How to measure AI coding subscription usage without guessing

The only reliable way to measure an AI coding subscription is to record three separate ledgers for the same fixed task: the provider’s account meter before and after the run, the machine-reported token or credit trace, and the accepted engineering outcome after tests and review. Do not convert a session’s API-equivalent dollar estimate into a subscription bill, and do not compare “messages” when one run reads a tiny file while another explores an entire repository. Use a fresh worktree, pin the model and reasoning effort, keep the task brief unchanged, capture the final diff and test result, then repeat the task class at least three times. The result is a burn rate you can audit—not a feeling that a plan “ran out fast.”

This guide answers one question: how do you measure your own AI-coding allowance before upgrading or cancelling? If you want a plan recommendation instead, use our separate US$20 Cursor vs Codex vs Claude Code comparison. The Cursor review and Codex CLI review cover product quality rather than measurement procedure.

First: stop mixing four different numbers

An AI coding dashboard can show several quantities that look interchangeable but are not:

Number	What it measures	What it cannot prove
Account quota percentage	Remaining capacity in a provider-defined rolling or billing window	Exact tokens, dollars, or future tasks unless the provider publishes the denominator
Input, cached-input, and output tokens	What one agent run processed and produced	The amount of included subscription allowance remaining
API-equivalent cost or credits	What the token profile maps to at a published rate card	Your subscription invoice or the size of an unpublished included pool
Accepted outcome	Tests passed, defects found, reviewed diff, or work shipped	Model consumption unless it is joined to the same run record

That distinction matters even at the entry level. Prices checked on August 4, 2026 were US$20 per month for Cursor Pro, US$20 per month for ChatGPT Plus with Codex, and US$20 monthly for Claude Pro (US$17 equivalent when billed annually). The equal sticker price does not create an equal meter.

Cursor says every plan includes model usage and can continue with on-demand billing. Codex maps model tokens to credits but also applies plan-level limits. Claude subscribers see rolling plan-usage bars, while its locally computed session-dollar figure is an API-rate estimate rather than the subscription bill. Your test must preserve each provider’s native account meter instead of forcing all three into dollars.

The seven-step measurement protocol

1. Choose a repeatable task class

Do not benchmark “a day of coding.” Choose something with a finish line, such as:

• review a two-file fixture with a hidden defect rubric;
• implement one endpoint against fixed tests;
• migrate one component while preserving snapshots;
• diagnose one known failing test without editing unrelated files.

Record the prompt in a file and hash it. Keep repository commit, tool version, model, reasoning effort, permissions, MCP servers, and network access fixed. A task that changes any of those inputs belongs in a new comparison row.

2. Start with fresh context and a clean worktree

Long conversations repeatedly carry earlier context. Anthropic’s current guidance recommends clearing between unrelated tasks; OpenAI likewise notes that prompt size, files, tools, reasoning, retrieval, and caching all affect consumption.

Use a new session or worktree for each scored run. Record git status and the starting commit. Do not let one agent inherit a plan or code summary that the other agent never received.

3. Snapshot the account meter before the prompt

Capture the provider’s own display with a timestamp:

• Codex: open the account usage dashboard or use /usage for daily, weekly, or cumulative activity; /status is useful for session configuration and remaining context.
• Claude Code: use /usage, or configure the official status line fields for the five-hour and seven-day percentages and reset timestamps.
• Cursor: record the account dashboard’s included pools and on-demand usage before starting. If the dashboard separates first-party and API-model pools, keep them in separate columns.

Never copy authentication tokens or private account identifiers into the ledger. A timestamped percentage, pool label, reset time, and plan name are enough.

4. Capture the run trace

Machine-readable output is preferable to a screenshot. Codex supports codex exec --json, whose final turn.completed event includes input, cached-input, output, and reasoning-output token fields. For interactive tools, record the built-in usage screen after the run and keep the local transcript private.

For every run, log:

task ID, provider, plan, tool version, model, effort,
start/end time, input tokens, cached input, output tokens,
account meter before/after, files changed, tests, accepted outcomes, rework minutes

Do not rely on prompt length alone. Tool output, repository reads, generated diffs, retries, subagents, and growing history can dominate the run.

5. Score the engineering outcome before calculating value

Tokens are an input, not a result. Decide the acceptance rubric before the agent sees the task:

• number of hidden tests passed;
• defects found minus false positives;
• required files changed without scope creep;
• reviewer-accepted diff;
• minutes of human rework before merge.

If a run consumes little quota but produces a rejected diff, its cost per accepted outcome is undefined—not “cheap.” If it completes twice the useful work, higher consumption may be rational.

