OpenAI's Agents API vs Anthropic's Computer Use — Production Limits

OpenAI and Anthropic now both offer hosted-agent surfaces in their respective APIs. OpenAI shipped the Responses API and the Agents Python/TypeScript SDK in March 2025; Anthropic shipped Computer Use in public beta in October 2024 and has been iterating it through the Claude 3.5/3.7/4 model line since. The two surfaces look superficially similar — both let a model invoke tools, pause for human input, and run multi-turn agentic workloads — and have very different production characteristics. This piece is a working engineer’s comparison against the published rate-limit and quota documents, the SDK source, and our own production-side notes.

We are not interested in which surface is “better.” We are interested in which surface is the right answer for which kind of workload, and in what each one’s production limits actually are.

The surfaces in one paragraph each

OpenAI’s Agents stack is the Responses API (the stateful sibling to Chat Completions) plus the openai-agents SDK. The Responses API holds conversation state server-side via a previous_response_id chain, exposes hosted tools (web_search, file_search, code_interpreter, mcp, and the various computer-use tools), and supports background mode for long-running tasks. The Agents SDK wraps the Responses API with a runner loop, structured handoffs, guardrails, and the Trace envelope that feeds the OpenAI dashboard.

Anthropic’s Computer Use stack is a tool-set exposed via the Messages API (computer_20250124, text_editor_20250429, bash_20250124, and the model-specific variants) plus the claude-agent-sdk (and the AgentKit-style harnesses around it). The pattern is “give Claude a screenshot and a typed action vocabulary; let it click, type, scroll, and screenshot until the goal is done.” Tool execution is the user’s responsibility — Anthropic provides reference Docker containers; the production-grade runtime is the integrator’s problem.

The two surfaces start at the same conceptual level (a model with tools) and diverge sharply in where the runtime lives.

Rate limits: the numbers as of late 2025

The published rate limits — visible in the rate-limit dashboards of both providers — are the load-bearing facts most production planning misses.

OpenAI Agents (Responses API). Rate limits are tied to the underlying model the Responses API call routes to. For Tier 4 and Tier 5 accounts on gpt-4o-class models, you are looking at request-per-minute limits in the thousands and token-per-minute limits in the high-six-figure to low-seven-figure range. The Responses API counts each tool turn against your RPM/TPM budget on the underlying model, so an agent loop with ten tool calls is ten RPM events plus their combined TPM. Background mode does not change the budget; it changes when the budget is spent.

The hosted-tool side has its own quotas. web_search is capped by your search-tool tier (the per-minute cap is published in the dashboard and is materially tighter than the underlying model’s RPM). code_interpreter is capped on container-minutes per organization. computer_use_preview is in limited beta with explicit usage caps that vary by account.

Anthropic Messages with Computer Use. Rate limits are the standard Messages-API limits tied to your usage tier — Tier 4 accounts on Claude Sonnet/Opus see RPM in the thousands and TPM in the high-six-figure range, with output-token budgets that are tighter than the input-token budgets. Computer Use does not have its own rate-limit envelope; it consumes the parent Messages-API budget like any other tool call. Each turn that the agent takes is a Messages request; a 50-step Computer Use task is 50 Messages requests against your tier limit.

The number that matters for production planning, in either case, is not the published TPM ceiling. It is the effective requests per concurrent user-session. A Computer Use loop on Claude that runs for an hour against a single user can easily consume 200-400 Messages requests. An OpenAI Agents loop with hosted tools is similar. Multiply by concurrent sessions and the ceiling that matters becomes the per-organization RPM, not the per-model TPM.

Tool-execution semantics

The most important difference between the two surfaces is where tools run.

OpenAI’s hosted tools run on OpenAI’s infrastructure. When the Responses API decides to call web_search, OpenAI runs the search. When it calls code_interpreter, OpenAI runs the container. When it calls a user-defined function, the API returns a tool-call object and waits for the user to invoke responses.submit_tool_outputs (or agents.run.continue) with the result. The mcp tool type routes the call to a user-specified MCP server, but the routing decision lives on OpenAI’s side.

