Skip to content
Agentic AI
Agentic AI10 min read0 views

OpenAI Agents SDK: Python vs JavaScript Feature Parity in May 2026

Sandbox, harness, code mode, and async subagents are Python-only as of April 2026. Here is the actual parity matrix and how to architect around it.

TL;DR — As of April 2026, OpenAI's "next evolution" features (sandbox, harness, code mode, subagents) shipped in the Python SDK only. The TypeScript SDK has the core (agents, handoffs, guardrails, tools, sessions, tracing) and is maintained, but the new toys are Python-first with no announced TS timeline.

What ships where, May 2026

flowchart LR
  Repo[GitHub repo] --> CI[GitHub Actions]
  CI --> Eval[Agent eval suite · PromptFoo]
  Eval -->|pass| Deploy[Deploy]
  Eval -->|fail| Block[Block PR]
  Deploy --> Prod[Production agent]
  Prod --> Trace[(LangSmith trace)]
  Trace --> Eval
CallSphere reference architecture
Feature Python TypeScript
Agents, handoffs, guardrails, tools yes yes
Sessions + memory yes yes
Tracing (OpenAI dashboard) yes yes
Voice agents (Realtime) yes yes
Sandbox (managed code execution) yes not yet
Harness (declarative agent runtime) yes not yet
Code mode (model writes Python) yes not yet
Subagents (built-in delegation) yes "in progress"
MCP client + server yes yes

Both SDKs share core features like agents, handoffs, guardrails, tools, human-in-the-loop, sessions, and tracing. OpenAI is working to bring code mode and subagents to TypeScript, but the company's April 2026 update was clear that the new harness and sandbox capabilities are launching first in Python, with TypeScript "planned for a future release" with no specific timeline.

Why the gap exists

Two structural reasons:

  1. The harness needs a sandbox, and the OpenAI sandbox launched as a Python service first. Wiring the JS SDK into the same execution surface requires extra plumbing (process pool, transport, language-specific stdlib).
  2. The Python SDK is OpenAI's reference implementation. Internal teams build there first; the JS SDK follows.

For teams shipping in 2026, this means: if your stack is TypeScript-first, you should either (a) accept that you'll be 1-2 quarters behind on net-new features, or (b) split your worker tier to a Python service for the bleeding-edge features and call it from your TS frontend.

How CallSphere splits the surface

CallSphere's voice runtime is TypeScript end-to-end (Next.js 15 App Router, Node serverless workers, OpenAI Realtime over WebRTC). Our 37 agents and 90+ tools live in TS because the voice loop demands it.

Hear it before you finish reading

Talk to a live CallSphere AI voice agent in your browser — 60 seconds, no signup.

Try Live Demo →

But our batch and offline agents — GTM lead scoring, SEO content generation, affiliate-fraud detection, after-hours triage rollups — are Python. That's where we use the new harness, sandbox, and subagents features. The boundary is a Postgres-backed job table and a small RPC layer; the TS app enqueues, the Python workers execute.

This split is the same one most production teams are settling on in 2026: TS for online, Python for offline. The OpenAI Agents SDK feature gap accelerates rather than causes that pattern.

Decision tree

  • Voice agent on a webpage? TypeScript SDK. The Realtime + WebRTC plumbing is mature in JS.
  • Long-horizon research, code-rewrite, batch processing? Python SDK. Pay the language tax to get the harness.
  • Mixed workload? Split it. Use the same OpenAI tracing project so the spans stitch back together in the dashboard.
  • Single team, single language preference? Pick the language; accept the parity timeline. JS is fine for production today if you don't need code mode and subagents.

Code: the same agent in both SDKs

Python:

from agents import Agent, Runner, function_tool

@function_tool
def lookup_account(phone: str) -> dict:
    return {"plan": "Growth", "mrr": 499}

agent = Agent(
    name="Triage",
    instructions="Route inbound calls.",
    tools=[lookup_account],
)
result = await Runner.run(agent, "+18453884261 just called")

TypeScript:

import { Agent, run, tool } from "@openai/agents";
import { z } from "zod";

const lookupAccount = tool({
  name: "lookup_account",
  description: "Look up a CallSphere account by phone.",
  parameters: z.object({ phone: z.string() }),
  execute: async ({ phone }) => ({ plan: "Growth", mrr: 499 }),
});

const agent = new Agent({
  name: "Triage",
  instructions: "Route inbound calls.",
  tools: [lookupAccount],
});

const result = await run(agent, "+18453884261 just called");

The shape is identical. The difference shows up only when you reach for sandbox/harness — those imports simply don't exist in JS yet.

Things both SDKs do well

Even with the gap, both SDKs share a strong common core:

Still reading? Stop comparing — try CallSphere live.

CallSphere ships complete AI voice agents per industry — 14 tools for healthcare, 10 agents for real estate, 4 specialists for salons. See how it actually handles a call before you book a demo.

  • Handoffs — typed agent-to-agent transfer with state passed through. Same API in Python and TS.
  • Guardrails — input and output validation that runs alongside the model. Both SDKs let you reject or rewrite outputs.
  • Sessions — built-in conversational memory that survives across turns.
  • Tracing — both SDKs emit OpenTelemetry-compatible spans to the OpenAI tracing dashboard or to any OTel collector.
  • Voice agents — both wrap OpenAI Realtime; the TS path is actually more battle-tested for browser-side voice.

If your project doesn't need code mode or sandbox, JS is genuinely fine. We've shipped 30+ production agents on the JS SDK and the gaps are visible only when you go looking for them.

A pragmatic 2026 stack

Here's what we recommend for new builds, by team profile:

  • Pure TS team, web-first product: JS SDK end-to-end. Wrap any Python-only feature behind a tiny FastAPI service when you really need it.
  • Pure Python team, batch / backend product: Python SDK end-to-end. The harness, sandbox, and code mode are huge wins for offline workloads.
  • Polyglot team, voice + batch: TS for the voice/web frontend, Python workers for batch agents. Same OpenAI tracing project.
  • Already on LangGraph or CrewAI: don't migrate just to chase parity. Mount OpenAI's tools where you need them; keep your runtime.

What to do if you need a Python-only feature in a TS app

  1. Wrap the Python agent as an HTTP service (FastAPI, one POST endpoint per agent).
  2. Mint a short-lived auth token from your TS app and call the service.
  3. Stream events back via SSE if the agent emits intermediate steps.
  4. Trace from both sides into the same OpenAI tracing project ID; spans will stitch.

CallSphere has a demo showing this exact split if you want to see it live, and we offer pilot deployments at $149 Starter / $499 Growth / $1499 Scale with a 14-day trial.

FAQ

When will TypeScript catch up? OpenAI has not given a date. April 2026 messaging used "future release" without a timeline.

Is the JS SDK going to be deprecated? No. It's actively maintained, the Realtime voice path is JS-first, and the core agent surface ships features in both languages.

Can I use the Python SDK from a Next.js app? Not directly. Stand up a Python service and call it.

Should I rewrite my JS agent in Python? Almost never. Wrap the Python service instead.

Sources

Share

Try CallSphere AI Voice Agents

See how AI voice agents work for your industry. Live demo available -- no signup required.

Related Articles You May Like