Published October 24, 2026 (IST) by the AgentStack News Desk. Facts were checked against the AWS Open Source Blog announcement, the hydro-project/infinity repository and documentation, and our own rerun of the project’s memory benchmark on October 24.
AWS released Infinity on October 23, 2026, an open source Rust runtime that suspends an AI agent each time it calls a tool and resumes it when the result arrives. AWS says the design fits 75,000 concurrent agents in the 8 GB of memory on a Raspberry Pi 5.
The Infinity agent runtime is a research release from the Hydro project, a collaboration between AWS and UC Berkeley, under the Apache 2.0 license. It ships with an asynchronous tool protocol called the Reactive Agent Protocol (RAP) and a coding agent called Infinity Code.
We reran the AWS benchmark and matched the 75,000-agent figure, but it holds only for agents with 20 turns of history. Each tool-calling turn added about 5 KB per agent, so agents with 160 turns fit about 10,100 to 8 GB. This report follows our editorial standards.
TL;DR
- What happened: AWS and UC Berkeley open-sourced Infinity, a Rust agent runtime, on October 23, 2026, as an early research release under Apache 2.0.
- How it works: every tool call is a suspension point, so a waiting agent is only its stored conversation history, with no task, stack, or open connection.
- Serverless: a step mode runs one slice per queue delivery, and the AWS reference deployment uses SQS FIFO, Lambda, Aurora DSQL, and DynamoDB.
- Our rerun: 10,000 agents at 20 turns used 105.6 KB each, matching about 75,700 agents per 8 GB, and memory grew about 5 KB per turn.
- Caveat: the benchmark uses a scripted model with compaction off, and throughput fell from about 18,200 to 2,500 completions per second as histories grew.
- What to do: size memory by turns per agent, and treat Infinity as a design to test, given its v0.2.0 crates and pre-release status.
What AWS Released on October 23
AWS published Infinity on its Open Source Blog on October 23, 2026, in a post by Shadaj Laddad, research lead for the Hydro team. The release bundles a runtime library, a tool protocol, a coding agent, and a reference serverless deployment, and AWS calls it an early research release shared to collect feedback.
| Component | What it does | Where it runs |
|---|---|---|
| Infinity Runtime | Runs each agent as short slices that end at every tool call and resume from stored history | Embedded in a Rust process or in step mode on serverless |
| Reactive Agent Protocol (RAP) | Fire-and-forget tool calls that post results back to a callback URL, with subscriptions | Over HTTP, with an MCP compatibility layer |
| Infinity Code | A coding agent that runs builds and tests in the background and returns diffs to review | A local daemon or a remote runtime |
| AWS reference deployment | SQS FIFO input queue, Lambda per delivery, Aurora DSQL histories, DynamoDB deduplication, EventBridge Scheduler timers | AWS, provisioned with included CDK constructs |
The hydro-project/infinity repository is written in Rust and splits into 21 crates, including providers for Amazon Bedrock and the Rig library. The core crate, infinity-agent-core, is at version 0.2.0 on crates.io. At our check it had 22 GitHub stars, 4 forks, and 120 crate downloads.
How Infinity Suspends an Agent During a Tool Call
Infinity treats each tool call the way Rust treats an await point in an async function. A slice loads the agent’s history, runs one model completion, saves the output, and dispatches at most one tool call. The slice then ends, and the tool result later arrives as a new message on the agent’s input queue.
A tool’s execute method starts the work and returns at once, then sends the result to the queue when it is ready. The architecture guide says the same path carries user text, subscription events, child thread reports, and timer wake-ups. Each conversation thread processes its messages in order, while different threads run in parallel.
Model APIs expect one result per tool call, so Infinity delivers later events as synthetic tool calls named receive_event__injected. The runtime never offers that name to the model and rejects it if the model tries to call it. A built-in spawn_thread tool uses the same mechanism, so child agents report back to their parent as events.
In step mode, nothing stays in memory between calls, and AWS says an agent waiting on a three-day CI pipeline uses no compute until the result arrives. Each input carries a stable ID, and the state store records processed IDs, so a redelivered queue message is skipped. Turns are written to storage only after they complete.
How the Reactive Agent Protocol Differs From MCP
The Reactive Agent Protocol makes tool calls asynchronous. The agent posts a call over HTTP, the tool acknowledges it, and the agent can shut down. When the work finishes, the tool posts the result to the agent’s callback URL. The Model Context Protocol, covered in our MCP explainer, keeps a request open until the tool returns.
The documentation says any MCP server works as a RAP tool through a compatibility layer, so the MCP servers teams already run stay usable. It also says MCP works fine for agents that only need quick request and response calls. RAP adds subscriptions, such as a feed of new pull requests that wakes the agent for each event.
What Our Rerun of the Infinity Benchmark Shows
We built the agent_scale benchmark from the repository at commit 341f6c2 on October 24, 2026 and ran it on an 8 vCPU Intel Xeon machine. The benchmark is single-threaded, uses in-memory stores and a scripted model, and samples process memory after each wave of agents goes idle.
Our baseline run launched 10,000 agents for 20 turns each, or 400,000 completions, in 32.3 seconds. Process memory ended at 1,056 MB, or 105.6 KB per agent. At that rate, 8 GB holds about 75,700 agents, which matches the AWS figure of about 75,000 within 1%.
The 75,000 figure describes one history length. Across five to 160 turns, each tool-calling turn added about 5 KB of memory per agent, so capacity falls in step with conversation length. Each scripted turn carries about 2.8 KB of text: two completions of 1,128 characters, a tool call, a 340 character tool result, and a user message.
| Turns per agent | Agents in run | Memory per agent | Agents per 8 GB | Completions per second |
|---|---|---|---|---|
| 5 | 2,000 | 26.0 KB | 308,000 | 18,200 |
| 10 | 2,000 | 51.5 KB | 155,300 | 18,200 |
| 20 | 2,000 | 101.8 KB | 78,600 | 14,800 |
| 40 | 2,000 | 201.5 KB | 39,700 | 9,200 |
| 80 | 2,000 | 398.6 KB | 20,100 | 5,000 |
| 160 | 1,000 | 794.8 KB | 10,100 | 2,500 |
Runtime speed also changed with history length. The single runtime thread processed about 18,200 completions per second at five turns and about 2,500 at 160 turns. That is still well under a millisecond of runtime work per completion, which is small next to the seconds a real model call usually takes.
Three limits apply to these numbers. The benchmark sets the context window to zero, which turns compaction off, so long histories never get summarized. It also uses a scripted model, so it measures runtime overhead and stored history, and real tool outputs are often far larger than 340 characters.
What It Means for Teams Running Long-Lived Agents
For teams running agents that wait on builds, approvals, or webhooks, Infinity offers a different cost model: a waiting agent costs its stored history, with no held process. Our AI agent frameworks guide covers runtimes that block on each tool call, and our Cloudflare vs Vercel vs AgentCore comparison covers hosted agent runtimes.
Memory planning should start from turns and tool output size, with agent count second. Infinity’s local driver compacts a thread at about three quarters of the model’s context window, which caps how much history each completion loads. Teams that adopt it should track history size per thread with the AI agent observability tools they already use.
AWS lists open questions in the release itself, including event authenticity: an agent exposed to the internet may receive forged event payloads. That matters for any team wiring subscriptions to outside systems, the same trust problem that applies to tools in our Agentic AI Foundation coverage and our MCP hosting platforms guide.
The project is also young and mostly maintained by AWS. Our count of its 512 commits since June 5, 2026 found 422 from amazon.com email addresses and none from a university domain, though some contributors commit from GitHub noreply addresses.
Four Steps to Take Before Trying Infinity
These steps follow from the AWS announcement, the project documentation, and our benchmark rerun. They apply to teams weighing Infinity for agents that spend most of their time waiting, and each one can be done in a test environment before any production agent moves to the runtime or to RAP.
- Measure your turns: count tool-calling turns and average tool output size per agent in your logs, then size memory at about 5 KB per turn plus your real output size.
- Rerun the benchmark: build agent_scale with your own turn count and a tool result that matches your largest outputs, and compare memory per agent.
- Test compaction: set a real context window in a trial run and check how the summaries change memory, latency, and answer quality for long threads.
- Price waiting time: compare idle cost on step mode with your current hosted runtime, using the LLM cost monitoring tools you already run for model spend.
Frequently Asked Questions
What is AWS Infinity?
Infinity is an open source agent runtime written in Rust, released by AWS and UC Berkeley on October 23, 2026 as part of the Hydro project. It suspends an agent at every tool call, stores its conversation history, and resumes it when the tool result arrives. AWS calls it an early research release under Apache 2.0.
Can Infinity really fit 75,000 agents on a Raspberry Pi 5?
The figure holds for agents with 20 tool-calling turns of history. Our rerun of the AWS benchmark measured 105.6 KB per agent at 20 turns, or about 75,700 agents in 8 GB. Memory grew about 5 KB per turn, so agents with 160 turns fit about 10,100 in the same memory.
What is the Reactive Agent Protocol?
The Reactive Agent Protocol, or RAP, is Infinity’s protocol for tool execution. The agent sends a tool call over HTTP, the tool acknowledges it, and the agent can shut down. The tool posts its result to a callback URL later. RAP also supports subscriptions that wake an agent for each new event.
Does Infinity work with MCP servers?
Yes. The Infinity documentation says any MCP server works as a RAP tool through a backward compatibility layer, so existing MCP tools keep working. MCP calls still behave as request and response calls, while RAP tools can return results hours or days later without keeping a process or connection open.
Can Infinity run on AWS Lambda?
Yes. Infinity has a step mode that runs one slice per queue delivery and keeps nothing in memory between calls. The AWS reference deployment uses an SQS FIFO queue per thread group, Lambda for each delivery, Aurora DSQL for histories, DynamoDB for deduplication, and EventBridge Scheduler for timers, provisioned with CDK.
The Bottom Line
Infinity shows that an idle agent can cost little more than its stored history, and our rerun confirmed the AWS memory figure for 20-turn agents. The same test showed that memory grows with every turn, so the useful planning number is about 5 KB per turn, with the agent count following from it.
We will update this story when Infinity publishes benchmarks with compaction on or with real model providers. Send corrections through our contact page.
Related coverage: Agent frameworks, Claude Managed Agents dynamic workflows, Agentic AI Foundation adds four projects, MCP servers, and Cloudflare vs Vercel vs AgentCore.