mrkeyoor.com_
Fri 30 Oct 01:46 UTC
LLM Toolsevaluationupdated 30 Oct 2026

infinity review

Hydro Project Infinity is a Rust framework for agents that yield while external tools run and resume when messages arrive. Its repository also includes Reactive Agent Protocol (RAP), with a documented MCP compatibility layer, and Infinity Code, a coding agent built around concurrent work and stacked sandboxes.

Verdict

Infinity built successfully, but the recorded test run ended with 300 passes and five failures. Rust teams interested in agents that yield while tools run have a concrete design to investigate. Verify one complete provider-and-tool conversation and inspect the failing sandbox-local target before depending on Infinity Code. Agent capacity and serverless operation remain unmeasured here.

We ran it

Lab card: what happened when we ran infinityScreenshot of infinity (infinity.hydro.run)
Install✓ · 22s572 packages
Build✓ · 385s
Tests✗ · 580s300 passed · 5 failed of 305 (cargo test)
Repo563 files~68,180 lines of source · 7.5 MB · 4 CI workflows

Answers from our run

Does infinity build from source?

Dependencies installed in 22 seconds (572 packages), and the build succeeded in 385 seconds. We cloned commit 1abc6fc into a clean Debian container with 3 CPUs and no project-specific setup.

Do infinity's tests pass?

No. The project's own test command finished in 580 seconds and reported 300 passed, 5 failed (cargo test).

Who should not use infinity?

Teams requiring a passing recorded test suite: our run recorded five failures.

What are the alternatives to infinity?

Rig, LangGraph. Infinity built successfully, but the recorded test run ended with 300 passes and five failures.

SetupN/AN/A. Installation and compilation succeeded, but provider configuration and a complete agent conversation were not reproduced. Build timings alone do not support a numerical setup rating.
DocsN/AN/A. The supplied README and architecture excerpts explain the lifecycle, but their provider and deployment procedures were not executed. This evidence does not support a scored documentation assessment.
CommunityN/AN/A. The supplied issues listing establishes reported problems, not adoption, maintainer capacity or response time. No numerical community rating is supported.
MaturityN/AN/A. Five recorded test failures require investigation, and the log omits their causes. Neither production reliability nor a completed coding workflow was established, so a numerical maturity score would overstate the evidence.

Who it’s for

Rust developers evaluating agents that wait for external tools.
Teams prepared to test message delivery and conversation storage as part of their application.
Developers who can verify their provider and MCP tools before adopting the coding or serverless workflow.

Who it’s NOT for

Teams requiring a passing recorded test suite: our run recorded five failures.
Readers seeking evidence of a completed coding task: this run did not establish that outcome.
Operators needing measured agent capacity, memory consumption or serverless cost.

Setup reality

Our October 29, 2026 run at commit 1abc6fc installed in 22 seconds and built in 385 seconds, with 572 dependencies recorded. Tests exited 101 after 580 seconds: 300 passed and 5 failed out of 305. The supplied tail identifies sandbox-local's bookmark_moved_externally test target but omits the assertions and underlying errors. It supports identifying the target, not diagnosing the cause.

The README example uses a model provider with in-memory conversation and state stores. That is a documentation example, not an agent conversation executed in our run. Provider access needs separate verification. The supplied issues listing includes an October 27, 2026 report that accounts without the hardcoded default model cannot complete a first run. This is a reported issue, not our diagnosis of the test failures.

The recorded sandbox configuration was 3 CPUs, 12 GB RAM and image lab-rust:1. The image label does not establish actual compiler or operating-system versions. We did not verify authenticated provider requests, MCP servers, AWS Lambda deployment or a completed coding task. Begin with one provider-and-tool conversation in a disposable repository, then investigate the failing test target before relying on the sandbox workflow.

Hydro Project Infinity built successfully in our sandbox, but five tests failed. For a Rust team evaluating agents that wait on external tools, that leaves two questions: does the runtime's message-based design fit the application, and does the intended workflow work at the chosen revision?

Why the waiting model matters

The README describes agents that yield while tools run and resume on the next message. Between turns, it describes conversation data without a running task, stack or open connection. These are upstream design claims; our run did not measure waiting-agent memory or concurrent capacity.

