> Token maxxing

How to get the most finished work out of every AI plan and API token we pay for: stop paying twice for the same context, send each job to the cheapest model that can do it, let the slow work wait for the discount, and always keep something back.

Written 16 October 2026. Prices and multipliers below come from Anthropic's documentation as of that date (sources at the end); they change, so check them before building a budget on them. This is the practical companion to the bada orchestrator proposal, which would automate most of it.

1. What we mean by it

"Token maxxing" here means more finished tasks per dollar and per plan window, not more tokens burned. The unit that matters is cost per completed task: a cheap request that needs three retries isn't cheap, and a subscription window that resets with half its room unused was money spent on nothing.

The line we don't cross. Everything on this page works inside each provider's terms. Sharing one account between people, rotating accounts or keys to dodge rate limits, scraping a consumer chat app as if it were an API, or reselling a subscription's allowance are against the terms of every provider we use, get accounts closed, and aren't optimization. If a limit is too tight, the honest moves are a bigger plan, the API, or a second provider (section 6).

2. Where the tokens actually go

Before optimizing, look (AGENTS.md section 8: measure first). In an agent session most of the bill is input, and most of that input is the same thing sent again: the system prompt, tool definitions, AGENTS.md and the conversation so far are re-read on every turn. A 40-turn coding session can re-send its first files forty times. Output is pricier per token but usually far smaller. So the order of attack is: stop paying full price for repeated input, then send less input, then pick a cheaper model for what's left.

We already collect the numbers: Claude Code and Codex export OpenTelemetry to our local collector, so token counts and cost per session sit in Grafana next to everything else. A token-maxxing change that doesn't move those numbers didn't work.

3. Free wins: same quality, smaller bill

Prompt caching

The biggest lever, and nearly free. Mark the stable start of a request (system prompt, tools, big reference documents) as cacheable, and later requests that start with the same bytes read it from cache instead of paying full input price. ¹

Claude API, October 2026	Price vs normal input
Cache write, 5-minute lifetime	1.25×
Cache write, 1-hour lifetime	2×
Cache read (most models)	0.1×
Cache read, Opus 5.5	0.05×

With the 5-minute lifetime, a prefix pays for itself on the second request. The rules that make it work:

Stable first, volatile last. Caching matches an exact prefix, so one changed byte early on invalidates everything after. A timestamp, a random id or unsorted JSON in the system prompt silently turns caching off.
Check it, don't assume it. Each response reports cache_read_input_tokens. On a warmed-up loop it should dwarf the uncached input. If it's zero, something early in the prompt is changing.
Pick the lifetime by the gap. Requests less than five minutes apart keep the 5-minute cache warm by themselves; the 1-hour lifetime only pays when the gaps run between five and sixty minutes.
Don't hop models mid-task without a reason. Caches belong to one model, so switching throws the warm cache away.

Claude Code, Codex and Kimi's CLI cache on their own. What we control is not breaking it: keep AGENTS.md and project instructions stable during a session and put changing state in the conversation, not the system prompt.

Send less context

Short, stable instructions. Every line of AGENTS.md is paid for on every turn of every session. Rules the model already follows, or that no longer apply, are pure cost.
Point, don't paste. Name the file and line instead of pasting the whole file; let the agent read the twenty lines it needs.
One task per session. Start fresh when the topic changes (/clear in Claude Code). ⁵ A long session carries every earlier detour into every later turn.
Compact deliberately. Summarizing a long session (/compact) frees room but rewrites the cached history, so do it at a natural break, not every few turns.
Make tools quiet. A test run that prints 3,000 passing lines costs 3,000 lines of input on every later turn. Ask for failures only.

Ask for less output

Output is the expensive side (5× input on most Claude models). Ask for a diff, not the whole file; a table, not an essay; no restating the question. On models with an effort setting, low or medium is usually enough for chores, and the top settings earn their cost only on genuinely hard problems. ²

Batch what nobody is waiting for

Anthropic's Message Batches API charges 50% of the normal price on every token, cache reads and writes included, in exchange for results arriving later rather than at once. ³ OpenAI has a batch tier on similar terms. ⁴ Evaluations, backfills, nightly summaries and "tag these 2,000 pages" jobs belong there. A batch request is single-shot, so it suits work without a tool loop.

4. Route each job to the cheapest model that can do it

The newest flagship isn't the right tool for renaming variables. Spend the expensive model on the hard part and push the rest down.

Job	Goes to	Why
Tagging, summaries, link checks, commit messages	Local Ollama (`qwen3:4b` today)	Costs electricity and time, not quota. Fine overnight.
Searching and reading a codebase	A small model in a subagent	The reading stays in the subagent's context; only the answer comes back.
Bulk, well-specified coding	Kimi, or an open coding model on Venice	Much cheaper per token; good enough when the task has clear checks.
Hard changes, design, review	Claude Code or Codex on their subscriptions	Where the strongest model actually changes the outcome.

Subagents deserve a note. Delegating "find every caller of this method" to a subagent keeps thousands of lines of search results out of the main conversation, which every later turn would otherwise pay to re-read. Give the subagent a cheaper model when the job is just reading.

Measure the simple option first. Before building a cascade of models, try the strong model at lower effort on the same tasks. One model at medium often matches a two-model pipeline, keeps one warm cache instead of two, and is far less code. Judge by cost per finished task on a sample of real work, not by price per token.

5. Plans are windows: use them before they reset, but keep a reserve

Subscriptions such as Claude's and ChatGPT's don't bill per token; they give a usage window that resets (every few hours, plus a weekly cap). Unused room at reset is gone. That makes timing part of token maxxing:

Front-load unattended work into windows about to reset. A window with room left an hour before reset is the cheapest compute we have.
Keep a reserve on every plan. Unattended work may spend up to the limit minus the reserve, never more, so there is always room left for Jay to work by hand. The orchestrator proposal suggests 30% as a starting point and enforces it in plain Ruby, not by a model's judgment.
Fall over, don't fail. When one plan says "limit reached", the task moves to the next allowed provider instead of waiting or retrying in a loop.
Night is for local. Long, low-stakes jobs wait for the evening and run on Ollama, where speed doesn't matter.

6. Several providers, on purpose

Paying for Claude, ChatGPT, Kimi and Venice isn't waste if each has a job: it gives four windows instead of one, lets us compare quality and price on our own tasks, and means no single provider going down or changing prices stops the work (AGENTS.md section 11). The rule is one account per person per provider, used as its terms allow. Two providers side by side are also the cheapest form of review, since the same model is never the only judge of its own work.

7. A checklist

Look at a week of token and cost data per tool in Grafana. Know where the money goes before changing anything.
Confirm caching hits: cache reads should dominate input on long sessions. If not, find what changes at the top of the prompt.
Trim AGENTS.md and project instructions to what still earns its place.
Start a fresh session per task; quiet the noisy tools.
Move chores to Ollama and reading to cheap subagents.
Move anything nobody waits for to a batch API.
Set a reserve per plan and route unattended work around it.
Measure again. Report before and after in cost per finished task.

Sources

1. Anthropic: Prompt caching, including write and read multipliers and lifetimes.
2. Anthropic: Effort.
3. Anthropic: Batch processing.
4. OpenAI: Batch API.
5. Claude Code: Manage costs effectively.

Provided as is, for information only, with no warranty and no liability. Not legal or professional advice. Security and radio material is for authorized, lawful use only. Full disclaimer.

Visits are logged on our own server: IP address, browser and device details, and pages viewed. We use them to understand traffic and spot attacks, and never share or sell them.