runcycles/cycles-client-rust
Tokio-native Rust client for the Cycles protocol — runtime authority over autonomous AI agents. Cycles enforces hard limits on spend, actions, pre-execution.
Rust client for Cycles — runtime budget authority for AI agents
- Rust100.0%
1 Review
cycles-client-rust is a strong Rust SDK for the Cycles protocol, and it feels intentionally designed rather than mechanically ported from another client. The best part is the API shape: using a ReservationGuard with RAII semantics fits Rust well, especially for a reserve → execute → commit/release workflow where double-commit and forgotten reservations are real risks. Having commit(self) and release(self) consume the guard is a good use of ownership, and the with_cycles() helper gives users a simpler path when they do not need manual lifecycle control.
The README is clear and practical. It covers installation, automatic lifecycle usage, manual guard usage, lower-level client calls, error matching, environment-based config, TLS choices, and the important (scope, unit) budget invariant. The examples directory also helps adoption: basic usage, guard usage, streaming, error handling, with_cycles, and an async OpenAI completion example give people several realistic entry points instead of one artificial snippet.
The maintenance signals are better than the repo’s small adoption numbers suggest. It has 51 commits, Apache-2.0 licensing, Code of Conduct / contributing / security files, CI across stable and MSRV Rust 1.88, cargo-audit, Scorecard, Dependabot automation, docs.rs/crates.io metadata, and a detailed AUDIT.md. The audit is especially useful because it checks all 9 protocol endpoints, request/response schemas, enums, headers, validation rules, lifecycle orchestration, forward compatibility, and reports roughly 95% coverage. That is exactly the kind of evidence users want from an SDK governing spend and runtime authority.
The main polish item is release consistency. Cargo.toml and the changelog show version 0.2.6, but the GitHub releases API I checked only listed releases through v0.2.4, while the repo page surfaced older release text. If 0.2.5 and 0.2.6 are published as tags or crates without GitHub releases, adding release entries would reduce confusion. I’d also keep pushing on heartbeat/retry tests, since the audit notes lower measured coverage there. Overall, this is a credible, idiomatic Rust client with unusually good protocol-conformance documentation for such a young project.