6. Snapshot the account meter again

Wait for the provider dashboard to refresh, then capture the same fields. Compute only the native delta: percentage points, credits, or dollars from the same labeled pool.

If the meter does not move or updates late, record null and rerun later. Do not replace a missing subscription delta with an API-equivalent estimate. That substitution is the most common source of false “tasks per month” claims.

7. Repeat and use a median

Run at least three trials per task class. Report the median consumption and the range. Agent behavior is stochastic: one run may find the right file immediately while another explores, retries, or spawns more work. An April 2026 research paper found very large token variance across repeated agentic tasks; that supports repeated trials, not a universal multiplier for every product.

TopInsight test: the ledger refuses false precision

• Measurement test date: August 4, 2026
• Environment: Windows 11 10.0.26200; Node.js 24.16.0
• Source record: July 30 Codex CLI 0.146.0, GPT-5.6 Sol, medium reasoning, read-only sandbox
• Public calculator: download and rerun the NDJSON ledger
• Original task evidence: six-defect audit fixture and result

We fed the calculator the aggregate record from our hidden-rubric audit. Codex found 6 of 6 seeded defects with zero false positives in 47 seconds. The trace reported 71,177 input tokens, including 33,280 cached input tokens, plus 1,050 output tokens. Using the July 30 GPT-5.6 Sol credit rates, the script reproduces 5.9406 credits, or 0.9901 credits per accepted defect.

The account meter was not captured before and after that historical run. The tool therefore returns:

{
  "recordsMissingAccountMeter": 1,
  "canProjectSubscriptionBurn": false,
  "warning": "Do not extrapolate subscription capacity from records without before/after account-meter snapshots."
}

That false is the important result. The run proves token use, credit conversion, task outcome, and elapsed time. It does not prove what percentage of a Plus, Pro 5x, or Pro 20x allowance the task used. A calculator that filled in a monthly task count would be inventing its denominator.

Run the public ledger from the repo or after downloading both files:

node ai-coding-usage-ledger-2026-08-04.mjs runs.ndjson --json

The script accepts no credentials and sends no data over the network. Its sample record contains aggregate counts only—no prompt, transcript, repository content, or account identifier.

A spreadsheet layout that survives product changes

Use one row per run, not one row per day:

Field group	Required columns
Identity	date, provider, plan, tool version, model, effort, task ID
Reproducibility	repo commit, prompt hash, permissions, context state, MCP count
Native meter	pool/window name, before, after, reset time, refresh delay
Trace	uncached input, cached input, output, reasoning output, wall time
Outcome	tests passed/total, accepted outcomes, false positives, files changed, rework minutes
Decision	native meter per accepted outcome, median of task class, upgrade/cancel threshold

This schema keeps old observations useful after a pricing change. Update the rate card for new runs; do not silently recalculate a historical subscription percentage against a new plan.

How to decide after two weeks

Choose thresholds before looking at the result:

• Upgrade when representative accepted work repeatedly reaches a hard limit, rework is low, and a higher plan costs less than the blocked engineering time.
• Route models when one expensive model dominates consumption but ordinary tasks pass with a cheaper model or lower reasoning effort.
• Tighten context when cached and uncached input grow across unrelated tasks, or when long sessions create retries without improving acceptance.
• Cancel or switch when accepted outcomes stay low even though the subscription meter barely constrains you. Unused quota is not value.

Community reports explain why this discipline matters. A recent Cursor thread shows users confusing displayed API-equivalent spend with separate included pools. A Codex thread ranges from users hitting limits after a few Sol tasks to another reporting only a small weekly change after hours of work. Claude Code users have built status lines precisely because five-hour and weekly windows are easy to lose track of. These are real pain points, but their contradictory individual numbers are not plan specifications.

Independent videos are useful for task ideas and workflow differences: the same app brief can produce different interaction loops and accepted outputs. They rarely synchronize renewal windows, account meters, model settings, and full traces. Use them to design workloads—not as quota ledgers.

Final rule

Measure quota per accepted outcome, not tokens per prompt and never vibes per month. Keep the provider’s native subscription meter, the machine trace, and the reviewed engineering result as three separate columns joined by one task ID. After three or more controlled runs, the median tells you whether to upgrade, route work to another model, or change your context habits. Without all three ledgers, the honest answer is “not enough evidence.”

For the next decision layer, compare your measured results with the high-price Cursor Ultra vs Codex Pro guide or use the Claude Code vs Cursor workflow comparison to choose the interface that fits the task.