A Leeds Team’s Token Budget for Friday’s Code Review

Fare watch EN2026-10-26

It is Thursday afternoon in Leeds, and your team wants an AI-assisted review of a payment-service change before Friday’s release. The question is not simply what the model charges per million tokens. It is how much material the review will send, how often that material will be sent again, and how much analysis will come back.

Here is a desk-ready estimate for a complete review of one defined change set—not an entire repository and not a guarantee that every defect will be found. The prices below are hypothetical arithmetic inputs, not current RelayVano rates.

1. Define the payment-service review boundary

Write down what the reviewer must inspect before counting anything. For this example, the scope includes changed implementation files, relevant tests, and enough surrounding code to understand authentication, retries, and database writes.

Implementation and supporting source: approximately 72,000 characters.
Tests and fixtures: approximately 16,000 characters.
Review instructions, architecture notes, and tool definitions: approximately 8,000 characters.

Exclude generated files, dependency directories, lockfiles unless relevant, and unrelated documentation. Remove credentials and customer data. A smaller, deliberate review package is usually more useful than a repository dump.

2. Convert the review package into input tokens

For an initial estimate, divide characters by four. That gives approximately 18,000 source tokens, 4,000 test tokens, and 2,000 instruction tokens: 24,000 input tokens for the first request.

This conversion is only a planning shortcut. Code, identifiers, punctuation, and different writing systems tokenize differently. Use the selected model’s tokenizer where available, then compare your estimate with the API’s reported usage after a trial request. Include system instructions and tool schemas; they also consume context.

3. Budget four requests instead of one

Our review has four stages: inspect the change, investigate suspicious paths, verify findings against tests, and produce the final report. Assume the client preserves conversation history and adds fresh tool results between requests.

Request 1: 24,000 input tokens; 2,000 output tokens.
Request 2: 29,000 input tokens; 2,000 output tokens.
Request 3: 34,000 input tokens; 2,000 output tokens.
Request 4: 39,000 input tokens; 3,000 output tokens.

Each transition adds the preceding 2,000-token response plus 3,000 tokens of new file excerpts or tool results. The final response is longer because it contains prioritized findings and suggested checks.

Total estimated usage is therefore 126,000 input tokens and 9,000 output tokens. Counting only the original 24,000-token package would substantially understate the bill. Your client may compact history or send different context, so inspect its actual behavior.

4. Apply separate input and output prices

Suppose your chosen model costs $3 per million input tokens and $15 per million output tokens. Again, these are illustrative rates; replace them with the applicable prices before budgeting.

Input cost: 126,000 ÷ 1,000,000 × $3 = $0.378.
Output cost: 9,000 ÷ 1,000,000 × $15 = $0.135.
Estimated model charge: $0.513, or about $0.51.

This baseline assumes ordinary uncached input pricing and no additional billable categories. If cached reads, cache writes, reasoning tokens, or context-length pricing tiers apply, calculate those categories using the provider’s billing rules. Do not assume repeated context automatically receives a cache discount.

5. Reserve $0.65 and measure the first run

Add a 25% planning buffer: $0.513 × 1.25 = $0.64125. Round the working budget to $0.65. That allowance covers modest variation, not unlimited agent loops, retries, or repeated reviews after fixes.

Record each request’s billed input, cached input where reported, output, model, and charge. A local test command consumes no model tokens by itself; sending its output back to the model adds input. Developer time and CI compute remain separate costs.

6. Turn the estimate into a repeatable release check

For this workflow, I recommend RelayVano as a pay-as-you-go relay that works with Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs, with the API base at https://api.relayvano.com. Sign up, check the selected model’s current rates, and run one representative review before setting your team’s budget.

Keep the scope, request count, and actual usage beside the review report. Next Friday’s estimate can then start from measured behavior rather than a guess about repository size.