Helix Payment Recovery Runtime
A self-healing runtime that diagnoses, repairs, and remembers failures in autonomous-agent payment and API calls.
- Source repo
- usehelix/helix
- Stars
- ★ 827
- Last updated
- 3mo ago
- License
- MIT
- Primary language
- TypeScript
- FA score
- 51/100 · Major gaps
At a glance
- Works with
- Universal · cross-platformCodex · Claude Code
- You'll need
- Typical use
- A team running on-chain agents with Coinbase, ERC-4337, or x402 payment paths needs a recovery layer for nonce, gas, or transaction-execution errors.
- Main limitation
- Direct payment support is limited to Coinbase, Tempo, Privy, and generic HTTP; other platforms require a custom PlatformAdapter.
- Source review
- 51/100 · Major gaps
What does this agent do, and when should you use it?
Helix is a self-healing runtime for autonomous agents, focused on payment execution and API-call failures. It wraps an async function and applies a six-stage PCEC flow: Perceive, Construct, Evaluate, Commit, Verify, and Gene. Verified repairs are retained in a SQLite-based Gene Map with reinforcement-learning scoring, so recurring failures can reuse prior strategies. The project exposes @helix-agent/core alongside a Python package, Docker server, REST endpoint, and CLI; its payment adapters cover Coinbase, Tempo, Privy, and generic HTTP. Helix is built as a payment vertical on VialOS Runtime and can be extended to other domains through the PlatformAdapter interface.
A developer wraps an asynchronous operation with wrap(myFunction, { mode: 'auto' }). When the operation fails, an adapter classifies the error, Helix constructs and scores candidate fixes, executes an allowed strategy, verifies the result, and records a successful repair in the Gene Map. Documented strategies include refresh_nonce, speed_up, reduce_request, backoff_retry, renew_session, split_transaction, and remove_and_resubmit. A local service accepts JSON error and platform values at POST /repair; the CLI can scan source with npx @helix-agent/core scan, dry-run a diagnosis with simulate, discover errors with self-play, and consolidate memory with dream. observe diagnoses only, auto changes parameters and retries, and full additionally enables fund-movement strategies.
- A team running on-chain agents with Coinbase, ERC-4337, or x402 payment paths needs a recovery layer for nonce, gas, or transaction-execution errors.
- A product using Tempo MPP, session, or DEX flows wants verified recovery decisions retained in local SQLite memory.
- An application built around Privy embedded wallets needs controlled diagnosis and retry handling for known wallet failures.
- A service engineer needs recovery for outbound API failures such as 429s, 5xx responses, timeouts, connection errors, or authentication failures.
- An engineering team wants to run npx @helix-agent/core scan ./src before CI/CD to identify documented error patterns in a codebase.
- A platform developer needs domain-specific recovery behavior and can implement PlatformAdapter with perceive and getPatterns.
How do you install or deploy this agent?
TypeScript/JavaScript:
npm install @helix-agent/corePython:
pip install helix-agent-sdkDocker server:
docker run -d -p 7842:7842 adrianhihi/helix-serverThe documentation does not specify Node.js or Python versions, nor any credentials or environment variables required for the first invocation.
How do you use this agent?
Minimal TypeScript usage:
import { wrap } from '@helix-agent/core';
const safeCall = wrap(myFunction, { mode: 'auto' });
const result = await safeCall(args);
Start the local server and dashboard:
npx @helix-agent/core serve --port 7842Call the repair endpoint:
curl -X POST http://localhost:7842/repair -H 'Content-Type: application/json' -d '{"error": "nonce too low", "platform": "coinbase"}'Do not use npx helix: the documentation explicitly says it installs an unrelated third-party package.
What are this agent's strengths and limitations?
- PCEC provides an explicit six-stage path from diagnosis through verification and retained repair knowledge, rather than a blind retry loop.
- The SQLite-backed Gene Map records and scores successful repairs, enabling reuse for recurring errors.
- It includes Coinbase, Tempo, Privy, and generic HTTP adapters while exposing PlatformAdapter for new domains.
- It can be consumed as an npm library, Python package, Docker service, REST endpoint, or CLI workflow.
- The documented observe, auto, and full modes make recovery scope selectable; the README also states seven pre-execution constraints and no modification of recipient or calldata.
- Direct payment support is limited to Coinbase, Tempo, Privy, and generic HTTP; other platforms require a custom PlatformAdapter.
- auto changes parameters and retries, while full enables fund-movement strategies, so teams must select a mode appropriate to their risk controls.
- The core depends on VialOS Runtime for PCEC, Gene Map, and learning modules, which introduces that runtime architecture into an adoption.
- No pinned Node.js or Python versions, production authentication details, persistence-location guidance, or high-availability setup are documented.
- The listed benchmarks and error-pattern counts do not include independent validation material beyond the repository's evaluation harness reference.
How does this agent compare with similar options?
Against Sentry/Datadog, Helix is positioned to attempt and verify repairs rather than only detect and report errors. Against simple retries, it selects strategies by error pattern and stores successful repairs in the Gene Map. The README comparison also claims federated cross-agent learning and seven safety checks, making it a fit for paths that need active recovery rather than observability alone.
Key facts side by side with the most closely related agents.
| Agent | Source review | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|
| Helix Payment Recovery Runtime This agent | 51 · Major gaps | ★ 827 | 3mo ago | TypeScript | Codex · Claude Code |
| OpenFang | 56 · Major gaps | ★ 18k | 2mo ago | Rust | OpenAI API · Claude API |
| Osmedeus — Modern Security Orchestration Engine | 48 · Major gaps | ★ 6.6k | 11d ago | Go | — |
| ClickClickClick | 23 · Major gaps | ★ 712 | 6mo ago | Python | OpenAI API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows mode selection (observe/auto/full) and 7 safety constraints, but no user confirmation mechanism or detailed data flow transparency. Sensitive data handling (e.g., keys) not explicit. Many third-party dependencies without security audit. External effects (e.g., payment transactions) have safety constraints but no user confirmation. Rollback mentioned (auto-rollback) but not detailed. Source attribution: publisher unverified, but code has copyright notice. Deductions: lack of user confirmation, data flow transparency, and sensitive data handling evidence.
Self-consistency: README and tests align, but some tests contradict descriptions (e.g., getPatterns returns 22 not 21). Dependency availability: many external packages without lock or mirror. Failure messages: tests cover error classification but no user-visible failure messages. Deductions: test/doc inconsistency, un-locked dependencies.
Audience and scenarios: developer-oriented, multiple integration methods. Capability boundaries: defined via modes and adapters. Trigger precision: error pattern matching tested but no false positive rate. Environment fit: supports Node, Python, Docker but no environment requirements. Deductions: insufficient evidence for trigger precision and environment.
Information architecture: README clear but missing API docs. Install notes: npm, pip, Docker provided. Naming stability: package and CLI names changed (npx helix warning). Examples and FAQ: present. Known limitations: not listed. License: MIT. Versioning/changelog: not provided. Maintenance responsibility: not clear. Deductions: missing API docs, known limitations, changelog, maintenance responsibility.
Output usability: multiple interfaces (CLI, REST, SDK). Marginal value: self-healing unique. Cost-benefit: claims reduced repair cost but no detailed analysis. Deductions: insufficient cost-benefit evidence.
Claim traceability: benchmarks in README lack detailed data or reproduction. Cross-source corroboration: no independent verification. Fact/inference separation: not explicit. Deductions: lack of verifiable evidence.
- Publisher unverified, identity unknown.
- Many third-party dependencies without security audit.
- Test/doc inconsistency (e.g., getPatterns returns 22 not 21).
- Benchmark claims lack detailed data and reproduction.
- Missing API docs, known limitations, and changelog.