Built-in tools are not free sidecars.
Cost note · 12 May 2026
A lot of teams still think of built-in tools as "just part of the model." That framing is getting expensive. In 2026, web search, file search, and code interpreter are becoming distinct line items with their own call charges, storage charges, and token behavior. If you do not split them out, your model dashboard will lie to you.
What changed
OpenAI's pricing now makes the separation explicit. Web search has tool-call fees and search-content token costs. File search has tool-call pricing and storage pricing. Code Interpreter is priced by container size. On top of that, the model tokens used while these tools are active are still billed at model rates. That means one user interaction can stack multiple cost layers.
Why teams miss it
The UI experience still feels unified: ask a question, get an answer. But behind the scenes, the workflow may include search calls, search content tokens, containerized code execution, or hosted retrieval. When all of that gets dumped into one "AI spend" bucket, optimization becomes guesswork.
The new budgeting mistake
Teams cap model output but leave tools unconstrained. They count token spend but not tool-call volume. They notice rising cost and assume they need a cheaper model when the real issue is that every answer is now doing search or spinning up code execution.
What to separate in reporting
- Web search tool calls
- Search content tokens
- File search calls and storage
- Code Interpreter container usage
- Model tokens consumed while using tools
What this changes operationally
Tool selection is now a budgeting problem, not just a capability problem. Search should be explicit. Retrieval should be justified. Code execution should be scoped to the workflows that truly need it. Once tools have their own economic weight, agent design starts to look more like platform engineering and less like a prompt exercise.