Quick Answer
Model Rightsizer is an open-source Claude Code sub-agent from CloudZero that scores each task on capability need versus cost pressure, then routes it to the smallest model that can handle it. In its first week, it cut Opus spend 75% while shifting 234x more work to Sonnet.
Every Claude Code agent you run has to answer a question it usually never gets asked: does this task need the smartest model available, or are you paying Fable prices to rename a variable across three files?
CloudZero’s new Model Rightsizer exists because of one afternoon. I spent about two and a half hours building an entire capacity-planning dashboard in one sitting: data layer, UI, routing logic, all of it. It was a real, large, multi-file build, and I pointed the whole thing at Fable, the biggest model available, because the work felt big enough to justify it. What I never did was ask, task by task, whether every piece of it actually needed that much power. I just watched the credits burn faster than the work seemed to justify. By the end of the day, I’d written Model Rightsizer.
Takeaway: a default is not a decision. Fable didn’t get chosen for that afternoon: it was just sitting there as the biggest option, and nothing asked whether each piece of the work needed it. |
So I built the thing that would have caught it: Model Rightsizer, a Claude Code sub-agent that picks the right model for each task before any work happens. It reasons about a task once, on the most capable model, then hands back a routing map. Every unit of work downstream runs on the smallest model that clears the bar: Haiku for extraction, Sonnet for bounded work, Opus for judgment calls and high-risk changes, Fable for the biggest autonomous sweeps. Nothing defaults to the most expensive tier just because nobody made a decision.
It worked fast: the week it shipped, Opus spend fell ~75% while Sonnet execution volume jumped 234x. The real numbers behind that come later — first, the blueprint’s own verdict on the exact afternoon that prompted building it.
One real week, not just one afternoon
At this point, this felt more like theory. I needed to stress test this idea. So I turned it on for real, and gave it a week.
That week, Opus spend dropped about 75%, from $2,813 to $711. At the same time, Sonnet usage jumped from 7 runs to 1,638, and those 1,638 runs cost $22 total. I didn’t do less work. The same work ran on a cheaper model, hundreds of times over.
To show how much cheaper, I repriced that same 1,638-run week at Opus’s and Fable’s list rates: identical tokens, different per-token price. On Sonnet’s intro rate ($2 per million input / $10 per million output, in effect through August 31, 2026), the real week cost $22. The same volume at Opus’s list rate costs about $55. At Fable’s, about $110.
Both of those are a floor, not a ceiling. Fable’s “thinking always on” would likely have burned more tokens on the same task, not the same tokens at a different price. And the $22–$110 spread is only the execution-tier slice: a rounding error next to the $2,102 the team saved on judgment-tier Opus work that same week ($2,813 down to $711). Per execution, the same gap holds at a smaller scale: $0.013 real against ~$0.034 and ~$0.067 if it had defaulted up.
That week turned the blueprint from a quick fix into part of how the team’s agents work now.That was the week the blueprint stopped being a fix for one bad afternoon and became how the team’s agents actually work, which is exactly where it lives today.
Report
Finance needs to prove AI’s return: CloudZero report
260 senior finance leaders (more than half CFOs) told us why the speed of seeing AI spend, not the size of it, separates who pulls ahead on AI from who gets burned.
The core idea: two axes
Most “which model should I use” advice collapses into a single, useless axis: bigger is better, use Fable everywhere, cost is someone else’s problem. model-right-sizer scores every task on two axes instead:
- Effectiveness need (0–100): how much the outcome suffers if a weaker model does the work. This score is higher when a mistake would cost more in rework than the premium tokens would have saved. It is also higher when the task requires deep reasoning, runs unattended for a long time, has an ambiguous spec, or has a large blast radius if it gets the answer wrong.Â
- Efficiency pressure (0–100): how much cost, speed, and volume matter for this task. Higher when it runs many times, when the loop sits open (you pay for the model’s time either way), when no human is watching in real time, or when a large shared prompt makes caching change the math.
Neither axis alone is the answer. A task can score high on effectiveness need and still not warrant Opus if efficiency pressure is severe. A classifier that runs 10,000 times is a different animal than a once-per-PR review, even if both are “important.”
The output isn’t a single verdict. It’s a probability-weighted pick: a primary model with a confidence percentage, a runner-up with its own percentage, and the specific condition that would flip the call. A pick with no runner-up and no flip condition, just “use Opus,” means the two-axis weighing didn’t actually happen.
What that looks like as output, for a representative task (“rename a config key across a 200-file repo, low ambiguity, no judgment calls”):
Effort is a second dial, and it’s usually wasted
Model choice is only one lever. How hard the chosen model reasons is another, and most systems set it once and leave it uniform.
Model Rightsizer treats effort as a function of task difficulty, grounded in two published results:
- Difficulty-adaptive effort beats uniform reasoning. IBPO (“Think Smarter, not Harder”, arXiv:2501.17974) shows that long-reasoning models tend to run the same lengthy reasoning process regardless of query difficulty. Matching reasoning length to task difficulty instead improves MATH500 accuracy by 4.14–5.74 percentage points at a fixed 2–4× compute budget, roughly doubling the accuracy-per-compute achieved by self-consistency sampling. The practical takeaway is that overthinking an easy task wastes compute just as underpowering a hard one hurts accuracy.
- An explicit budget beats an implicit one. BudgetThinker (“Empowering Budget-aware LLM Reasoning with Control Tokens”, arXiv:2508.17196, Tsinghua AIR) trains models to track a remaining token budget using control tokens and a length-aware reward. Rather than degrading as the budget tightens, the model maintains accuracy across a range of budgets. In practice, every stage this agent routes includes an explicit token or thinking budget alongside the selected model, and adherence to that budget is evaluated afterward.The practical takeaway is that telling a model how much it has to spend works better than making it guess.
The same read on a task tells you two things: which model to use, and how hard to make it work. A big, risky change worth getting right gets the strongest model set to think hard. A quick typo fix gets a lighter model on its lowest setting, since spending more effort there buys you nothing. The one exception is Haiku, the smallest tier. It has no effort dial to turn, so when a Haiku task turns out harder than expected, the only move is to hand it up to a bigger model rather than ask it to think longer.
Side by side:
What Model Rightsizer would have said about that afternoon
It’s one thing to say some of that afternoon’s work didn’t need Fable. It’s another to run the numbers. I described each real piece of work from that session to Model Rightsizer, 11 tasks in total, from a one-line documentation tweak up to the two largest builds of the day, and asked it to score each one on its own two-axis rubric, exactly as if it had been consulted before the work was dispatched.
Zero of the 11 held. Every task that afternoon had run on Fable, and the blueprint would have kept none of them there. It moved 3 to Opus (the genuinely architectural, high-risk pieces, including the day’s single largest build), 6 to Sonnet (bounded, well-specified feature work, including the second-largest), and 2 to Haiku (near-mechanical edits).
The part that surprised me: the two biggest builds of the day are exactly where the blueprint split Opus from Sonnet, not where it reached for Fable. Size was never the right signal for which tier to use. That afternoon, it was the only signal I had.
These scores come from task descriptions written after the fact, not the full context a live dispatch would see. Confidence is lowest on those two big builds, where a high line count could mean real complexity or just repetition at scale, and a live run with the actual spec would sharpen those calls. But “zero of 11” doesn’t need much sharpening to make the point.
Zero of the 11 held their actual dispatch. Every single task that afternoon ran on Fable; the blueprint would have kept none of them there. The redistribution: 3 to Opus (the genuinely architectural or high-blast-radius pieces, including the day’s single largest build by line count), 6 to Sonnet (bounded, well-specified feature work, including the day’s second-largest build), and 2 to Haiku (near-mechanical edits).
The detail that actually matters: the day’s two biggest commits by size are exactly where the blueprint split Opus-versus-Sonnet, not where it reached for Fable. Line count was never the signal that should have driven the tier, and that afternoon it was the only signal being used.
These scores come from task descriptions written after the fact, standing in for the full context a live dispatch would have had. Confidence is lower on the two biggest builds, where a high line count could mean either real long-horizon complexity or mechanical repetition at scale. A live run, with the actual spec in hand, would sharpen exactly those two calls. Still, zero of 11 is a hard number to argue with.
Takeaway: re-scored after the fact, all 11 tasks moved off Fable. Nothing about that afternoon’s work needed the same tier eleven times over. The model just kept getting picked because nothing was asking the question. |
How it plugs into a Claude Code repo
The published repo ships two things, kept deliberately small. model-right-sizer.md is the agent definition itself: YAML frontmatter plus a system prompt, self-contained and org-agnostic. skills/model-right-sizer-init/SKILL.md is a companion skill that stamps a lightweight mandate into a target repo’s CLAUDE.md, so the agent gets consulted before and after substantive work.
Installation is one file. Drop model-right-sizer.md into your tooling’s agent discovery path (.claude/agents/ for a Claude Code project), then run the model-right-sizer-init skill once. It wires the consultation habit into that repo’s CLAUDE.md: a blueprint pass before a unit of work starts, a usage report pass after it finishes. The agent itself asks for almost nothing, just read, grep, glob, and fetch tools. It never edits or writes a file anywhere in your repo. The routing calls and the usage report are its entire output; what you do with them is up to your own orchestration.
How we use it inside CloudZero’s own developer workflow
Inside CloudZero, Model Rightsizer plugs into the standing dev-flow every code change in my team’s shared plugin runs through: recon, isolate, build, review, prove, vet, integrate, reconcile. Most of those eight stages spawn their own sub-agents: a code reviewer, a QA sweep, a git-tree recon. Before Model Rightsizer existed, every one of those dispatches just inherited whatever model the orchestrating session happened to be running on.
Model Rightsizer bookends that flow. Right after the design consult, before any sub-agent is dispatched, it runs a blueprint pass that maps the whole flow in advance: for each task, which model, how much effort, and how confident it is in that call. So code-reviewer runs on Sonnet, most of a panel-review fan-out runs on Haiku, and the one genuinely ambiguous refactor gets bumped to Opus. Nothing downstream picks its own tier. Each step just reads the blueprint.
The second bookend closes the loop. After the flow’s final stage, Model Rightsizer produces a usage report: recommended model versus actual for each stage, real spend pulled from the same AI Telemetry MCP described below, and a flag on any stage that quietly escalated mid-flight. That escalation flag is the part dev-flow acts on. When the same stage keeps escalating, that’s the signal to revisit the blueprint’s assumptions, not just fix the one pick.
Not every flow in the plugin runs the blueprint at this weight. Some get the full blueprint-and-report pair every time. Lighter flows get a blueprint only, sized to their smaller stakes. Deciding which weight a flow gets is itself a blueprint decision: the same probability-weighted judgment the blueprint applies to a single task, applied one level up to the flow.
How our overlay wires it into CloudZero’s own AI telemetry MCP
The core repo’s usage-report pass will happily run on estimated token counts. Our overlay swaps that estimate for realized spend, pulled straight from CloudZero’s own AI Telemetry ingest streams over MCP, the same product we sell, pointed at our own agent’s decisions.
The usage-report pass pulls the real spend in two steps. First it calls get_telemetry_streams to find the org’s Anthropic token-usage stream, then get_telemetry_data to pull token counts broken out by model and by token type: input, output, cache-write, and cache-read. Those counts are costed against the live price sheet from the table above.
The stream is keyed on a composite tag, AITelemetryTarget, formatted as claude-<model-id> | <user-email-local-part>. That tag is the join key that ties spend back to a dollar figure. Note that it’s a separate source from the run counts above, which come from our own dispatch logs.
This data arrives in real-time, so you can catch a spending habit while it’s still forming. It comes with the same limit noted above: AITelemetryTarget only resolves down to model, user, and hour. So a same-day pull can tell you a user’s total spend for a given hour, but not yet which specific task spent it.
How to try it, and where we’re taking it
Model Rightsizer drops into a workflow you already have, with no new orchestration layer, no rewritten agents, just one file and a stamped mandate. Every sub-agent you already run keeps its default; the blueprint only steps in when a task’s shape actually calls for sizing up or down, and reports back on the call. It’s the efficiency layer underneath the Claude Code sessions you’re already running, not a replacement for how you run them.
The code itself is public: docs.cloudzero.com/docs/ai-skills. Run the model rightsize install skill to pin model right sizer to your claude.md in your repo of choice. This will make sure Claude uses the model right sizer in all sessions.
