--- title: 'camelRun vs OpenAI Agents API: Which Hosted Runtime Fits?' published date: '2026-10-08' author: 'Illiana Reed' title-image: 'https://camelai.com/blog/assets/images/covers/camelrun-vs-openai-agents-api.png' --- **TL;DR:** The camelRun vs OpenAI Agents API choice comes down to what your agent has to touch. OpenAI's Agents API (public beta since September 10, 2026) runs the Codex harness for you with a full Linux sandbox, computer use and subagents. It runs OpenAI models only, and OpenAI hosts the control plane. camelRun runs any model, keeps each agent's history and files until you delete it, wakes agents from schedules and chat channels, and is open source, but its code sandbox runs JavaScript only. Choose the Agents API for coding, data and browser work on OpenAI models, and camelRun for long-lived agents inside your product that act through your own APIs. --- ## Agents API vs Agents SDK vs Codex: which OpenAI product is which? OpenAI has several agent products with similar names, and many pages that rank for "OpenAI Agents API" are about one of the others. | Name | What it is | Where it runs | License | |---|---|---|---| | **Agents API** | A hosted API: OpenAI runs the agent loop (the Codex harness), keeps the session and can provide the sandbox | OpenAI's service | Hosted service, public beta | | **Agents SDK** | A library for writing the agent loop in your own code (`openai-agents` for Python, `@openai/agents` for TypeScript) | Your application and servers | MIT | | **Codex** | OpenAI's coding agent: a CLI, an IDE extension and cloud automation | Your machine or OpenAI's cloud | CLI is Apache-2.0 | - **The Agents API** is the September 2026 launch this post compares. You call it through the regular OpenAI SDKs (`client.beta.agents...`), and OpenAI handles orchestration, context compaction and recovery. [OpenAI's own runtime comparison](https://developers.openai.com/api/docs/guides/agents) rates it the lowest-effort way to run an agent. - **The Agents SDK** is a framework. Its runner executes the loop inside your process, you store the state, and you host it yourself. It can also use non-OpenAI models through provider adapters. Comparing it with camelRun means comparing a loop you host with a runtime that hosts the loop for you. Our [agent harness vs framework vs runtime explainer](https://camelai.com/blog/agent-harness-vs-framework-vs-runtime) covers that boundary. - **Codex** is where the Agents API's harness comes from. If you bring your own sandbox to the Agents API, you run `codex exec-server` from the Codex CLI inside it. These are also separate products: - the **Responses API**, the model API for building your own loop; - the **Assistants API**, which shut down on August 26, 2026; - ChatGPT's **workspace agents** and **dots**, which are agents inside ChatGPT; - **Amazon Bedrock Managed Agents, powered by OpenAI**, an AWS preview announced September 29, 2026, which runs an adapted Agents API inside Bedrock. [camelRun vs AWS Bedrock AgentCore](https://camelai.com/blog/camelrun-vs-aws-bedrock-agentcore) covers the AWS side. camelRun is in the same category as the Agents API: a hosted runtime where you write the instructions and tools, and the runtime runs the loop. ## What is the OpenAI Agents API? The [Agents API](https://developers.openai.com/api/docs/guides/agents-api/overview) gives your application the Codex harness as an OpenAI-managed service. You define an **agent** (model, instructions, tools, MCP servers), optionally attach an **environment**, and start a **session**: a durable instance of the agent that you send turns to. Progress arrives as streamed **events** or as webhooks. **Key features:** - **Environments.** Pick one of three: - `none`, for agents that only call tools; - `openai_hosted`, a Linux sandbox with Python, Node.js and CLI tools. It comes in three sizes (1 vCPU/1 GB; 2 vCPU/4 GB, the default; 4 vCPU/16 GB), and network access can be on, off, or limited to up to 100 hosts; - `self_hosted`, on your own machines or on [providers](https://developers.openai.com/api/docs/guides/agents-api/environments/self-hosted) such as Modal, Cloudflare, Vercel, E2B and Daytona. - **Sandbox lifetime.** Files persist across turns while the sandbox exists. After an hour with no activity or keep-alives, [the sandbox can be deleted](https://developers.openai.com/api/docs/guides/agents-api/environments/openai-hosted), and you can't configure that timeout. Files in `/workspace/outputs` become immutable artifacts that outlast it. - **Harness.** - Context compaction and mid-turn steering. - Skills and tool search. - Programmatic tool calling, on by default: the model writes JavaScript that calls its tools. - Parallel subagents. - **Tools.** Function tools your app runs, remote MCP servers that OpenAI calls, and web search. Since September 29, 2026, there's also [computer use](https://developers.openai.com/api/docs/guides/agents-api/tools/computer-use) in an OpenAI-hosted browser, with your app approving each new site. - **Credentials.** Vaults hold MCP tokens and OAuth credentials. For API requests from hosted sandboxes, vault secrets can be substituted by a proxy without exposing their real values to sandbox code. Ordinary `env` values remain readable by that code, so don't put secrets there. - **Observability and SDKs.** Dashboard traces with OTLP export, and SDKs for Python, JavaScript, Go, Java and Ruby. **Models:** OpenAI models, through the OpenAI API (the docs' examples use `gpt-6-astra`). You can change a session's model for later turns, and the session keeps its conversation. **Data:** US data residency only, and no Zero Data Retention (ZDR), even with a self-hosted sandbox. **Pricing:** the Agents API itself has no fee. You pay for tokens, tools at their standard rates, and hosted sandboxes at container rates. ## What is camelRun? [camelRun](https://camelai.com/run) is camelAI's hosted runtime for AI agents. You define each agent's model, instructions, tools and channels. camelRun runs the loop, keeps the agent's history and files (compacting long histories) and runs model-written JavaScript in a sandbox. It wakes the agent when there's work: a message, a schedule, a channel event, a webhook or a human approval. **Key features:** - **Keyed agents.** You name each agent with your own id, such as `user-123`, a ticket or a PR. The same key gets the same agent, with its history, from any process, until you delete it. - **Tools in your code.** Tools can be TypeScript or Python functions, HTTP-served tools, MCP servers or OpenAPI specs. The runtime makes every call and keeps third-party credentials sealed away from the model. - **Any model.** Anthropic, OpenAI, OpenRouter, Amazon Bedrock, or any OpenAI- or Anthropic-compatible server (vLLM, Ollama). You can switch an agent's model and it keeps its history. - **Wake-ups.** Chat channels, schedules, webhooks, and approvals or questions for people. - **Open source.** The runtime is AGPL-3.0 and the SDKs are MIT. You can self-host it with one Docker container plus Postgres. **Pricing:** $0.01 per agent-hour of active run time, plus model usage. Sleeping agents cost only storage. The team built camelRun after building agent infrastructure five times in three years. When camelCode's agents moved onto it, the team deleted about 72,000 lines of code. [The intro post](https://camelai.com/blog/the-web-wasnt-built-for-agents) has the story. ## camelRun vs OpenAI Agents API: head-to-head | | OpenAI Agents API | camelRun | |---|---|---| | **Who runs the loop** | OpenAI (managed Codex harness) | camelRun's hosted runtime, or your own deployment | | **Models** | OpenAI models | Any provider; switch an agent's model and keep its history | | **Code execution** | Linux sandbox (hosted or yours), plus a hosted browser | JavaScript sandbox only: no shell, Python, package installs or network | | **Addressing agents** | Session IDs that OpenAI issues and you store | Your own keys | | **Files** | Live while the sandbox exists; `/workspace/outputs` kept as artifacts | Kept with the agent until you delete it | | **Your tools** | Function tools your app answers; MCP called by OpenAI | Functions, HTTP-served tools, MCP and OpenAPI, all called by the runtime | | **Wake-ups** | Input from your app; webhooks report session state | Messages, schedules, chat channels, webhooks, approvals | | **Multi-agent** | Built-in subagents | No built-in primitive; delegate through a tool | | **Observability** | Dashboard traces, OTLP export | Event stream, history API, webhooks, console; no OpenTelemetry export | | **Self-hosting** | Executor only; OpenAI hosts the control plane | The whole runtime (AGPL-3.0; SDKs MIT) | | **Data** | US residency only; no ZDR | Self-host to keep data in your own infrastructure | ### Model choice This is the largest structural difference. If OpenAI's models are what you want anyway, the restriction costs you nothing. If you want Claude for some agents, an open-weight model on your own servers for others, or the option to move later, it settles the question. camelRun runs OpenAI models too, alongside the other providers. Because an agent's history lives in the runtime, a long-lived agent can change provider without starting its conversation over. ### Where the agent's code runs The Agents API is stronger here, and this is the main reason to choose it. A hosted session gets a real Linux box. The agent can install packages, run Python, execute a test suite, edit files and produce artifacts. With computer use, it can drive a browser. A self-hosted environment can sit inside your private network. camelRun's sandbox runs **JavaScript only**. The model writes code that calls its tools (in parallel, with `Promise.all`) and reads its files, but there's no shell, no Python, no package installs and no network. Anything that reaches the outside world goes through your tools, which run in your code with your own network access and credentials. That design suits agents that act through your product's APIs. It doesn't suit agents that build, test or run arbitrary CLIs. The JavaScript approach itself isn't unique: OpenAI's programmatic tool calling is the same idea, with a Linux sandbox available beside it. ### State: sessions vs keyed agents Both keep the conversation on the server. The differences are files and naming. In the Agents API, hosted-sandbox files last only as long as the sandbox. It can be deleted after an hour without activity or keep-alives; connected sandboxes receive keep-alives even between turns. The session outlives the sandbox, and `/workspace/outputs` survives as artifacts, but other files don't. For an expired sandbox, OpenAI's advice is to start a new session and supply the inputs again. With a self-hosted environment, you own provisioning, reconnection and keeping files. In camelRun, history and files belong to the agent, and a keyed agent keeps them until you delete it. You look the agent up by your own key, instead of storing an OpenAI-issued session ID for every user or thread. ### Your tools, and failed calls In the Agents API, a function call pauses the session in a "requires action" state. It stays there until your app, reached through the stream or a webhook, posts the result. If your handler is down, the turn waits. In camelRun, the runtime calls your tools, either over the SDK's connection or over HTTPS for served tools. Each call has a deadline (15 seconds by default for in-process tools). camelRun never re-sends a call whose answer was lost. Instead the model is told the outcome is unknown, and every call carries an idempotency key. Neither product gives you exactly-once side effects. OpenAI's docs likewise tell you to store function results by call ID and to check the outcome before re-running anything that has side effects. ### Triggers, channels and approvals The Agents API starts a turn when your app sends input, and webhooks tell you when a session needs something or goes idle. In [OpenAI's documented Slack integration](https://developers.openai.com/cookbook/examples/agents_api/apps/slack_bot/readme), your application receives Slack events, maps each thread to a session, and relays the results. For recurring work, plan an application-side scheduler that submits session input; the reviewed configuration and session guides do not specify a scheduling resource. camelRun wakes agents from more sources: schedules (including ones an agent sets for itself), Slack, Discord, Telegram and GitHub channels, generic webhook channels for services like Sentry or Linear, and human input. A run paused for approval sleeps without accruing agent time. By default it waits 7 days (configurable up to 30) and resumes from any process when someone answers. ### Open source, self-hosting and data The Agents API's harness comes from Codex, whose CLI is Apache-2.0, but sessions and orchestration stay on OpenAI's service. The part you can self-host is the executor. Data residency is US-only, with no ZDR. The whole camelRun runtime is open source under AGPL-3.0, and a commercial license is also offered. Self-hosting takes one Docker container and Postgres, so history and files can live in your own database and storage. ## OpenAI Agents API pricing vs camelRun pricing The two products charge for different things, so keep the meters separate. | Meter | OpenAI Agents API | camelRun | |---|---|---| | **Platform / runtime** | None | $0.01 per agent-hour of active run time (model calls and tool execution), on any keys | | **Model tokens** | OpenAI API rates, e.g. GPT-6 Astra $10 input / $50 output per million tokens; GPT-6.1 Sol $2 / $10 | Nothing from camelRun on your own keys; list price from prepaid credit on camelAI's keys | | **Code execution** | Hosted containers: $0.03 (1 GB), $0.12 (4 GB), $0.48 (16 GB) per 20-minute session; eligible sessions bill by the minute with a 5-minute minimum | Included in agent time | | **Storage** | No separate session-storage line on the pricing page | $0.10 per GB-month | | **Web search** | $10 per 1,000 calls, plus content tokens | $0.001–$0.007 per search on camelAI's keys | *Pricing verified October 2026 against [OpenAI's pricing page](https://developers.openai.com/api/docs/pricing) and [camelRun's pricing](https://camelai.com/run). Token prices are standard tier, short context. Pricing and limits change often; check each vendor's pricing page before deciding.* **One hour of agent work, excluding tokens (our arithmetic):** - **Agents API with no environment:** $0. - **Agents API with a hosted sandbox for the hour:** $0.09 (small), $0.36 (medium, the default) or $1.44 (large). This assumes each size bills at the container tier that matches its memory. - **camelRun:** $0.01 per active agent-hour. These don't buy the same thing. The $0.36 gets a 2 vCPU, 4 GB Linux box; camelRun's $0.01 covers loop time and a JavaScript sandbox. Idle time is metered differently too. OpenAI says connected sandboxes get keep-alives between turns but doesn't say whether that time is billed as container time, so check before you model costs for agents that sit idle. A camelRun agent that's waiting or asleep accrues only storage. And if your agent only calls tools and runs on OpenAI models anyway, the Agents API adds no platform charge at all. Tokens usually dominate either bill. With your own OpenAI key, the same model costs the same rate on both platforms. On camelAI's keys you pay list price from prepaid credit, and credit purchases carry a 5.5% processing fee; models reached through OpenRouter also pass through its funding fee. One GPT-6 Astra call that reads 50,000 uncached input tokens costs $0.50 before any output. ## What the first agent looks like OpenAI's [quickstart](https://developers.openai.com/api/docs/guides/agents-api/quickstart) gives the agent a hosted sandbox and asks it to write and run a script: ```python from openai import OpenAI with OpenAI() as client: with client.beta.agents.sessions.create( agent={ "model": "gpt-6-astra", "instructions": "Write clean code, run it, and report the actual output.", }, environment={"type": "openai_hosted"}, input="Create tree.py, a Python script that prints a readable tree of the files in the current directory. Run it and show me the output.", stream=True, ).with_result_collection() as stream: for event in stream: print(event.to_json(indent=None), flush=True) result = stream.get_final_result() print(result.output_text) session_id = result.session_id ``` camelRun's [quickstart](https://camelai.com/docs/camelrun/quickstart) gives a keyed agent one tool that runs in your own process: ```python import asyncio from camelai_run import Agents, tool @tool def weather(city: str) -> dict: """Today's weather in a city""" return {"city": city, "forecast": "sunny", "highC": 24} async def main(): async with Agents() as agents: # reads CAMELAI_API_KEY agent = await agents.upsert("quickstart", instructions="You are a concise assistant.", tools=[weather]) run = await agent.run("Should I bring an umbrella in Lisbon today?") print(run.text) asyncio.run(main()) ``` One hands the model a computer; the other hands it your function. ## When to choose the OpenAI Agents API - You're standardizing on OpenAI models and want Codex's harness without operating it. - The agent needs a Linux sandbox to run code, install packages, build and test, or produce files. - You need computer use to work through websites. - You want built-in subagents, OTLP trace export, or SDKs in Go, Java or Ruby. - Your agent only calls tools, and you want no platform fee on top of tokens. US-only data residency and no ZDR must be acceptable. AWS shops can also look at the Bedrock Managed Agents preview. ## When to choose camelRun - You want to choose or switch models across providers, including Claude and self-hosted open-weight models, without losing an agent's history. - You're adding agents to a product: one per customer, ticket, thread or PR, keyed by your own ids, with thousands of agents at once and most of them asleep. - Your agents act through your own APIs, and you want credentials kept in your code. - Your agents live for weeks, wait days for approvals, or wake on schedules and chat messages. - You need to self-host the whole runtime or read its source. JavaScript-only code execution has to be enough. If it isn't, the Agents API, Claude Managed Agents ([our comparison](https://camelai.com/blog/camelrun-vs-claude-managed-agents)) or a harness in your own container fits better. For the wider field, see [AI agent runtimes and hosting platforms compared](https://camelai.com/blog/ai-agent-runtimes-hosting-platforms). ## FAQ **Is the OpenAI Agents API open source?** The service isn't. Its harness comes from Codex, whose CLI is Apache-2.0, and you can run the executor on your own machines, but sessions and orchestration run on OpenAI's platform. The Agents SDK is open source (MIT), but it's a library you host, not a hosted service. **Did the Agents API replace the Assistants API?** Not directly. The Assistants API shut down on August 26, 2026, and OpenAI's migration path for it is the Responses and Conversations APIs. The Agents API is a separate, newer product for running whole agents. **Can I move an Agents SDK agent to camelRun?** Mostly, yes. Instructions, function tools, structured output and tool approvals all map across, and [camelRun's docs](https://camelai.com/docs/camelrun/overview) include a concept-by-concept mapping from the Agents SDK. A few things don't carry over: - handoffs (camelRun delegates through tools instead); - the Python code interpreter (camelRun's sandbox runs JavaScript); - file search over vector stores; - temperature and top_p settings. ## Try camelRun camelRun is at [camelai.com/run](https://camelai.com/run). The [quickstart](https://camelai.com/docs/camelrun/quickstart) gets an agent with one of your tools running in about five minutes. It costs $0.01 per agent-hour of active run time plus model usage, and the runtime's source is [on GitHub](https://github.com/qaml-ai/run). If you're still deciding how much of the stack to own, start with [how to build an AI agent](https://camelai.com/blog/how-to-build-an-ai-agent).