Did That Session Even Need Opus?
You open Claude Code, the model is already Opus, and you leave it there. That is the whole decision for most sessions. You picked Opus once, months ago, because it is the strongest model and you did not want to think about it again. Then the 5-hour window starts vanishing faster than you expected, the “approaching your Opus limit” warning lands mid-task, and you still have not asked the one question that would explain it: did the session you just ran actually need Opus at all?
When “always Opus” becomes the whole workflow
Defaulting to the best model is a rational habit. The failure modes of picking too small a model are loud (a wrong answer, a broken refactor, a wasted round-trip), and the cost of picking too big a model is silent. You never see the quota you would have kept. So the default hardens, and every session pays the Opus rate whether the work earned it or not.
The trouble is that Opus quota is the tier you exhaust first. On a Max plan the Opus budget is far tighter than the Sonnet budget, which is why the limit messages that stung across the spring were so often Opus limits specifically. When a mechanical file rename and a deep architecture design both bill against that same scarce pool, the rename is the one quietly costing you a task you cared about later in the day.
Watching my own governor runs, this jumped out. I run batches of autonomous Claude Code sessions against a ticket queue, and plenty of them were on Opus doing work that never touched Opus-shaped reasoning: reading a file to answer “where is X,” applying a one-line fix I had already specified, regenerating a config. Sonnet work, billed at Opus. I was not choosing that. The default was choosing it for me, one session at a time, and I had no view that showed me which sessions those were.
What a Sonnet-shaped session looks like
There is no clean line between “needs Opus” and “does not.” Model choice is a judgment about task shape, and the same words in a prompt can hide either a trivial edit or a subtle design problem. But some sessions have a shape you can recognize after the fact.
| Feature | Leans Sonnet-shaped | Leans Opus-shaped |
|---|---|---|
| Task type | Lookups, renames, mechanical edits you already scoped | Open-ended design, multi-file reasoning, tricky debugging |
| Instruction | You told it exactly what to change | You described a goal and let it plan |
| Course corrections | Few; it did roughly what you said | Several; the plan evolved as it went |
| What failure costs | A cheap retry | A wrong architecture you live with for weeks |
None of these prove a session was wasted on Opus. A one-line fix can sit inside a problem that genuinely needed the stronger model to locate. The point of the table is not to sort your history automatically. It is to describe the pattern a human recognizes instantly once it is put in front of them, which is exactly the pattern a tool can help you find in a month of sessions you will never re-read by hand.
How the quota audit works
tj quota-audit ships today in TokenJam. It reads your Claude Code JSONL locally, finds the sessions that ran on Opus, and flags the ones whose shape looks Sonnet-shaped by signals like the ones above. For each flag it estimates the Opus quota that session consumed, so the output is not a vague nudge but a ranked list: here are the Opus sessions most worth a second look, and here is roughly how much Opus budget they cost you.
The command is shipped. I want to be exact about what it does and does not claim, because the honest version of this feature is harder to build than the dishonest one. The dishonest version sorts your sessions and tells you which to downgrade. This one refuses to make that call, because it cannot. It can measure what an Opus session cost and describe its shape. It cannot know whether the answer would have held on Sonnet, and neither can any tool that did not run the task twice. So the output is a list of candidates to review, never a verdict.
What is already shipped is the substrate this sits on. Session Story reconstructs what each session and subagent actually did, locally, from the same JSONL. Plan-tier-aware quota reporting knows the difference between your Opus and Sonnet budgets. The audit is the targeting layer on top: it points you at the specific sessions worth reviewing, and Session Story lets you open one and see what it really did before you change anything.
Why “candidate,” never “safe”
The word “safe” is where honest tooling in this space goes to die. A tool that tells you a session was safe to run on a cheaper model is claiming to know the counterfactual, and it does not. It measured one run on one model. Everything about the other model is inference.
So the audit stays inside what it can actually see. It reads reclaimable quota, which is real and measured, and it reads task shape, which is a signal and labeled as one. It hands you a list and gets out of the way. This is the same discipline behind matching model to task complexity that Anthropic’s own guidance encourages: the routing decision is yours to make with context a log file does not have. TokenJam narrows the search from a month of sessions down to the handful worth your attention. You still make the call.
That restraint is the whole posture. The tokenmaxxing reflex was to let a black box optimize your usage for you and hope it did not quietly wreck your output. A quota diagnostic earns trust by doing less: it shows you where the quota went and what to review, and it leaves the acting to the person who knows the task.
Where this fits
If you live in Claude Code on a Max plan and the Opus limit is the wall you keep hitting, the audit is built to answer one question you cannot answer today without hand-parsing transcripts: which of my Opus sessions were doing Sonnet work, and how much Opus quota would I get back by moving them? You get a targeted list of candidates. You keep the judgment. Nothing gets downgraded on your behalf, and nothing leaves your machine.
It runs the same way everything in TokenJam runs. Install and run now: pipx install tokenjam then tj quota-audit (or npx tokenjam / uvx --from tokenjam tj), reading the JSONL already on your disk, phoning home to nobody.
Common questions
- Does the audit switch my model to Sonnet automatically?
- No. It never changes a model for you. It reads your local session logs, flags Opus sessions that look Sonnet-shaped, and estimates the Opus quota each one used. Acting on a flag is entirely your decision. TokenJam is a diagnostic, not an auto-optimizer.
- If a session is flagged, is it safe to just downgrade it?
- No, and this is the important part. A flag means the session is a candidate worth reviewing, not that Sonnet would have produced the same result. TokenJam can measure the quota a session burned and describe its shape, but it did not run the task on Sonnet, so it cannot promise equivalence. Treat a flag as a prompt to look, use your own judgment, and verify the swap if it matters.
- Can I use the Opus audit today?
- Yes. `tj quota-audit` ships today. Install with 'pipx install tokenjam' (or 'npx tokenjam' / 'uvx --from tokenjam tj') and run 'tj quota-audit'. It sits on top of Session Story, per-subagent attribution, plan-tier-aware quota reporting, and the MCP server, all of which ship too. What it will never do is declare a downgrade safe. It hands you a ranked list of candidates and leaves the call to you.
- Why does Opus quota run out before my Sonnet quota?
- On a Max plan the Opus budget is much tighter than the Sonnet budget. That is why the limit warnings people hit are so often Opus-specific. When Sonnet-shaped work runs on Opus by default, it drains the exact tier you exhaust first, which is why finding that work is worth the effort.
- Does my session data get uploaded anywhere for this?
- No. The audit reads the JSONL Claude Code already writes to your disk, runs entirely on your machine, and never phones home. There is no signup and no account. That is a fixed constraint for everything TokenJam does, not a setting.
- How is this different from just picking a model per session by hand?
- It is not a replacement for your judgment, it is a way to aim it. Picking well per session assumes you notice every time you left Opus on for mechanical work, across a month of sessions you will never re-read. The audit surfaces the specific ones worth a second look and estimates the quota at stake, so your attention goes where it pays off.