OpenAI Agents SDK vs Claude Agent SDK: Library vs Harness

The OpenAI Agents SDK vs Claude Agent SDK question looks like a vendor choice. It's really a choice between two different shapes of software.

• The OpenAI Agents SDK is a lightweight orchestration library. You define agents, wire them together with handoffs, add guardrails, and run them in your own process. It works with OpenAI models by default and with other providers too.
• The Claude Agent SDK is Claude Code's whole agent loop, importable. You hand it a task, and it reads files, runs shell commands, edits code, and spawns subagents until the job is done. It runs Claude models only.

So the short answer: if you're designing a multi-agent workflow (triage, routing, specialist agents, approval gates), start with OpenAI's library. If you need an agent that does work on a machine (a repo, a folder of documents, a shell), start with Claude's harness.

The rest of this post covers where each one is stronger, and the one feature that has narrowed the gap.

Quick comparison

What the OpenAI Agents SDK is built for

The OpenAI Agents SDK describes itself as a way to build agentic apps "in a lightweight, easy-to-use package with very few abstractions." It's the production successor to Swarm, OpenAI's earlier multi-agent experiment, and that lineage shows. The library is about coordinating agents, not about giving one agent a computer.

Four primitives do most of the work:

Here is the shape of a triage agent routing to two specialists:

from agents import Agent, Runner

billing = Agent(name="Billing", instructions="Handle billing questions.")
refunds = Agent(name="Refunds", instructions="Process refund requests.")

triage = Agent(
    name="Triage",
    instructions="Route the user to the right specialist.",
    handoffs=[billing, refunds],
)

result = Runner.run_sync(triage, "I was charged twice last month.")
print(result.final_output)

To the model, each handoff is just a tool, named something like transfer_to_refunds. That's the whole trick, and it's why the library stays small.

Where OpenAI's library is stronger

Model choice. The GitHub README calls the SDK provider-agnostic, supporting OpenAI's Responses and Chat Completions APIs "as well as 100+ other LLMs." You can point it at any OpenAI-compatible endpoint, or use the LiteLLM and any-llm adapters. Read the models page before you commit, though: those two adapters are "best-effort, beta," and some features (hosted web and file search, structured outputs on some providers, a few Responses-only tool features) won't carry over.

Explicit routing. Handoffs make the flow of control readable. You can see which agent owns the conversation at every step, which matters for customer-facing bots where a wrong turn is visible to a user.

Guardrails as a first-class idea. Guardrails come in three kinds: input, output, and tool. Two details trip people up. Input guardrails run in parallel with the agent by default, so the agent may spend tokens before the tripwire fires (a blocking mode exists). And input guardrails run only for the first agent in a chain.

Tracing out of the box. Tracing is on by default and lands in OpenAI's Traces dashboard. It also plugs into third-party processors, including Langfuse and LangSmith. One catch: tracing isn't available to organisations under OpenAI's Zero Data Retention policy.

Voice and a JavaScript port. The SDK ships realtime and voice agent pipelines, and there's an official JavaScript/TypeScript version, also MIT-licensed.

What the Claude Agent SDK is built for

We cover installation, auth, and the permission model in our Claude Agent SDK guide, so this section sticks to how it compares.

The Claude Agent SDK gives you "the same tools, agent loop, and context management that power Claude Code." The difference from OpenAI's library is not a feature list. It's that the agent comes with a working environment already attached: a shell, a working directory, file tools, and the judgement to use them.

That changes what hosting looks like. Per the hosting docs, every query() spawns a claude CLI subprocess that owns a shell, a working directory, and session transcripts on disk. One session is one long-lived process. You don't deploy it like a stateless API wrapper. You deploy it like a worker in a container.

Where Claude's harness is stronger

Real work on a real filesystem, with no setup. Reading, editing, and searching files, running commands, and searching the web are built in. You don't write the tool dispatch, the retries, or the context compaction. For "read this repo and fix the failing tests," that's weeks of plumbing you skip.

Subagents for parallel work. Subagents run in their own context, can run concurrently, and can be restricted to specific tools. Only their final message returns to the parent, so a research subagent can read dozens of files without flooding the main conversation. They can nest, and the SDK lets you cap depth, concurrency, and spend.

from claude_agent_sdk import ClaudeAgentOptions, AgentDefinition

