OpenAI Agents API Beta: The New Gateway Bypass Operators Need to Account For
OpenAI's Agents API beta ships a dedicated session harness under client.beta.agents that doesn't route through /v1/chat/completions. For teams using AI gateways, this means billing blind spots, missing audit trails, and a new API key scope to manage.
Archive item produced with AI assistance from the cited source and published without individual review. Editor of record: Joe Werner.

OpenAI's Agents API entered public beta on September 10. The announcement leads with developer ergonomics — managed sessions, automatic context compaction, environment provisioning. What it buries in the docs is more operationally significant: this API does not go through /v1/chat/completions.
If your team routes AI traffic through a gateway, that gateway is currently blind to every Agents API call your developers make.
A new namespace, a new routing path
The Agents API lives under client.beta.agents.sessions, a completely separate SDK namespace from the standard chat or Responses API. Every request requires the OpenAI-Beta: agents=v1 header, and the API key must carry two scopes that didn't exist before: api.agents.read and api.agents.write alongside the existing api.responses.write for model inference.
This matters for gateway operators for a concrete reason. Most AI gateways — including TheRouter — proxy requests by intercepting calls to OpenAI-compatible endpoints: /v1/chat/completions, /v1/responses, and similar paths. The Agents API doesn't use those paths. A session created via client.beta.agents.sessions.create(...) goes directly to OpenAI's managed harness infrastructure, bypassing your configured base URL.
The practical consequence: a developer who switches from a direct Responses API call to the Agents API will drop off your usage dashboard, your spend tracker, and your audit log, simultaneously and silently.
Three billing streams from one task
Standard model API calls produce one billing event: tokens in, tokens out, at the model rate. The Agents API can produce three:
- Model inference: billed at the selected model's standard API rate (e.g., GPT-6 Astra rates apply when
model: "gpt-6-astra"is set) - Built-in tool use: web search, code execution, file operations, and MCP connections each have their own line-item rates under OpenAI's standard tool pricing
- Container compute: when
environment.typeis set toopenai_hosted, the sandbox charges per-minute container rates on top of model and tool costs
A single sessions.create() call can accumulate all three in one shot. If you're reconciling costs at the month end, the model-rate charges look normal, but the container and tool charges appear separately and are not labeled with the session task or the team member who initiated it.
The workaround today is to require developers to use self-hosted environments (environment.type: "self_hosted") so the only billable component flowing to OpenAI is model inference — which can then be routed through your gateway in the underlying model calls. OpenAI's docs note that self-hosted mode lets you choose your own sandbox providers (Blaxel, Cloudflare, Daytona, E2B, Modal, Vercel, and others listed in the API reference).
All three major providers have now left /v1/chat/completions behind
This isn't only an OpenAI story. Anthropic launched its Managed Agents API in April 2026 with its own beta header (managed-agents-2026-04-01) and its own endpoint structure. Google released Gemini Enterprise Workflow Agents earlier this year on a similarly distinct surface. Now OpenAI has joined them.
The pattern is the same across all three: a dedicated session or workflow harness that manages state, context, and tool execution, and that deliberately sits outside the standard completion endpoint. The routing consequence is identical across providers: if you rely on intercepting /v1/chat/completions or its OpenAI-compatible equivalent, you're routing the API surface from 2024, not the one that will carry production agent workloads in 2027.
The router view matters here because you can see the shift across all three at once. A team that uses Claude Code through TheRouter is already operating outside the standard completion path in some ways — Claude Code's gateway integration routes the underlying API calls, but the agent session management layer above it is provider-controlled. The Agents API formalizes and deepens that separation.
What changes for gateway operators today
The immediate decisions are scoped:
API key management: Agents API sessions require the api.agents.read and api.agents.write scopes. If you're issuing API keys to team members through an admin surface, you need to decide whether to add these scopes to existing keys or create separate Agents-API-only keys. Separate keys give you a cleaner audit signal at the cost of more credentials to manage.
Environment policy: For the period when you can't intercept Agents API traffic in your gateway, push teams toward environment.type: "self_hosted" with a sandbox provider they can configure. The underlying model calls in that mode will go through whatever base URL the sandbox's OpenAI client is configured with — that's your entry point for routing.
Cost attribution: Add the Agents API's container pricing page to your monthly billing reconciliation checklist. Container charges don't appear on the same line as model tokens. Teams running hosted sandboxes for multi-hour tasks will see meaningfully different bill shapes than their Responses API usage.
Scope for watch: OpenAI has flagged that the Agents API is in public beta with OpenAI-Beta: agents=v1. Beta status means the endpoint contract can change without the standard deprecation cycle. Budget for monitoring changes in the SDK changelog and the API reference.
What TheRouter users should watch
For teams already routing OpenAI traffic through TheRouter: your existing routing configuration continues to work for chat completions and the Responses API. The Agents API requires direct OpenAI credentials with the new scopes — it can't be transparently proxied at this point.
Watch the OpenAI API changelog for when the Agents API moves out of beta and whether OpenAI-compatible routing surfaces emerge for it. The parallel to watch on the Anthropic side is the ant beta:sessions connect command released alongside the September 10 platform update, which adds terminal-level attachment to Managed Agents sessions — a sign that both providers are building tooling for operators to observe agentic sessions outside the standard API event stream.
The practical guide to what TheRouter routes today: anything that flows through /v1/chat/completions, /v1/responses, or compatible endpoints — model inference, streaming, fallback, cost accounting. Agentic session harnesses from any provider require their own credential surface and their own observability strategy.

OpenAI API Key Creation Governance: How Service-Account-Only Enforcement Closes the Shadow-Routing Gap
OpenAI's new org-level key creation controls let admins enforce service-account-only, project-keys-only, or disable all key creation. The first structural control that prevents shadow routing via personal API keys.

OpenAI Now Enforces API Key Expiration at the Org Level: What Gateway Operators Must Audit Today
OpenAI now lets admins enforce a maximum key lifetime at the org or project level. Existing keys are not retroactively shortened, but every new key created after the policy must expire within the limit — your gateway is the riskiest place to hold a long-lived key.

OpenAI Splits the Rate-Limit 429: What 'slow_down' vs 'server_is_overloaded' Mean for Your Retry Policy
OpenAI now returns distinct error codes for two previously identical 429s — traffic that ramps too fast gets slow_down, model saturation gets a 503. Your retry logic must treat them differently, and most AI gateway clients currently don't.