InfinityTranslation site

Official website:Infinity · Source code:hydro-project/infinity

Infinity is an open-source agent runtime built with Rust, developed as part of the Hydro project—a collaboration between AWS and the University of California, Berkeley—and licensed under the Apache 2.0 License. The version released on October 23, 2026, is an early research release intended for developers who need to manage a large number of long-running tasks, rather than as a ready-to-use personal chat service.Project Announcement

It addresses a very specific problem: after an agent initiates a build, waits for approval, or subscribes to external events, there may be no new work for hours. Infinity breaks down a run into pausable and resumable steps, saving sessions and state so that tool results or new messages can trigger the next step. Sessions that are on hold do not have to constantly occupy active execution slots.Operational Architecture

Core Capabilities and Use Cases

For code assistants, documentation can continue to be prepared during test runs, and a decision on whether to make fixes can be made once the results are available. For backend business assistants, they can wait for a manual decision or a webhook, rather than repeatedly checking for updates. A common characteristic of these scenarios is long wait times and infrequent events—not just a high volume of model inferences.

Infinity provides sub-agents, message queues, and asynchronous programming capabilities. The accompanying RAP protocol transmits results and subscribes to events via callbacks, and also provides an MCP compatibility layer to facilitate integration with existing tools. Using an asynchronous protocol does not automatically provide tools with reliable retries, secure authorization, or business correctness; developers must still design boundaries for actual operations.Introduction to RAP

Local processes and AWS Lambda are the two official deployment options. With the Lambda approach, computing resources are released after each execution and are restarted when the next message arrives. However, the fact that “computing resources are not consumed while waiting for a message” does not mean the service is free; charges may still apply for model invocations, state storage, messaging services, and the actual execution of tools.Deployment Guide

Understanding the “75,000 Agents” Correctly”

The official benchmark uses a simulation model in which each agent enters an idle state after performing 20 rounds of tool interactions; testing was conducted on an AMD EPYC server. Based on approximately 100 KB of resident memory per idle session, 8 GB of memory can accommodate about 75,000 sessions. This figure demonstrates the lightweight nature of the idle state; it does not mean that a Raspberry Pi can run 75,000 large models simultaneously, nor does it guarantee throughput for a real-world business operation of the same scale.Base Conditions

Let's Start with a Small Experiment

1. check or refer toOfficial Quick Start GuideSet up Rust and Cargo, create a local project, and add dependencies for the runtime, model provider, and Tokio.
2. First, run a single session and observe the event output. This tutorial uses Amazon Bedrock, which requires access to models in the corresponding region and a valid AWS configuration; model fees are billed separately.
3. Add a tool that returns results with a delay to test waiting, new messages, cancellation, and recovery, and verify that actions with side effects are not executed repeatedly.
4. Configure persistence and cloud deployment only when you're ready to go live. The in-memory storage in the getting-started example retains its state only while the process is running and should not be used directly as a failover solution.

Comparison with Other Implementation Approaches

The reason for choosing Infinity should be that its execution model aligns with the characteristics of the task, rather than simply chasing concurrency numbers.Official List of Open QuestionsThese include event interleaving, priority scheduling, long-term context compression, and event source authenticity. A more reasonable evaluation sequence is to first verify semantic recovery and access control, and then measure cost, latency, and fault behavior under the actual model.