options = ClaudeAgentOptions(
    allowed_tools=["Read", "Grep", "Glob", "Agent"],
    agents=dict(
        reviewer=AgentDefinition(
            description="Reviews code for bugs. Use after edits.",
            prompt="You are a strict code reviewer.",
            tools=["Read", "Grep", "Glob"],
        ),
    ),
)

Fine-grained control over actions. Permission modes, allow and deny rules, and hooks at points like PreToolUse, PostToolUse, SubagentStop, and PreCompact let you intercept what the agent is about to do. File checkpointing can rewind changes made through the Write and Edit tools (not changes made through shell commands).

Your Claude Code setup carries over. Skills, commands, memory, and plugins load from .claude/ the same way the CLI loads them. If your team already lives in Claude Code, your agents inherit that work.

Tracing where you choose to send it. Telemetry goes out as OpenTelemetry traces, metrics, and events to any OTLP backend. It's off until you turn it on, and nothing goes to a vendor dashboard by default.

Where it's narrower

It's Claude only. The documented ways to authenticate are the Anthropic API, Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, and Microsoft Foundry. Those give you a choice of cloud, not of model family. Licensing is also split: the Python repository is MIT, while the TypeScript SDK's licence reserves all rights, and use of the SDK falls under Anthropic's Commercial Terms.

The gap that has narrowed: sandbox agents

Older comparisons say OpenAI's SDK has no file or shell access. That's out of date.

Sandbox agents give an OpenAI agent "a persistent workspace where it can search large document sets, edit files, run commands, generate artifacts, and pick work back up from saved sandbox state." They come with filesystem, shell, and patch tools, plus skills, memory, and compaction. The backends are Unix-local, Docker, and hosted sandbox providers.

The two SDKs now overlap, but they still disagree about where the agent lives:

OpenAI now publishes an official migration guide from the Claude Agent SDK, mapping subagents to handoffs or agent.as_tool(), and query() to Runner.run(). Its summary of the difference: the Claude SDK runs the harness inside the sandbox, while OpenAI keeps secrets, approval decisions, and business-system access outside the execution environment. That's a competitor's framing, so weigh it accordingly, but it names the real design choice.

OpenAI Agents SDK vs Claude Agent SDK: how to choose

Two cases where neither is the obvious pick. If you need explicit graphs with checkpoints and branches, look at LangGraph; our LangGraph vs LangChain breakdown covers that layer. And if the question is how to watch agents in production across vendors, Langfuse vs LangSmith is the next read. Both SDKs speak MCP, so tool servers you build carry across either way.

A simple test: write down the first thing your agent does. If it's "decide who should handle this," you want a router. If it's "open the project folder," you want a harness.

The step before either SDK

Both SDKs assume you're a developer who will write, host, and debug the agent. That's fine for engineering teams. It's the wall for everyone else, who mostly meet agents as someone else's working setup in a demo and then can't reproduce it.

Taku sits on that side of the problem. It's an AI-native desktop workspace where you mirror an app, skill, or workflow someone already got working, run it, remix it, and keep it. It isn't an agent framework and doesn't compete with either SDK. Taku is in Beta, and the Mac app is available now.

FAQ

Can the OpenAI Agents SDK use Claude models?

Yes, through its provider options. It supports any OpenAI-compatible endpoint plus the LiteLLM and any-llm adapters, which OpenAI labels best-effort beta. Some OpenAI-hosted features won't work with other providers, and tracing uploads still need an OpenAI API key.

Can the Claude Agent SDK use GPT or open-source models?

Not as documented. Its supported providers (the Anthropic API, Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, Microsoft Foundry) all serve Claude models.

Are handoffs the same as subagents?

No. A handoff transfers the whole conversation to another agent, which takes over. A subagent does a scoped task in its own context and returns only its final result to the parent. OpenAI's agent.as_tool() is the closer match to a subagent.

Which SDK is open source?

The OpenAI Agents SDK is MIT-licensed in both Python and JavaScript. For Claude, the Python SDK repository is MIT, the TypeScript SDK reserves all rights, and so does the bundled Claude Code binary. Use falls under Anthropic's Commercial Terms.

Does the OpenAI Agents SDK support MCP?

Yes. It supports hosted MCP tools, Streamable HTTP, SSE, and stdio servers, with approval policies per tool. The Claude Agent SDK supports MCP servers too.

Is the Claude Agent SDK the same as Claude Code?

It runs the same engine. The SDK launches the Claude Code CLI as a subprocess and exposes its loop, tools, and configuration to your Python or TypeScript code.