Cycles
Every capture cycle as a receipt — what it covered, expected vs actual answers, surface mix, and cycle-to-cycle diffs so you always compare like with like.
Overview
A cycle is one pass over your questions: the receipt for one batch of captures. Every manual run and every scheduled capture records exactly which questions, engines and locations it covered, how many answers were expected and how many landed, how long it took, and whether it completed. (The API and the MCP tools call the same thing a capture run.)
Why this matters: AI-visibility metrics only mean something when you know what was actually captured. If a metric moved between Tuesday and Friday, the first question is whether the cycle covered the same things — different questions, different engines, a surface that failed to capture. Cycles make that answerable instead of guessable.
Where cycles live
Cycles are a tab of Run schedule & cost: /dashboard/schedules?tab=cycles. The old /dashboard/runs address redirects there.
The table shows, per cycle: its name and whether it was scheduled or manual · when it started · its scope (full project or one group) · its status in plain words, with the reason under it when it stopped short (credits, a provider outage, a policy pause) · answers captured of expected · duration · and, for organization owners and admins, cost. Filter by scope, status and period; Load more widens the view 50 at a time.
Cycles are not numbered on this tab. The product numbers cycles from the project's first capture on the answer and trend surfaces, and that numbering is computed per answer; a cycle row is identified by its start time and its label.
Starting a cycle
- Open Run schedule & cost and choose the Cycles tab.
- Click Start a cycle — a full cycle captures all active prompts against all active engines.
- If the project has prompt groups, the button opens a menu: a full-project cycle or a single group's cycle.
- The cycle appears at the top of the list; scheduled captures create cycles the same way automatically.
To ask a subset once — one prompt, or a hand-picked set — use Run once now at the top of the page. It opens the capture form, priced as a single run.
Running the same thing twice. If this project's last manual run (a bulk capture, a cycle started by hand, or the first capture started with “Run the first capture now” when a schedule is set up) is still running, or started or finished less than an hour ago, starting another asks you to confirm first. The confirmation says when that run started and that it is still running, or how many minutes ago it finished, how many answers it has, and — for organization owners and admins — what it has been billed so far. Confirming starts the run and records on it which run it repeated and who confirmed. Over the API, POST /api/snapshots/capture-bulk and POST /api/runs/trigger answer 409 with code REPEAT_CAPTURE_UNCONFIRMED until the request carries confirmRepeat: true. Scheduled runs are never held back by this, and neither is a single prompt captured on its own (the capture form's single-prompt mode).
What a cycle records
| Field | What it tells you |
|---|---|
| What it covered | The exact set of questions, engines and locations the cycle executed |
| Expected vs actual | How many answers were implied vs how many actually landed — a shortfall is visible, never silent |
| Not captured, by cause | When a cycle comes up short: how many answers each cause took, with one plain sentence per cause (see below) |
| Duration & status | How long the batch took and whether it completed, partially completed, or failed — with the reason in plain words |
| Surface mix | How the cycle's answers split across AI surfaces — chat LLMs vs Google AI Overview vs AI Mode vs organic SERP |
| Cost split | The cycle's cost by source (LLM, proxy, SERP) — visible to organization owners and admins only; other members see the cycle without cost fields |
When a cycle comes up short
A cycle that captured fewer answers than it planned says why, counted per cause, on its row in the Cycles tab, on its page, and on the matching job in the Job log (the same counts the capture form shows when the job ends). Six causes can appear, each with its count and one plain sentence:
- An engine's model is no longer served — the engine is skipped before any call: nothing is spent, nothing counts against your allowance or daily cap, and the count is shown as
skipped: the model is no longer served. The platform's model alert names the replacement; swap the engine from there. - The AI provider could not take some answers — the provider declined them; nothing was charged for them. On a scheduled cycle this happens when the platform's own provider credit runs short, so the platform asks those questions on those engines again later in the same cycle — once an hour until the cycle ends — and adds what comes back to the same cycle: its answer count rises and this count falls (since 8 October 2026). If nothing at all was captured, the whole cycle is retried every hour instead. A refusal by your plan (allowance, cap, budget or a pause) stops the retries.
- and 4. A platform-side pause — a safeguard while the platform team restores capacity, or a pause by the platform team; your credits and schedules are unaffected.
- Your plan's daily cap, included allowance or pay-as-you-go cap — the plan sentence you already see when a capture is refused.
- Any other provider error — the AI provider did not respond for those answers.
A cycle refused before it was sized (a pause, a gate) shows the cause with not sized in place of a count, the same way its expected count reads. The counts and sentences ride on the cycle as metadata.shortfall — one entry per cause, each { count, reason } — and, on a cycle that ran, the engines skipped as no longer served are the cycle's skipped_snapshot_count (a cycle refused before it ran keeps the whole planned count there), so list_runs and get_run carry them too. Cycles recorded before 25 September 2026 have no shortfall entry.
Cycle detail & diffs
Open any cycle to see its page. When two cycles covered exactly the same questions, engines and locations, the page links the comparable one and offers a side-by-side diff — per-prompt, per-engine changes between the two, covering SERP engines as well as chat LLMs.
Diffs deliberately require the same coverage: comparing a 35-prompt cycle against a 10-prompt cycle would attribute the coverage change to your brand. If no comparable cycle exists, the page says so instead of offering a misleading comparison.
Comparing periods
Period-over-period comparison lives on the home page's cycle charts: each question type's line runs on the project's own cycles, a model change cuts the line rather than being averaged through, and a change to the tracked set is marked on the cycle it landed in.
Capture provenance
Each answer inside a cycle carries a disclosure of how it was collected:
- Native browser capture — Google AI Overview and AI Mode are captured by AEO Optima's own browser over a residential connection, with the capture country named.
- Provider API — chat LLM answers come from the provider's own API.
- SERP vendor API — connector-based SERP captures name the vendor.
MCP parity
AI assistants get the same receipts through three MCP tools: list_runs, get_run (including the per-cycle surface composition), and diff_runs. Cost fields follow the same visibility rule as the UI — they are omitted for member and viewer tokens.
Related
- Snapshots — what each captured answer contains
- Run schedule & cost — putting captures on a cadence, and what one cycle costs
- SERP & AI-Surface Tracking — native Google AI Overview / AI Mode capture