GPT-5.4 Tool Search and Long-Context Pricing: What the 272K Line Means for Agents

OpenAI released GPT-5.4 and GPT-5.4 Pro on March 5. The headline features are a context window of about 1.05 million tokens and built-in computer use. For anyone running agents against MCP servers, two quieter changes matter more: tool search, and a price line at 272,000 input tokens.

Tool search lets the model load tool definitions when it needs them, instead of receiving every schema on every call. The price line means a request just over 272K input tokens costs roughly twice as much as one just under it. Both say the same thing: what you send on every call is now a design decision with a price.

I read OpenAI's announcement, the model and pricing pages, the changelog and the tool search guide. Every number below is reported by OpenAI unless I say otherwise. I have not run GPT-5.4, and I have not seen an independent measurement of tool search.

GPT-5.4 and GPT-5.4 Pro: specifications and API pricing

Specification	GPT-5.4	GPT-5.4 Pro
Context window	1,050,000 tokens	1,050,000 tokens
Maximum output	128,000 tokens	128,000 tokens
Input, per million tokens	$2.50	$30.00
Cached input	$0.25	Not listed
Output, per million tokens	$15.00	$180.00
Input above 272K	$5.00	$60.00
Output above 272K	$22.50	$270.00
APIs	Responses, Chat Completions	Responses only
Reasoning effort	none (default) to xhigh	medium, high, xhigh

Source: OpenAI's model pages, the March 5 changelog and the pricing page as of March 6, 2026. Standard tier; Batch and Flex are half these rates.

By my arithmetic, GPT-5.4 costs 43% more per input token than GPT-5.2 ($1.75) and 7% more per output token ($14), and GPT-5.4 Pro costs twelve times GPT-5.4 on both. OpenAI's case is that GPT-5.4 needs fewer tokens per task, which only your own workload can confirm. It also warns that some Pro requests take several minutes.

The engineering cost of tool schemas

Every tool an agent can call reaches the model as a name, a description and a JSON schema for its parameters. Before GPT-5.4, OpenAI's API put all of those definitions in the prompt up front. OpenAI's announcement says that for systems with many tools this could add thousands, or tens of thousands, of tokens to every request. That overhead is paid three ways:

Tokens on every step. An agent pays for its tool list on each model call, not once per task.
Latency. OpenAI says the extra definitions slow responses, and a multi-step task pays that on every step.
Selection. Every near-duplicate tool is another chance to pick the wrong one. OpenAI describes the old approach as crowding the context with information the model might never use.

How GPT-5.4 tool search works

You add {"type": "tool_search"} to the tools array and mark functions, namespaces or whole MCP servers with defer_loading: true. The model starts with a lightweight list. For a namespace or an MCP server, it sees only the name and description. When it needs a tool, it searches, and the loaded definitions are appended at the end of the context, so the cached prefix of the prompt survives.

In hosted mode, OpenAI searches the deferred tools you declared. In client mode, the model emits a tool_search_call, your code decides what to load, and you return the definitions. OpenAI suggests client mode when the tool set depends on the tenant, the project or another system you control. If your code returns tools that were not in the original request, the guide says to validate the schemas carefully and expose only trusted definitions.

OpenAI gives one quantified result. On 250 tasks from Scale's MCP Atlas benchmark, with all 36 MCP servers enabled, putting the servers behind tool search "reduced total token usage by 47% while achieving the same accuracy". Read the claim as written: the same accuracy with fewer tokens. The announcement also says agents choose the right tools more reliably, but I found no number for that part.

What tool search changes in agent design

Descriptions become routing. The model decides what to load from a namespace or server description. A vague description now produces a tool that is never found.
Group your tools. OpenAI says its models were trained mainly to search namespaces and MCP servers, and suggests fewer than 10 functions per namespace. A single deferred function keeps its name and description visible, so the saving there is mostly the parameter schema.
Keep the loaded set stable. Changing which tools are loaded breaks the cache from that point on.
Treat loading as a trust decision. A tool definition is text the model follows. Loading definitions at runtime moves that decision to runtime as well.
Leave some tools out entirely. The MCP Apps extension released in January lets a server mark a tool as app-only, so the host never puts it in the model's list.

How GPT-5.4 long-context pricing works

GPT-5.4 accepts about 1.05 million tokens, but the listed prices apply only to prompts under 272K input tokens. Above that, OpenAI says prompts are "priced at 2x input and 1.5x output for the full session", for standard, batch and flex. I read "full session" as the whole request, not just the tokens past the line. Cached input doubles too, from $0.25 to $0.50.

