Budgeting tokens before you send a prompt

The first time a team argues about the cost of a prompt, it is usually because intuition pointed the wrong way. Intuition says “use the cheaper model”. The invoice says something else: what decides the bill is not the price per million tokens, but how much you asked it to generate.

Two costs, not one price

The cost of a single call is the sum of two parts: the input tokens you send, and the output tokens the model returns. They are priced differently — output is typically three to four times more expensive.

That single fact explains most cases of "we used the cheap model and it cost more". Generating a long answer on a low-cost model can easily outspend a short answer on a premium one, because the variable moved from unit price to length.

Long input and long output are different problems

Split requests by which side dominates and budgeting becomes straightforward:

• Input-dominated: translation, summarisation, reviewing a long document. Cost is almost entirely determined by what you paste in, and the output price barely participates.
• Output-dominated: generation, expansion, writing code. Cost is set by the length you ask for, and the input price barely participates.

Deciding which one you have takes a single question: for this task, is the long side written by me or by the model?

A process you can finish in thirty seconds

1. Paste the whole prompt into the token estimator — system instructions and examples are input tokens too.
2. Read the estimate knowing the heuristic: roughly one token per CJK character, one per four characters elsewhere.
3. Switch between candidate models and compare both the input and output numbers.
4. Spend the expensive model on the high-value call only. For a batch of repetitive tasks, routing the simple ones to a low-cost model is usually enough.

Treat the estimate as a yardstick, not an invoice

Any estimate computed in a browser is a heuristic, because providers do not publish their tokenizers and no two are identical. Cache hits, batch discounts and long-context pricing tiers all push the real number away from the list price.

The usable signal is relative: the ratio between models for the same input is stable, while the absolute value drifts. Use it as a measuring stick, not a bill.

Estimating tokens and both costs before sending is the cheapest step in the whole workflow. It does not change model quality, but it changes which prompt goes to which model — and that is usually a bigger saving than switching models.