--- title: 'camelRun vs AWS Bedrock AgentCore: Runtime, Harness, Pricing' published date: '2026-10-07' author: 'Illiana Reed' title-image: 'https://camelai.com/blog/assets/images/covers/camelrun-vs-aws-bedrock-agentcore.png' --- **TL;DR:** In camelRun vs AWS Bedrock AgentCore, the answer depends on which AgentCore component you mean: Runtime hosts a loop you build (one microVM per session, up to 8 hours), Harness (GA since June 2026) runs a config-defined loop for you on Runtime, and Memory, Gateway, Identity and Policy are separately billed services around both. camelRun is one open-source runtime that runs the loop, keeps each agent's history and files until you delete it, and bills $0.01 per active agent-hour plus model usage, but its code sandbox runs JavaScript only. Choose AgentCore for AWS-native controls, Linux sandboxes or GPUs; choose camelRun for long-lived, per-customer agents whose tools live in your own code, or when you want to self-host. --- ## camelRun vs AWS Bedrock AgentCore at a glance AgentCore is a family of AWS services, each with its own API and meter. Two matter most here: **Runtime**, which hosts an agent you build, and **Harness**, which runs an agent you configure. camelRun overlaps most with Harness: you write a prompt and tools, and the runtime runs the loop. (Our explainer on [agent harness vs framework vs runtime](https://camelai.com/blog/agent-harness-vs-framework-vs-runtime) defines those layers.) | | AgentCore Runtime | AgentCore harness | camelRun | |---|---|---|---| | **Who runs the loop** | You, in your container, with any framework | AWS, from config (powered by Strands Agents) | camelRun | | **Unit of work** | A session: one microVM, up to 8 h (14 days on Instances) | A microVM session on Runtime, up to 8 h | A keyed agent that lives until you delete it; runs have no timeout | | **Durable state** | Ephemeral per session; you add Memory, session storage or S3/EFS | Managed Memory, session storage, S3/EFS mounts | History and files kept by the runtime, compacted when long | | **Code execution** | Full Linux microVM, Code Interpreter, Browser | Built-in shell and file tools, Code Interpreter, Browser | JavaScript sandbox only | | **Models** | Whatever your code calls | Bedrock, OpenAI, Gemini, LiteLLM | Anthropic, OpenAI, OpenRouter, Bedrock, compatible servers | | **Pricing basis** | vCPU-hours + GB-hours, per second | No harness fee; Runtime, Memory and other meters | $0.01 per active agent-hour + storage | | **Where it runs** | AWS | AWS | Hosted, or self-hosted | ## What is AWS Bedrock AgentCore? Amazon Bedrock AgentCore became [generally available on October 13, 2025](https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-is-now-generally-available/), after a July 2025 preview. Runtime now runs in [21 commercial Regions plus AWS GovCloud (US-West)](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agentcore-regions.html). ### AgentCore Runtime: you bring the loop [AgentCore Runtime](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-how-it-works.html) is serverless hosting for an agent you write, in any framework or none (LangGraph, CrewAI, Strands Agents, the OpenAI Agents SDK, Google ADK). You package it as an [ARM64 container](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-http-protocol-contract.html) serving `/invocations` and `/ping` on port 8080, or ship Python and Node.js agents as a zip. Each session gets a dedicated microVM with isolated CPU, memory and filesystem, up to 2 vCPU and 8 GB. It ends after 15 minutes idle or 8 hours total by default, both [configurable](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-lifecycle-settings.html) from 60 seconds to 8 hours. Then the microVM is destroyed, and the same session ID gets a fresh environment. AWS's docs call session state ephemeral and point you to AgentCore Memory for durable context. Two recent additions: - **Runtime V2** ([GA September 18, 2026](https://aws.amazon.com/about-aws/whats-new/2026/09/new-agentcore-runtime-generally-available/)) restores each session from a snapshot. AWS reports P75 cold starts of 1.9–2.0 seconds, against 5.4–30 seconds on V1, and V2 reclaims memory your agent releases. It's in five Regions so far, and deploys take several minutes. - **Instances** (August 2026) run sessions on [EC2 managed instances in your own account](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-instances-how-it-works.html): up to 14 days, GPU instance types, several agents per session, and EBS volumes that survive restarts. ### AgentCore harness: AWS runs the loop [AgentCore harness](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness.html) reached [GA on June 17, 2026](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-harness-generally-available/). You declare the model, system prompt, tools, skills, memory and limits, and AWS runs the loop, powered by its open-source Strands Agents framework. Harness runs on Runtime, so every session gets its own microVM with a filesystem and a shell. A definition, from AWS's docs: ``` aws bedrock-agentcore-control create-harness \ --harness-name "research-agent" \ --execution-role-arn "arn:aws:iam::123456789012:role/MyHarnessRole" \ --system-prompt '[{"text": "You are a research assistant."}]' \ --tools '[{"type": "agentcore_browser", "name": "browser"}]' ``` You then call `InvokeHarness` with a session ID. Harness takes models from Amazon Bedrock, OpenAI, Google Gemini or any LiteLLM-compatible provider, and can switch providers mid-session. It has versions and named endpoints, a Step Functions integration, lifecycle hooks, and export to Strands code when configuration isn't enough. ### The rest of AgentCore - **Memory:** short-term events and long-term records (semantic, summarization, user-preference and episodic strategies). - **[Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html):** turns APIs, Lambda functions and OpenAPI or Smithy specs into MCP tools, fronts MCP servers, and adds semantic tool search. - **Identity:** inbound IAM SigV4 or OAuth (Cognito, Okta, Entra ID), plus a token vault for outbound OAuth tokens and API keys. - **Code Interpreter and Browser:** sandboxed Python, JavaScript and TypeScript, and a managed browser with OS-level interaction. - **[Policy](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html):** Cedar policies (or plain-English rules compiled to Cedar) checked on every tool call through Gateway. - **Observability and Evaluations:** CloudWatch traces (OpenTelemetry-compatible), evaluators and A/B tests. ## 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 agent loop, keeps each agent's history and files (compacting long histories), runs model-written JavaScript in a sandbox, and wakes agents when there's work: a message, a schedule, a channel event, a webhook or a human approval. Agents are keyed by your own ids, one per customer, ticket, thread or PR, and you can run thousands of agents at once. This is the quickstart from the docs: ```ts import { Agents, schema, tool } from "@camelai/run"; const agents = new Agents(); // reads CAMELAI_API_KEY // A tool is an ordinary function: it runs here, in your process. const weather = tool({ description: "Today's weather in a city", input: schema.Object({ city: schema.String() }), execute: ({ city }) => ({ city, forecast: "sunny", highC: 24 }), }); // The same key is the same agent, with its history, every time you run this. const agent = await agents.upsert("quickstart", { instructions: "You are a concise assistant.", tools: { weather }, }); const run = await agent.run("Should I bring an umbrella in Lisbon today?"); console.log(run.text); await agents.close(); ``` The runtime is AGPL-3.0 and the SDKs are MIT. It's the fifth time our team has built agent infrastructure in three years, and moving camelCode's agents onto it let us [delete about 72,000 lines of code](https://camelai.com/blog/the-web-wasnt-built-for-agents). ## Head-to-head, component by component ### What you build vs what's managed On **Runtime**, you build the loop, tool calling, context handling and persistence, and AWS supplies isolation, scaling, endpoints and auth. On **Harness** and **camelRun**, you write the agent's definition and tools, and the platform runs the loop. ### Sessions, lifetime and waking up On AgentCore, Runtime and Harness work happens in **sessions** (up to 8 hours on microVMs) that your code starts through the API or, for Harness, a Step Functions step. Runtime also offers sessions up to 14 days on Instances. A schedule or Slack bot that wakes the agent is yours to build from other AWS services or your own code. On camelRun, the unit is an **agent**. The same key returns the same agent from any process until you delete it, and runs have no timeout. Agents wake on messages, schedules, channels (Slack, Discord, Telegram, GitHub, or a generic webhook from services like Sentry or Linear) and your own webhooks. A run waiting on a person accrues no agent time, for 7 days by default and up to 30. ### State and history - **Runtime:** state lasts as long as the microVM. For durability you wire in AgentCore Memory, [managed session storage](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/release-notes.html) (preview: 1 GB per session, 14-day retention) or S3 Files and EFS. - **Harness:** does the wiring. Created through the API, it provisions [managed memory](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-memory.html) by default (the CLI defaults to none), so conversations continue across microVM sessions. Long histories get a sliding window by default, or summarization. - **camelRun:** history, files, configuration and pending work live in the runtime, with compaction. Durable history doesn't mean exactly-once side effects, though: camelRun never re-sends a tool call whose answer was lost, the model is told the outcome is unknown, and your tool gets an idempotency key. ### Models: not a differentiator Both are model-agnostic. Harness and camelRun can each switch an agent's model mid-conversation and keep its context; on Runtime, that's up to your code. Harness reaches extra providers through LiteLLM, and camelRun through any OpenAI- or Anthropic-compatible server, such as vLLM or Ollama. ### Tools and credentials AgentCore's Gateway turns APIs, Lambda functions and MCP servers into governed MCP tools, with 1-click integrations such as Salesforce, Slack and Jira, and Identity's token vault keeps keys out of agent code. Harness tools can be remote MCP servers, a Gateway, Browser, Code Interpreter or **inline functions**: for those, [the harness pauses](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-tools.html) and hands the call to your code, which returns the result in another `InvokeHarness` call. In camelRun, a tool is an ordinary TypeScript or Python function, and the runtime calls it, either over the SDK's connection to your process or over HTTPS with a runtime-signed identity (for serverless and multi-instance backends). MCP servers and OpenAPI specs are called by the runtime with credentials stored sealed. Every call gets a deadline and an idempotency key, and the model never sees your credentials. ### Code execution: Linux vs JavaScript This is AgentCore's clearest advantage. Each harness session has a real shell, file tools and up to 10 interactive shells; Code Interpreter runs Python, JavaScript and TypeScript on up to 2 vCPU and 8 GB with a 10 GB disk; Browser handles OS-level dialogs; and Instances add GPUs. camelRun's `js_exec` lets the model write **JavaScript** that calls its tools (in parallel with `Promise.all`) and reads its files, for up to 120 seconds. There's no shell, no Python, no package installs and no network. The Python SDK defines tools; it doesn't run Python code. The sandbox's limits don't apply to your tools, which run in your code. If your agent needs to build and test code or run arbitrary CLIs, it needs a Linux box: use AgentCore or another Linux sandbox, not camelRun. ### Enterprise controls: where AgentCore is ahead - IAM (SigV4) or OAuth inbound auth, VPC, PrivateLink and VPC egress. - Cedar policies enforced outside agent code, with Bedrock Guardrails support. - CloudWatch and OpenTelemetry-compatible traces, CloudTrail, evaluations and A/B tests. - SOC 1, 2 and 3, ISO and CSA STAR coverage; 21 commercial Regions plus GovCloud. - Default quotas of 5,000 active sessions per account in US East (N. Virginia) and US West (Oregon), adjustable. camelRun's controls are app-level: per-agent and per-run spend limits, per-customer model keys, runtime-signed identity on tool calls, an event stream, webhooks and a console. It has no OpenTelemetry export. ### Lock-in, open source and self-hosting AgentCore runs only on AWS. On Runtime your loop is your own framework code, so the AWS-specific parts are IAM, deployment and the Memory, Gateway and Identity APIs. Harness agents are AWS configuration, with export to Strands code as the exit. The AgentCore Python SDK is Apache-2.0. camelRun's runtime is AGPL-3.0 and its SDKs are MIT. Use it hosted, or run it yourself with one Docker container and Postgres; a commercial license is also available. ## AgentCore pricing AgentCore has no single price: each component bills in its own unit. The [harness has no separate charge](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-operations.html); you pay for the Runtime, Memory and tools it uses. Model tokens are billed by Bedrock or your provider. | Component | What's metered | Price | |---|---|---| | Runtime microVMs V1 | vCPU-hour / GB-hour | $0.0895 / $0.00945 | | Runtime microVMs V2 (consumption) | vCPU-hour / GB-hour | $0.1276 / $0.0169 | | Runtime V2 (committed baseline, launching by October 2026) | vCPU-hour / GB-hour | $0.0997 / $0.0132 | | Runtime Instances | Management fee per instance-hour, plus the EC2 instance in your account | % of EC2 On-Demand (12% in AWS's example), ~1-minute minimum | | Harness | — | No separate charge | | Code Interpreter, Browser | vCPU-hour / GB-hour | $0.0895 / $0.00945 | | Gateway | Tool invocations / search calls / indexed tools / egress | $0.005 per 1,000 / $0.025 per 1,000 / $0.02 per 100 tools per month / $0.006 per GB | | Identity | Token or API-key requests | $0.010 per 1,000 (no charge through Runtime or Gateway) | | Memory, short-term (from Oct 6, 2026) | Ingested / retrieved / stored | $1.00 per GB / $0.20 per GB / $0.10 per GB-month | | Memory, long-term | Records stored / retrievals | $0.75 per 1,000 records per month ($0.25 self-managed) / $0.50 per 1,000 | | Policy | Authorization requests / authoring tokens | $0.000025 per request / $0.13 per 1,000 input tokens | | Evaluations | Built-in (input / output tokens) / custom | $0.0024 / $0.012 per 1,000 tokens; $1.50 per 1,000 evaluations | | Web Search | Queries | $7 per 1,000 | | Observability | CloudWatch usage | CloudWatch pricing | How it's billed: - Runtime bills per second with a 1-second minimum and a 128 MB memory minimum. - CPU isn't billed during I/O wait on a model or tool, if nothing else uses CPU. - Memory is billed from microVM start to termination, including idle time before the timeout. V2 reclaims idle memory after 120 seconds. - Short-term Memory moves on October 6, 2026, from $0.25 per 1,000 events to the GB meters above. Ingestion and retrieval bill each event at a minimum of 12 KB and a maximum of 64 KB; storage uses the event's actual size. - Managed session storage isn't charged during its preview, and new AWS customers get up to $200 in Free Tier credits. Pricing verified October 2026, from the [AgentCore pricing page](https://aws.amazon.com/bedrock/agentcore/pricing/). *Pricing and limits change often; check each vendor's pricing page before deciding.* ### camelRun pricing - **Agent time:** $0.01 per agent-hour of active run time: time in a run (model calls and tool execution), not idle loaded time. It applies on your own model keys too. - **Storage:** $0.10 per GB-month. Idle and sleeping agents cost only storage. - **Model tokens:** billed by your provider on your keys, or charged to your credit on camelAI's keys. - **Web search:** $0.001 to $0.007 per search. - **Credit:** prepaid, with $5 free (GitHub accounts older than 30 days, or after a card check with no charge). Credit purchases carry a 5.5% processing fee. ### Example: one customer conversation on each Assume a support conversation where the agent spends **10 minutes in runs** over a 30-minute window, with no idle gap reaching 15 minutes and the final run ending at minute 30. Then the customer goes quiet. Tokens are excluded on both sides. **camelRun:** 0.167 agent-hours × $0.01 = **$0.0017**, plus a fraction of a cent of storage. **AgentCore Runtime (V1, your own loop):** assume billed usage, including system overhead, is 1 GB held and 60 vCPU-seconds; the rest of the active run time is model wait. With the default 15-minute idle timeout, the microVM lives 45 minutes. - CPU: 60 s × $0.0895 / 3,600 = $0.0015 - Memory: 0.75 h × 1 GB × $0.00945 = $0.0071 - Total: **$0.0086**, plus Memory or S3 for state that outlives the session, Gateway calls and CloudWatch. AWS's own V2 example, a 10-minute support session with 90% I/O wait and 1–2.5 GB of memory, comes to $0.0067. On this workload camelRun's platform line is lower because it doesn't bill time between runs, while AgentCore doesn't bill CPU during model waits, which camelRun does. AgentCore's memory line is the lever: a shorter idle timeout or V2 lowers it, at the cost of more cold starts. Between conversations, storing state costs $0.10 per GB-month on both (camelRun storage, AgentCore short-term Memory). Estimate your tokens before comparing platform fees. ## When to choose AgentCore - **You're an AWS shop:** procurement, IAM, CloudTrail and billing already run through AWS. - **You need enterprise controls today:** IAM and VPC isolation, Cedar policy on tool calls, GovCloud, a specific Region, or SOC, ISO and CSA STAR coverage. - **Your agent needs a computer:** a shell, Python, package installs or a real browser, as coding agents do. - **You need GPUs or multi-day sessions on dedicated compute:** use Runtime Instances. - **You already have an agent in LangGraph, CrewAI or Strands** and want managed, isolated hosting without a rewrite. ## When to choose camelRun - **Your agents live inside your product,** one per customer, ticket, thread or PR, and persist for weeks or months, not 8-hour sessions. - **Your tools are your app's APIs,** and you want them to stay in your code with your credentials. - **You want the loop, history, schedules, channels and human approvals in one product,** instead of assembling Runtime, Memory, Gateway and Identity. - **You want to self-host, or keep the option.** - **Your agents mostly wait** on people or events, and you want waiting to cost only storage. Still choosing an architecture? Our guide on [how to build an AI agent](https://camelai.com/blog/how-to-build-an-ai-agent) compares the three approaches, and [camelRun vs Claude Managed Agents](https://camelai.com/blog/camelrun-vs-claude-managed-agents) covers Anthropic's hosted option. ## FAQ **Can I self-host camelRun in my own AWS account?** Yes. It runs anywhere with Docker (linux/amd64 or arm64) and Postgres 14 or later; multi-node setups add S3-compatible storage, such as AWS S3. You operate it yourself, without AgentCore's managed IAM, policy and observability. **How is AgentCore harness different from Amazon Bedrock Managed Agents?** [Bedrock Managed Agents, powered by OpenAI](https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock-managed-agents-openai.html), is a separate product in preview since September 29, 2026. It's built on a customized version of OpenAI's Agents API, runs OpenAI models on Bedrock in three US Regions, and runs tools on compute you provide (your host or AgentCore Runtime). Harness is generally available and model-agnostic. **Can I move between AgentCore harness and camelRun?** Your instructions, model choice and tools exposed as MCP servers or OpenAPI-described APIs carry over, since both can call them. Inline functions become camelRun tool functions. Memory doesn't move automatically. ## Try camelRun camelRun runs the agent loop, keeps each agent's history and files, and wakes agents when there's work, for $0.01 per agent-hour of active run time plus model usage. Start with the [camelRun quickstart](https://camelai.com/docs/camelrun/quickstart), read the [docs overview](https://camelai.com/docs/camelrun/overview), see pricing on the [camelRun product page](https://camelai.com/run), or read the code on [GitHub](https://github.com/qaml-ai/run).