The number has a history. When GPT-5 launched in August 2025, OpenAI said its API models accept at most 272,000 input tokens, with up to 128,000 for reasoning and output, inside 400,000 in total. GPT-5.2's model page lists the same 400,000 and 128,000. As I read it, the listed price covers the input range the GPT-5 family already had, and only the new room costs more.

A worked example: one agent turn on each side of the line

This is my own arithmetic with illustrative numbers, not a measurement. An agent is 250,000 tokens into a long task. Its MCP servers expose 120 tools at about 250 tokens each, which is 30,000 tokens of definitions. The turn produces 4,000 output tokens. The second row assumes tool search cuts the definitions in context to 5,000 tokens.

Turn (illustrative)	Input tokens	Rates applied, per million	Cost of the turn
All 120 tools loaded	280,000	$5.00 in, $22.50 out	$1.49
Tools behind tool search	255,000	$2.50 in, $15.00 out	$0.70

Source: my arithmetic at OpenAI's standard list prices, uncached.

The same turn costs about 2.1 times as much with the full tool list. At the standard rate, the extra 25,000 tokens would cost about six cents. Crossing the line costs the rest, because the higher rate applies to everything. Caching lowers both rows but leaves the ratio close to two, since cached input doubles past the line as well.

Agents drift over this line without anyone deciding to. Tool outputs accumulate, and a loop that started at 50,000 tokens can pass 272,000 twenty steps later, carrying the tool list on every one of those steps. GPT-5.4 also ships with native compaction for longer-running agents, and I would use it to keep that tail under the line.

What long-context pricing should change in your prompts

There is a second reason to stay under the line: recall falls with length. These are OpenAI's results on its own MRCR v2 test, with eight needles to find.

Input length	GPT-5.4	GPT-5.2
4K to 8K tokens	97.3%	98.2%
64K to 128K	86.0%	85.6%
128K to 256K	79.3%	77.0%
256K to 512K	57.5%	Not reported
512K to 1M	36.6%	Not reported

Source: OpenAI's GPT-5.4 announcement. Vendor-run, at xhigh reasoning effort.

Past 272K you pay about double for a model that, on OpenAI's own test, finds fewer of the needles. I would still use the large window for work that needs one connected view, such as a whole codebase. For questions over a document collection, I would keep retrieval: it costs a fraction, and the far end of the window is where OpenAI's own recall figures are weakest.

For everything else, put stable content first so the cached prefix holds, keep fixed overhead such as tool lists small, and watch input size at the 95th percentile. The average will look fine long after the tail has crossed.

Where the schema tax lands: the orchestrator

In a multi-step agent, the orchestrator is the call that runs on every step, and it is usually the one holding the tool list. That is where a schema tax compounds. On Auto-RAG and MerlinX, I found the orchestrator model was 75% of workflow cost. A cheaper orchestrator was then shown on a frozen evaluation suite, at 95% confidence, to be not worse than the model it replaced. The rollout cut cost per conversation by 73% across 840 agents, with no measurable quality loss.

I would hold tool search to the same standard. OpenAI's 47% comes from MCP Atlas, and your tool set is not MCP Atlas. The token saving is easy to measure. The accuracy is the part that needs a frozen suite.

Built-in computer use, for when nobody wrote a tool

GPT-5.4 is OpenAI's first general-purpose model with native computer use. Through the Responses API computer tool, it reads screenshots and returns mouse and keyboard actions for your harness to run. OpenAI reports 75.0% on OSWorld-Verified, against 47.3% for GPT-5.2 and a human baseline of 72.4%. OpenAI's own guide says to run it in an isolated browser or VM, keep a human in the loop for high-impact actions, and treat page content as untrusted. I would count that as part of the specification.

Computer use is for when nobody wrote the agent a tool. Tool search is for when somebody wrote it too many.

What I would test before moving agents to GPT-5.4

Cost per task, not per token. Run the same frozen suite on GPT-5.2 and GPT-5.4 and compare total spend.
Tool search on your own servers. Measure tokens, accuracy and wrong-tool calls with and without deferred loading, and count how often the model fails to search when it should.
The 272K boundary. Send one request just under the line and one just over, then read the bill, so you know how "full session" is applied.
Cache hit rate. Confirm that loading tools mid-task keeps the prefix cached, as OpenAI says it should.
Confirmation points for computer use. Decide which actions need a human before the first run.

GPT-5.4 can read about a million tokens. The pricing page would prefer you sent 271,999.

Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and the cost of running agents in production.