Token Budget Planner

Working backward from a budget

Most cost tools start with your usage and tell you what it will cost. This one runs the arrow the other way: you set a monthly dollar cap and it tells you how much Claude Code that actually buys - how many prompts, how many sessions, how many hours, at your chosen model. That is the more useful framing when you have a fixed budget and need to make it last. Instead of finding out on the 20th that you have blown through your cap, you start the month knowing your daily allowance and can pace to it deliberately. The planner divides your budget by the cost per prompt to get prompts per month, then converts that into the units you actually think in: sessions, hours, and a per-day spending line.

The one number everything hangs on

Cost per prompt is the hinge. It is computed from four things: your input tokens (billed at the model's input rate), your cached input (billed at roughly a tenth of that), your output tokens (billed at roughly 5x the input rate), and your model choice. Change any of them and the whole plan shifts. Halve your average prompt size and you double how many prompts your budget buys. Switch from Sonnet to Opus and you cut your prompt count by roughly 5x for the same money. This is why the planner exposes all four knobs - they are the levers that determine whether your budget feels generous or tight.

How to read your allowance

• Prompts per month - the raw capacity your budget buys at your current settings.
• Prompts per day - the same figure spread across your working days. This is your daily pace target, the number to keep in your head.
• Sessions per month - prompts divided by how many prompts a typical session takes. Useful if you think in work sessions rather than individual prompts.
• Hours per month - sessions times hours per session. This translates the budget into calendar time, which is often the most intuitive unit of all.
• Daily dollar cap - your budget divided by working days. A simple guardrail: if you are past this by mid-afternoon, you are running hot.

The suggested budget split, and why

The allocation panel splits your budget across three tiers of work because using one model for everything is how budgets get wasted. The default split - the majority to Sonnet for core coding, a meaningful slice to Opus for genuinely hard reasoning, and a small slice to Haiku for bulk or cheap tasks - reflects how efficient users actually work. Sonnet is the daily driver that handles most coding at a fraction of Opus's cost. Opus is reserved for the moments where reasoning is the bottleneck and its price pays for itself in an avoided rewrite. Haiku mops up the high-volume, low-stakes work where speed and cheapness matter more than depth. Spending your whole budget on Opus is the single most common way to burn through it with nothing to show for the premium.

How to make your budget go further

1. Default to Sonnet, escalate to Opus only when reasoning is genuinely the bottleneck. This alone can multiply how many prompts your budget buys.
2. Raise your cache hit rate by referencing the same files in the same order across prompts. Cached input costs about a tenth of fresh input, so this is nearly free capacity.
3. Cap your output. Output tokens cost roughly 5x input, so asking for a diff instead of a full-file rewrite is one of the highest-leverage habits you can build.
4. Trim input. Point Claude Code at file paths and line ranges rather than pasting whole modules. Half of blown budgets are oversized inputs.
5. Keep CLAUDE.md tight. It loads every session, so every line is a recurring cost against your budget.
6. Compact long sessions. A bloated session reloads its whole history each turn, quietly eating your daily allowance.

Setting a realistic budget in the first place

If you do not have a number yet, work forward from value rather than fear. The ROI of Claude Code for professional work is usually strongly positive, so an artificially low budget often costs you more in lost output than it saves in spend. A sensible approach is to set a budget you are comfortable with, run a month, reconcile the estimate against your real dashboard usage, and adjust. The planner gives you the pacing; the dashboard gives you the truth. Together they let you tune a budget that is high enough to work well and low enough to stay disciplined.

What this planner does not model

This is a planning estimate. It assumes consistent prompt size and average cache behavior, and it uses rounded per-million rates. It does not model tool-call outputs that can spike a single prompt, MCP-loaded context, long-context pricing tiers, or the exact terms of a specific plan. The suggested split is a sensible default, not a prescription - your real allocation depends on your work. Use the planner to set a target and a daily pace, then reconcile to your actual usage at month end and adjust the inputs until the estimate tracks reality.