OpenAI Agents API pricing: what building an agent actually costs in 2026

So what is the "OpenAI Agents API," exactly?

Worth untangling first, because "OpenAI Agents API" points at a few related things that shipped in stages.

It started in March 2025, when OpenAI launched the Responses API and the open-source Agents SDK together, along with the first built-in tools. The Responses API is the primitive: a superset of Chat Completions that models generate through and that every hosted tool plugs into, and the eventual replacement for the older Assistants API. The Agents SDK is the orchestration layer on top, handling the agent loop, handoffs, and guardrails in your own app.

Then in October 2025 came AgentKit, a visual layer for people who didn't want to write the loop by hand: Agent Builder (a drag-and-drop canvas), the Connector Registry, ChatKit (an embeddable chat UI), and expanded Evals. More recently, OpenAI added a managed Agents API runtime that runs the loop for you on its own Codex harness.

One important thing to know before you build on any of this: OpenAI is winding down Agent Builder and Evals. From November 30, 2026 they won't be available, and OpenAI now points you to the code-first Agents SDK or to Workspace Agents in ChatGPT instead. In the docs, Agent Builder and Evals already sit under a "Legacy APIs" heading. So if you're picking a surface today, the durable ones are the Responses API, the Agents SDK, and the managed Agents API, not the no-code canvas.

Here's the good news for your budget: none of these layers carry their own fee. OpenAI is explicit, in the launch post and again in the AgentKit announcement, that the Responses API and AgentKit tools are "not charged separately" and "included with standard API model pricing." You pay for the model calls they make, and for the tools those calls invoke. Which is exactly why the pricing question is really three questions.

The pricing model: there's no "agent" line item

Building an agent stacks three meters, and your bill is the sum of all three:

1. Model tokens. Every turn of the loop is one or more model responses, and each one bills input and output tokens. This is usually the biggest line.
2. Hosted tool calls. Web search, file search, and Code Interpreter are built-in tools that each add a surcharge on top of the tokens they consume.
3. Containers and storage. Code Interpreter runs in a container that's billed by the minute, and file search keeps your documents in vector stores billed per GB per day.

The trap is thinking of an agent as "a model call with a price." It's not. A web-search-heavy agent pays $10 per 1,000 searches and the model tokens those search results consume when they're read back into the context. Get all three meters clear in your head and the pricing page stops being confusing.

What the models actually cost

Let's start with the biggest meter. These are the standard-processing rates from the OpenAI API pricing page, per 1M tokens, checked on September 11, 2026. "Long context" kicks in above 272,000 input tokens and runs at roughly double.

A few things worth calling out. First, gpt-5.6-sol is on promotional pricing through November 21, 2026, marked down from its regular $5.00 input / $30.00 output. Second, cached input is a tenth of the fresh rate, and prompt caching applies across agent workflows, which matters a lot when your agent re-sends a growing context on every turn. Third, models released on or after March 5, 2026 carry a 10% uplift on data-residency endpoints. And if you're building a voice agent, note that realtime audio is metered separately again: OpenAI's realtime API bills voice sessions by the minute on top of everything here.

If you're weighing this against other providers, our OpenAI API vs Anthropic API breakdown covers the same math for Claude, and it's worth noting Anthropic and Google don't charge a long-context tier at all, so the 272K cliff is an OpenAI-and-xAI thing. If you're shopping model-by-model for agent work, our roundup of the best AI agents is a good next read.

What the hosted tools cost

This is the meter people forget, and it's the one that makes agents different from a chatbot. The built-in tools charge per call, on top of the tokens they generate.

Two details save real money here. Web search has a return_token_budget knob that caps how many result tokens flow back into the model, and file search (which runs over embeddings in a vector store) lets you limit the number of retrieved results, which OpenAI's own docs say "can help reduce both token usage and latency." Since every retrieved chunk becomes model input tokens, trimming results trims two meters at once.

Computer use is the interesting exception. The current docs no longer center a dedicated per-call rate for it; the recommended path for gpt-6-astra is a code-execution loop where the model writes a script your own sandbox runs. So you pay model tokens per turn, plus whatever your execution environment costs, and there's no tidy hosted-tool figure to quote.

The loop is the multiplier

Here's the number that dwarfs everything above. An agent run is not one model call, it's a loop of them. OpenAI's own diagram makes it concrete: a Triage Agent calls POST /v1/responses, hits a guardrail, hands off to a CRM Agent, which calls the model again and then fires a tool. That's already several billable model calls for one task, and OpenAI's computer-use example caps its sample loop at 20 responses before it aborts.

Now stack context growth on top. Each tool call returns output (search results, a database row, a file listing) that gets fed back into the next call's prompt. So the loop doesn't just multiply calls, it inflates the token count of every later call. One developer put it more bluntly than any docs page:

"I was spending $200/day running agents with tool calls. The problem: tools return huge JSON (search results, DB queries, file listings). Each response bloats context. By turn 10, you're paying for 100k+ tokens on every LLM call."

chopratejas, Hacker News

This is why a per-token price tells you almost nothing about what an agent costs. The real unit is the whole run, retries and all:

"the cost isn't just 'how many tokens did this call use,' its 'how many tokens did this entire user action consume across all the agent loops, retries, tool calls, and embeddings.' most observability tools show you the LLM call as one flat span... or see that the agent looped 4 times because the first 3 outputs failed validation."

dkowalski, Hacker News

The lever you actually control here is reasoning effort. On reasoning models you set reasoning: { effort } from low to xhigh, and higher effort means more tokens and longer loops. Deep research runs, OpenAI notes, "can run for several minutes" tapping "hundreds of sources." Great for a research agent; expensive as a reflex.

Four ways to run an agent, four ways to get billed

Where the loop runs decides who racks up the calls, and OpenAI now offers four runtimes:

• Agents API runs the loop for you on a managed Codex harness, with automatic context compaction, multi-agent orchestration, and an optional hosted sandbox. Convenient, and the compaction is a genuine cost help, but you're still paying for every model call the harness makes.
• Agents SDK runs the loop inside your application. You own deployment, storage, and approvals; the runner handles the agent loop and handoffs. Most control, most of the token accounting is yours to watch.
• Responses API is building from scratch: you call the model directly and wire up your own orchestration and history.
• ChatKit is the embedded chat front-end you drop into your product.

None of these change the per-token or per-tool rates. They change who is responsible for how many times the loop fires, which in practice is the thing that moves your bill.

The no-code option, Agent Builder, is worth a screenshot because it makes the multi-agent shape visible, but remember it's on the way out.

That customer-service flow (start, jailbreak guardrail, classification agent, an if/else that routes to a return, retention, or information agent, then a hallucination guardrail) is a good picture of what a real support workflow needs. It's also a good picture of how many model calls one ticket can trigger. Every node that says "agent" is at least one more POST /v1/responses.

Service tiers: Batch, Flex, Standard, Fast

One more dial before the worked example. OpenAI runs four processing tiers, and they swing token cost by up to 4x:

• Standard is the baseline.
• Batch is 50% off, async over 24 hours. gpt-5.6-sol drops to $2 input / $10 output.
• Flex matches Batch pricing for slower, occasionally-unavailable requests.
• Fast mode (renamed from "Priority" on July 30, 2026) is roughly 2x Standard. gpt-5.6-sol on Fast is $8 input / $40 output.

For a live support agent you're almost always on Standard or Fast, because a customer is waiting. For overnight jobs (summarizing yesterday's tickets, backfilling a knowledge base) the Batch API is the obvious win. Tool-call prices don't appear to change by tier, so this dial only moves the token meter.

A worked example: what a support agent actually costs to run

Enough theory. The honest way to think about agent cost is to run your own numbers, because the loop length and token growth are wildly different between a one-shot FAQ bot and a multi-agent workflow that browses and updates a CRM. Plug in your own volume below.

Play with it and the pattern jumps out: the loop length and input-token growth swing the number far harder than which model you pick. Halve the calls per conversation and you roughly halve the bill. That's the real optimization surface, and it's also the part OpenAI's pricing page doesn't put a sticker on.

What people are actually saying about the cost

The sharpest critique of the built-in tools is that you're paying a premium for something that's a thin wrapper over the raw API. One developer rebuilt a paid "AI visibility" product to show the markup:

"the hosted AI-search-visibility tools are super expensive. They charge $200–$1000/mo for what is, fundamentally, a loop over the OpenAI Responses API and Anthropic Messages API with web_search enabled, plus citation parsing... a typical weekly run costs ~$0.40 in API spend."

zipvoila, Hacker News

That cuts both ways. Yes, the raw API can be dramatically cheaper than a packaged product if your use case is a simple weekly loop. But "a loop over the Responses API with web_search enabled, plus citation parsing" is also a real engineering project with a real maintenance tail, and for a lot of teams the packaged product exists precisely so nobody has to own that loop at 2am. The trick is knowing which side of that line your problem falls on.

Try eesel for support, and skip the loop math entirely

Here's the honest framing. The OpenAI Agents API is infrastructure. It's the raw material you assemble an agent from: tokens, tools, a loop you orchestrate, and an eval and monitoring setup you build yourself. That's the right choice when the agent is your product and you want control down to the token.

eesel is the other end of that trade: not infrastructure, but a ready-to-work teammate. You hire the AI support teammate, plug it into your helpdesk, and it arrives already knowing your company from your past tickets and help center. There's no loop for you to meter, because the pricing is flat: $0.40 per ticket handled, billed on the conversation, not on how many internal model calls or tool hops it took to resolve it. That last part is the whole point of the earlier loop discussion. The unpredictable meter is the vendor's problem, not yours.

And if it's the programmatic control that drew you to the Agents API, eesel keeps that too. There's a real public CLI (@eesel/cli) plus an MCP server, webhooks, and network access, so you can connect an integration, edit the agent's standing instructions, list and approve human-in-the-loop actions, and read the run-by-run activity log from a terminal or a script. The docs literally say "everything on this site can be done from the terminal," and coding agents like Claude Code and Cursor can drive it directly. You get the agent-friendly surface without building and babysitting the agent itself.

Before you commit to running a raw agent for customer service, run the number for your own volume in the estimator above, then decide whether the loop is a thing you want to own. If it isn't, start a free trial and let the teammate do the job.