The architecture guide explains how messages connect that lifecycle. A slice loads conversation history and processed-message IDs from storage, prepares incoming messages, requests a model completion and dispatches work. RAP tool results return as later messages. Synchronous tools can execute within the slice, so yielding is not the path for every tool call.

For an application developer, the useful consequence is that storage and message delivery are part of the execution model. A successful source build alone does not verify those paths with your provider and tools.

What happened when we ran it

Our October 29, 2026 run used commit 1abc6fc. Installation succeeded in 22 seconds, and the build succeeded in 385 seconds. The record lists 572 dependencies. Tests exited 101 after 580 seconds, with 300 passed and 5 failed out of 305.

The supplied log tail identifies the sandbox-local test target bookmark_moved_externally and gives the rerun arguments -p sandbox-local --test bookmark_moved_externally. It does not include the failing assertions or underlying error messages. The cause remains unknown; the target name does not establish an operating-system problem, a missing dependency or a product defect.

The recorded configuration was 3 CPUs, 12 GB RAM and image lab-rust:1. The checkout contained 563 files, approximately 68,180 source lines and 7.5 MB of source. Those figures do not measure installed disk usage or agent memory. The scan found four CI workflow files and reported no Dockerfile or tests directory. The absence of that directory did not mean there were no executable tests.

This run did not establish model quality, authenticated provider access, MCP compatibility, AWS deployment or a completed coding task.

Evaluate the runtime and coding workflow separately

The README distinguishes Infinity Runtime, Reactive Agent Protocol and Infinity Code. It describes Infinity Code as running builds and tests in the background, editing through parallel threads with stacked sandboxes, and returning diffs for review. We did not reproduce that coding workflow.

The sandbox-local failures deserve investigation before adopting a tool built around sandboxes. They do not establish that every runtime operation fails. Use a disposable repository for the first coding trial and inspect the resulting diff.

The README says existing MCP servers run through a compatibility layer. Treat that as a compatibility claim to verify with the server you intend to use, including its authentication and error handling. The introductory provider-and-in-memory-store example is documentation only here; it was not executed as an agent conversation in our run. The linked AWS Lambda route likewise remains unverified by this evaluation.

Check provider access before the first conversation

The supplied issues listing includes an October 27, 2026 report that accounts without the hardcoded default model cannot complete a first run. That report is a reason to check model availability for the chosen provider account. It does not explain our sandbox-local test failures, and the supplied listing does not establish a fix.

The supplied release lookup resolved to sandbox-remote-v0.2.0, dated October 22, 2026. That is a component-specific release, not evidence that the whole framework passed our tests. The tested checkout remains commit 1abc6fc.

Choose the first trial by the requirement

Rig describes a Rust library for building LLM applications, alongside a terminal coding agent. Its library is another starting point when model integration is the immediate requirement. LangGraph describes a framework for long-running, stateful agents, making it another option to examine for orchestration. These are scope comparisons from their READMEs, not performance or reliability rankings.

For Infinity, first verify a complete conversation with the chosen provider and a representative external tool. Then investigate the failing sandbox-local target before relying on Infinity Code. Evaluate AWS deployment separately if the application needs it.

Alternatives

ProjectWhat it isPick it when
Rig gh↗A Rust library for building LLM applications; its repository also includes a terminal coding agent.Evaluate its library when Rust model integration is your immediate requirement. This review does not compare its reliability or performance with Infinity.
LangGraph gh↗A framework for building, managing and deploying long-running, stateful agents.Evaluate it when stateful orchestration is your main requirement and its application model fits your team. Neither alternative was run in this evaluation.

What people are saying

  1. [velocity-scout] PentagonShadeSky/Axie-Infinity-Bot
  2. [github-trending] hydro-project/infinity

Sources

  1. Hydro Project Infinity README
  2. Infinity architecture
  3. Infinity issues listing
  4. sandbox-remote-v0.2.0 release
  5. Rig README
  6. LangGraph README

More llm tools reviews

Claude-Code-Game-Studios · OmniRoute · harnessrouter · pi-subagents · kimi-code · RAG-Anything · the whole board →