Tool Schema Token Cost
Paste your tool definitions and see the per-call token overhead, broken down tool by tool.
2 definitions, ~317 estimated tokens sent on every call. Read as a bare array of tool definitions.
- Definitions found
- 2
- Total, indented
- ~317 tokens
- Total, compact
- ~317 tokens
- Cost of the indentation
- ~0 tokens per call · $0 per month
- Per call
- $0.00095
- At 200,000 calls/month
- $190.00 per month
- Largest definition
- start_return — 51.6% of the total
- search_orders
- ~153 tokens · 48.4%
- start_return
- ~164 tokens · 51.6%
usage object on an actual API response: that is what you are billed on, and it includes chat-template wrapping this model cannot see. Schemas are counted as the JSON you pasted, serialised the way you chose. Providers do not send your JSON verbatim — they wrap each definition in their own template before it reaches the model, so the real figure is higher, by an amount that differs per provider and per model. Treat this as a floor and a comparison tool: the ranking between your tools, and the difference between two versions of one schema, are reliable even when the absolute number is not. Definitions are assumed to be sent on every call, which is true unless you attach tools conditionally.The overhead nobody puts in the estimate
Tool definitions are input tokens. They are re-sent on every single call, including the calls where the model uses no tool at all, and they are invisible in the place people look — the prompt they wrote. A set of eight moderately documented tools can easily exceed the system prompt it sits next to, and it grows every time someone adds a capability and nobody removes one.
Three things this makes visible. The indentation line is the cheapest fix in the list: if you build the request by hand with JSON.stringify(x, null, 2) you are paying for whitespace on every call, and most SDKs serialise compactly anyway. The per-tool table tells you which description is doing the damage — descriptions are usually the bulk, not the parameter schemas. And the monthly figure answers the question that actually matters: whether a rarely used tool earns the tokens it costs to keep on the list.
What this deliberately does not do is tell you to cut descriptions. Descriptions are what the model routes on; a terse schema is cheaper per call and more expensive per outcome if the model starts picking the wrong function. The useful move at scale is usually not shorter definitions but fewer of them per call — attach the four tools that fit the current step rather than all twenty — and the number above is how you decide whether that engineering is worth doing. Check the result against usage.prompt_tokens on one real call before you plan around it.