Anthropic’s tools, including the Computer Use tools, run on the integrator’s infrastructure. Anthropic’s API returns a tool-use block — “take a screenshot,” “click at (320, 480),” “type the string claude.ai” — and the integrator’s harness is responsible for translating that into actual screen actions, capturing the result, and sending the next Messages request with the tool_result. The model is in the loop. The runtime is not.

The production consequence is the inverse of what you might expect. OpenAI’s hosted-runtime model is faster to integrate (the SDK does the loop) but constrains you to OpenAI’s tool quotas and the OpenAI dashboard’s observability. Anthropic’s user-runtime model is more work to integrate (you build the harness) but gives you full control of where the tool runs, what it logs, and how the failure modes manifest. We have shipped both. The “build your own harness” cost on Anthropic is a real cost. The “you do not own the runtime” cost on OpenAI is also real and is the one most production teams underweight at integration time.

Failure modes

Each surface has a recognizable production failure mode.

OpenAI Agents: the most common failure we have seen is the “conversation chain orphan” — a previous_response_id chain that gets dropped because of a client retry, and the next call refuses to find the prior state. The Responses API’s stateful conversation is convenient until it is not; we now recommend client-side caching of the full message history as a fallback, even when the chain is the primary state mechanism. The second common failure is hosted-tool rate-limit-burst — a multi-step agent loop blows through the per-minute web_search quota mid-task and the model continues without the search results, often without flagging the gap clearly.

Anthropic Computer Use: the most common failure is the screenshot-context blowup. Computer Use feeds screenshots to the model every turn, and the input-token cost grows quickly. We have seen 30-step tasks land in the 250k-token input range on a single Messages request, which hits the model’s effective context window and degrades the model’s spatial reasoning. The second common failure is the OS-version-drift problem — the reference Docker container is pinned to a specific OS image; small drift in the host environment changes screenshot rendering enough to confuse the model on actions it would normally land cleanly.

The two failure-mode lists do not look alike. Neither surface has a clearly better story; they have differently shaped problems.

Tool selection: which is the right answer

Our working guidance, against late-2025 production deployments:

Pick OpenAI Agents when:

• The workload is bounded by OpenAI’s hosted-tool surface (web_search, code_interpreter, simple MCP routing).
• You want the conversation state to live on the API and you trust the previous_response_id chain to be your durable state.
• You want time-to-first-running-agent measured in days, not weeks.
• You are comfortable with the hosted-tool quotas being the binding constraint.

Pick Anthropic Computer Use when:

• The workload involves driving a user-facing application that does not have a programmatic API. Computer Use is, in 2025, the most production-capable computer-driving model on the public market.
• You need fine-grained control of where tools run and how they are observed. The user-runtime model is the load-bearing reason to pick this surface.
• You are willing to build a harness — Docker, screenshot capture, action translation — and own its operational characteristics.
• Your binding constraint is per-task token efficiency, and you have engineered the harness to keep the screenshot history bounded.

Pick neither when:

• The workload is a single-model completion that does not need a tool loop. The Chat Completions / Messages API is still the right answer for non-agentic work.
• The workload requires a framework-shaped abstraction (graphs, role-based crews, persistent memory). Use LangGraph, AutoGen, CrewAI, or Letta on top of whichever model surface fits.

What we expect from 2026

Both surfaces are early. The next twelve months will, in our reading, narrow the gap and not eliminate it.

OpenAI will keep growing the hosted-tool surface and we expect the per-organization rate-limit story to get cleaner, including per-tool subscription tiers that decouple the tool quota from the model quota. Anthropic will keep iterating Computer Use against larger context windows and we expect a managed-container option that handles the “you own the runtime” pain for integrators who do not want to.

Neither surface will replace the open-source agent frameworks for serious orchestration. Both will become the canonical primary-model surfaces underneath those frameworks. The right reading is that the model labs are settling into the “runtime for the model + a small set of standard tools” role, and the agent frameworks are settling into the “orchestration on top” role. That is a healthy division of labor. The selection question, for the engineer choosing today, is which surface’s failure modes you would rather operate against. The framework choice comes after.