Function calling token cost calculator
Function (tool) calling is one of the most underestimated cost lines in an LLM app. The JSON schemas you pass — names, parameter types, and especially long natural-language descriptions — are serialized and prepended to your prompt as input tokens on every request. A few rich tools can quietly add hundreds of input tokens per call. This tool measures that hidden overhead and projects its monthly cost.
How it works
Paste the tools or functions array you send with each request. The tool serializes
and counts it using a four-characters-per-token heuristic plus a small per-function
structural allowance for the wrapping the API adds. Because definitions are re-sent on
every call (unless cached), the per-request overhead multiplies by your daily volume,
priced at your model’s input rate, to give a monthly figure. Verbose descriptions are
usually the biggest offender, and the calculator makes that cost concrete.
Where hidden tokens accumulate in real schemas
It is easy to underestimate how quickly function definitions grow. A single tool with a name, a two-sentence description, and five parameters with descriptions and enum values can easily total 150–300 tokens. Send five such tools and you are adding 750–1,500 input tokens to every single request before the user says a word.
At an illustrative input rate of $3 per million tokens, 1,000 tokens of function overhead per request at 10,000 daily requests costs:
- 1,000 tokens × 10,000 requests × 30 days = 300,000,000 tokens/month
- At $3 / 1M tokens: $900/month in overhead alone
This is not a contrived scenario — it is the real situation for production apps that pass a large tool catalogue on every call without caching.
Where the tokens actually come from
The schema the API receives is not just your raw JSON. Providers typically serialize tool definitions into a structured format (often resembling XML or a system-prompt prefix) that adds wrapping characters. The breakdown for a typical tool might look like:
- Tool name and description: 40–120 tokens
- Each parameter name + type: 5–15 tokens
- Each parameter description: 15–60 tokens depending on length
- Parameter enum values: 1–3 tokens each
A description that reads "The user's email address" costs far fewer tokens than one that reads "The primary email address the user registered with, used to send account notifications, password resets, and marketing communications, which must conform to RFC 5322 format". Both achieve the same result in most models; only one is expensive.
Practical optimisation strategies
Trim descriptions aggressively. Models are good at inferring parameter intent from names and types; you rarely need a sentence explaining what an email field does.
Route tool subsets. If your app has 20 tools but a given user message only plausibly needs 3 of them, pre-classify and send only those 3. This cuts both token cost and tool-selection confusion.
Enable prompt caching on the tools block. If your tool definitions change rarely, most providers allow you to mark the tools array as a cacheable prefix. The cache hit re-uses a previously computed KV representation and charges a fraction of the input token rate. This can be the single highest-leverage optimisation for a high-volume function-calling app.
Avoid redundant schemas. If several tools accept the same fields (like a user_id or date_range), consider whether one general-purpose tool can replace three specific ones. Fewer tools means fewer schema tokens across the board.