Estimate Any LLM Bill Before You Build: Token Math for n8n Builders

You are about to wire an LLM into an n8n workflow, and the only cost guidance you can find is a pricing calculator that wants numbers you don't have and hands back a total you can't check. You can estimate llm api cost by hand with four numbers and one equation, then bake the same math into a Set or Code node so the workflow logs its own spend.

A single call costs a fraction of a cent, which feels free until you multiply by ten thousand runs a month. This walks the reproducible method end to end, with one support-reply example carried all the way to a monthly figure, so you can swap in your own numbers.

What does an LLM call actually cost?#

Four numbers decide it. To estimate llm api cost you need input tokens, output tokens, the input rate, and the output rate, and the equation is cost equals input tokens over a million times the input rate plus output tokens over a million times the output rate. One call costs a fraction of a cent.

A token is the unit both halves are billed in, roughly four characters or 0.75 words of English. The catch beginners miss is the multiplication: a call that costs $0.003 looks like nothing, but at 10,000 runs a month it is a $30 line item, and an agent that calls the model five times per run is five times that. The point of estimating is to do that multiplication before you ship, not after the first invoice.

These get you a ballpark in seconds. They are estimates; the real tokenizer is the source of truth. Source: provider docs.

One more thing the equation hides: input is not just the user's message. The system prompt, tool and function schemas, few-shot examples, and any retrieved context you inject are all billed as input on every single call. Leaving them out is the most common way an estimate comes in low.

This matters most inside an agent. A single chat turn is one call, but an agent that plans, calls a tool, reads the result, and tries again can fire the model five or ten times for one user request, and each of those calls re-sends the growing context. So the unit you estimate is not always the user request; for an agent it is the call, and you multiply by the average calls per run before you ever reach runs per month. Get that multiplier wrong and the real bill can be several times your first guess.

What are the token rules of thumb, and where do they break?#

A token is roughly four characters or 0.75 words of English, so characters divided by four gives a fast input estimate. The rule holds for English prose but breaks for code, JSON, and non-English text, which run denser, and Claude's newer tokenizer can use up to 35 percent more tokens for the same text.

Output is the expensive half. On every provider the output rate runs roughly four to six times the input rate, so a long reply costs far more than a long prompt. Claude Haiku 4.5 is $1 per million input and $5 per million output; GPT-5.4-nano is $0.20 in and $1.25 out. Cap max_tokens so a runaway answer cannot quietly blow the budget.

Estimate with chars over 4, budget with the real tokenizer. Code, JSON, and other languages run hot.

The practical consequence is a two-speed approach. Estimate with chars ÷ 4 to make a go or no-go decision in seconds, then verify the real count with tiktoken (OpenAI's o200k_base averages about four characters per token for English), a provider token-count endpoint, or a tokenizer playground before you commit a budget. The rule is a ruler, not a meter.

Exact counting is cheaper than it sounds. For OpenAI-family models, tiktoken.get_encoding("o200k_base") turns a string into the precise token list locally, with no API call, so you can audit a real prompt in a second. Anthropic and Google expose token-count endpoints that return the count for their own tokenizers. The point is not to count every call forever; it is to calibrate your ÷4 estimate once against a representative prompt, learn how far off your particular content runs, and apply that correction to the fast math from then on.

How do you estimate any LLM bill in five steps?#

Count input tokens as characters over four, estimate output tokens the same way, multiply each by its per-million rate, add them for the cost per run, then multiply by runs per month. The method never changes; only the two rates do, so you can swap any model into the same arithmetic.

Same method for any model; only the two rates change. Recompute with your own numbers.

Here is the method worked end to end, all figures modeled from published June-2026 rates. Take a support-reply workflow where each run sends about 1,500 input tokens (a system prompt, the customer message, and one retrieved doc) and generates about 300 output tokens. Step one: roughly 6,000 input characters ÷ 4 ≈ 1,500 tokens. Step two: a 1,200-character reply ÷ 4 ≈ 300 tokens. Step three, on Claude Haiku 4.5 at $1 in and $5 out: 1,500/1e6 × $1 = $0.0015 and 300/1e6 × $5 = $0.0015. Step four: $0.0030 per run. Step five: 10,000 runs a month is $30.00.

Now hold the run fixed and only change the model, and the same workflow swings about tenfold:

Read that table as a lever, not a leaderboard. The workflow did not change between rows; only the model did, and the monthly bill moved from about $2.70 to $90, a spread of more than thirty times. For a high-volume, low-stakes job like a first-pass support reply, the cheapest capable model often wins outright. For a low-volume, high-stakes job, the premium model's cost is rounding error and you should just buy the quality. The estimate is what lets you make that call deliberately instead of defaulting to whatever model you used first.

Make it reproducible in n8n: in a Code node, Math.ceil(text.length / 4) gives a quick input-token estimate and a capped figure covers output, then multiply by the two rates and write a per-run cost field. Now the workflow logs its own estimated spend, and you can watch the real cost of an automation stack instead of guessing. The pattern pairs well with a cost-control agent that acts on those numbers, and it means the per-run figure travels with the data through the rest of the pipeline.

How precise does your estimate need to be?#

Match the effort to the decision. For a go or no-go, characters over four plus the volume multiply is enough. For English prose, pad about 15 percent. For code, JSON, non-English text, or a real budget commitment, count with the actual tokenizer instead of trusting the rule.

Rough call? Use chars over 4. Real budget on code or non-English text? Count with the actual tokenizer.

Padding 15 percent for English prose is not superstition; it absorbs the tokens you tend to undercount, like the system prompt you forgot and the punctuation-heavy formatting in a structured reply. For code, JSON, or non-English text the gap is larger and less predictable, which is exactly when the rough estimate stops being safe and the real tokenizer earns its keep.

Sanity-check your method against a published total. Anthropic documents an example of about 10,000 support tickets at roughly 3,700 tokens each on Haiku 4.5 landing near $37, so your own arithmetic should land in that neighborhood when you plug in similar numbers. If it is wildly off, you probably forgot the hidden input tokens or the output half.

Then act on the number. If the modeled monthly bill is uncomfortable, the levers are right-sizing the model, caching the stable parts of the prompt, and batching, and the cheapest model for the job can be a tested cost-and-speed decision rather than a guess. The estimate is what turns "this feels expensive" into a number you can actually cut.