Token Budget Planner

Works backwards from a monthly cost ceiling to the prompt you can afford on every request.

Monthly cost ceilingThe number you are not allowed to go past

$/mo

Requests per monthWhat you expect to serve inside that ceiling

ReserveShare of the ceiling held back for spikes and retries

Output tokens per requestBudgeted first — output is the expensive half

Fixed input overhead per requestSystem prompt and tool schemas — billed on every call

Your prompt todayVariable input tokens per request, for comparison

Input rateUS dollars per 1,000,000 tokens. Example figure — replace it with yours.

$/1M

Output rateUS dollars per 1,000,000 tokens. Example figure — replace it with yours.

$/1M

Prompt budget per request

7,767 tokens

Variable input, on top of the 900 fixed overhead tokens. Roughly 31,067 characters of English. Your prompt today is 4,767 tokens under.

Usable budget after a 20% reserve: $1,600 / month
Budget per request: $0.03
Output cost per request: $0.0060
Fixed overhead cost per request: $0.0027
Left for the variable prompt: $0.02
Prompt tokens that buys: 7,767
Approximate characters at 4 chars/token: 31,067
Total tokens per request at budget: 9,067
Cost per request as you run today: $0.02
Requests the ceiling supports as you run today: 90,395

What this assumes: the budget is spent evenly across requests — no request is allowed to be larger than any other, which is not how a real workload behaves and is why the reserve field exists. Output is budgeted before input, because output is usually the expensive half and is the term you should fix first. The character estimate uses a flat 4 characters per token, a rough English rule of thumb and nothing more: code, JSON and non-Latin scripts all tokenise differently, sometimes by a factor of two. Count with a real tokeniser before you commit. A month is 30 days, and no cache discount is modelled.

Working backwards from the ceiling

Most prompt design starts with what you want to say and discovers the cost afterwards. This runs the other way: a ceiling divided by a request count is a per-request budget, and once the output and the fixed overhead are subtracted, whatever is left is the prompt you can afford. It turns an argument about whether the system prompt is too long into a number.

The order of subtraction is deliberate. Output first, because it is usually billed at several times the input rate and because you can rarely promise it will be short — an answer that gets truncated does not save money, it gets regenerated. Fixed overhead second: the system prompt, the tool schemas, the formatting instructions. These are the tokens you pay on every single call forever, and they are the ones that quietly grow, because adding a tool or a rule feels free at the time. What is left is the retrieved context and the user's own input, which is the part everyone thinks of as "the prompt".

The reserve is not padding. Retries, cache misses, a heavier day, a prompt-injection guard that re-runs a request — a budget planned to exactly 100% of the ceiling is over it in the first bad week. Twenty percent is a starting point, not a recommendation; set it from how spiky your own traffic already is. And treat every token count here as approximate until a real tokeniser confirms it: the difference between your estimate and the bill is usually the chat template, the tool schemas and the system prompt nobody counted.

Token Budget Planner

Working backwards from the ceiling

The reasoning behind this

Related tools