Ashita Orbis
Companion to: Vibe Researching

The Token Ledger: Generation vs Verification

Ashita Orbis | July 14, 2026 | 6 min read

The companion post makes a wall-clock claim: one day of generation bought four days of verification. Wall-clock understates it, because verification ran heavily in parallel while generation ran mostly single file. This investigation reconstructs the token ratio from the week's session transcripts, and the imbalance it finds is roughly an order of magnitude larger than the calendar figure.

Headline

The primary metric is output_tokens per assistant message — the tokens the models actually produced, which for reasoning models already includes their hidden reasoning tokens. Cache-read input is excluded deliberately (see below).

Basis (output tokens) Generation Verification Ratio
Claude only, measured 527K 9.33M ~18 : 1
All measured (Claude + GPT-in-harness) 527K 10.90M ~21 : 1
All measured + estimated review/dive tails 527K ~11.5–12.8M ~22–24 : 1
Verification-only (feature/ops build stripped) 527K ~7.0–8.4M ~13–16 : 1

Defensible range: ~13:1 to ~25:1, centered near 20:1 on the measured all-in basis. Every honest cut sits far above the 1:4 wall-clock figure; the most conservative cut that can be constructed — Claude-only generation against verification-only work — is still about 10:1.

Definitions

  • Generation is the initial creation of version 1: the research sweep, the cost engine, the report draft, and the site assembly that ended with the first live deployment. That was a single model session, from the opening prompt to the "it's live" message.
  • Verification is everything after version 1: review councils, adversarial passes, nine simulated-reader audits, adjudication, fresh-verifier fix checks, regression- and test-suite construction, provenance and registry machinery, and the remediation edits those reviews forced.
  • A stricter verification-only basis additionally strips identifiable pure feature or operations work (the connector server, the feedback intake, the site's visual system, and a traffic-mix engine axis added mid-week) as new product surface rather than verification.

Method

Why output tokens. They are the cleanest proxy for work produced, and for the reasoning models in the roster they already fold in reasoning tokens, so a long review counts for what it actually cost.

Why cache reads are excluded. Summed over the week, cache-read input runs to roughly a billion tokens — cheap re-reads of already-processed context, not work. Including them would produce an absurd figure in the thousands-to-one and is not defensible. (A secondary metric that adds uncached input is reported below but flagged, because the in-harness GPT proxy re-sends context uncached and inflates that number by an artifact rather than by real review work.)

Data sources, by confidence.

  1. Measured, high confidence. Every transcript in the project's own working directories and its subagent worktrees was walked programmatically, summing per-message output tokens for assistant messages whose timestamps fall inside the window, and classifying each message as Claude or GPT-in-harness by its recorded model field. Files are filtered per message, so a session that spans past the window boundary contributes only its in-window portion.
  2. Measured, hand-attributed. Some generation and verification work lived in shared working directories that also hold large volumes of unrelated automation. Each candidate session there was individually sampled — its first prompts and final message read — and hand-classified; only sessions dominated by this project were included, and the classification is auditable.
  3. Measured-or-estimated. The review councils and the reception audits run as separate processes whose tokens are not written into the main transcripts; they are estimated from their published output artifacts.
  4. Estimated, widest error bars. The premium-tier provider reviews and deep dives ran in a browser interface with no token telemetry at all. Their visible output was counted from the published artifacts and scaled by an explicitly stated hidden-reasoning multiplier. This is the single most approximate input, flagged as such — and it moves the headline by at most about a tenth even at the top of its range.

The measured core

Generation is one session at 527K output tokens (plausibly up to ~650K if a small ingestion or chart helper is folded in). Measured verification output is 9.33M from Claude and 1.58M from GPT-in-harness, for 10.90M all-measured. The Claude verification total is dominated by a handful of long orchestration and remediation sessions; the GPT total by a fan-out of independent reviewer instances.

That measured core — 527K against 10.90M — is where the headline lives. It is a sum of transcript usage fields, not an estimate. The estimated tails (premium-tier reviews, councils, reception audits, and the X sweeps) add at most ~1.9M against that ~11M base, pushing the ratio up by roughly a tenth and never rescuing the 1:4 claim in any direction.

Sensitivity

By what counts as verification. Keeping every post-v1 activity gives ~20.7:1. Stripping an estimated quarter of the mixed sessions as pure feature or operations build gives ~15.9:1; stripping two-fifths gives ~13.3:1.

By provider mix. Claude output alone is 17.7:1. Adding the measured GPT-in-harness layer lifts it to 20.7:1. Adding the estimated council, audit, provider-dive, and sweep tails lifts it to 21.8–24.3:1.

By metric. Output-only (the primary) is 20.7:1. Adding uncached input pushes it to 33.6:1, but that figure is inflated by the in-harness proxy re-sending context and should be read as an upper artifact, not the headline.

Generation-uncertainty check. Even if generation is understated at 650K, the measured all-in ratio is still 16.8:1. The order of magnitude is robust.

Confidence

The measured core (generation 527K, verification 10.90M) is high-confidence transcript data. The estimated tails carry wide error bars but small leverage — combined they are under a fifth of the measured base. The bottom line is that the token ratio is an order of magnitude larger than the 1:4 wall-clock ratio: best stated as ~15:1 to ~25:1, centered ~20:1, with a conservative floor near 10:1.

Objections a careful reader should raise

  1. Cross-tokenizer mixing. Claude, GPT, and premium-tier tokens are not the same unit. The Claude-only ratio (17.7:1) is the cleanest single number; the multi-provider figure is an explicit sum-of-different-tokenizers approximation, used only for order of magnitude.
  2. Generation under-count. Bounded: even at 650K the ratio stays about 17:1.
  3. Shared-directory attribution. The mixed-directory sessions were prompt-sampled and this-project-dominant; even halving all of them drops verification only to about 9M, still 17:1.
  4. Feature work counted as verification. Addressed directly by the verification-only basis (13–16:1).
  5. The premium-tier reasoning multiplier is a guess. It is the widest error bar, flagged as such, and moves the headline by at most a tenth.
  6. Model-version labels are unreliable in this workspace. Irrelevant to every ratio — only the provider boundary matters, and that comes from the recorded model field, not the version label.
  7. Cache-read excluded. Deliberate and stated; including a billion tokens of cheap re-reads would be indefensible.

The point the ratio serves is the companion post's: for research assembled by inference from soft public data, the verification does not merely cost more than the generation — it costs about twenty times more, and most of that spend is the machinery that makes the next claim cheaper to check than the last.