runcycles/cycles-server
Self-hosted server that enforces hard limits on AI agent spend, risk, and tool actions before execution. Reference implementation of the Cycles Protocol
Self-hosted runtime authority server for AI agents — budgets, risk, actions, tenant isolation
- Java92.7%
- Lua4.4%
- Shell1.4%
- Python1.4%
- Dockerfile0.2%
1 Review
runcycles/cycles-server is a serious implementation of a runtime authority layer for AI agents, focused on budget enforcement, tenant isolation, action control, auditability, and operational safety. The project stands out because it treats AI-agent spend control as infrastructure rather than a library convenience: reservations are created before execution, committed after successful work, released on failure, and enforced through Redis-backed Lua scripts for atomicity under concurrency. That is a strong design choice for the problem domain, especially because budget leakage and race conditions are exactly where agent governance systems tend to fail.
The repository is very well done for an early-stage open-source infrastructure project. The README gives a clear quickstart path with Docker, a manual Java/Maven path, endpoint summaries, deployment notes, TLS guidance, environment variables, and test categories.
The strongest technical signal is the attention to failure modes. reserve.lua checks frozen/closed budgets, debt, overdraft state, idempotency mismatch, unit mismatch, and multi-scope reservation state before mutating balances. The tenant-isolation integration tests explicitly cover cross-tenant create, commit, release, extend, event, decision, balance, and list access. The operations guide documents Prometheus metrics, alerting recipes, SLO thinking, tracing, and cardinality controls, which is exactly the kind of material operators need before trusting a control-plane service.
Constructive feedback is mostly around polish and adoption. The repo appears to include dump.rdb; even if it is harmless sample Redis data, checked-in database snapshots can confuse contributors and should either be documented clearly, moved under a named fixture directory, or removed.
Overall, this is a well-engineered and thoughtfully documented infrastructure project. It has strong safety instincts, real test depth, good operational material, and a clear use case in governing multi-tenant AI-agent execution. With a bit more contributor/security documentation and minor repo hygiene cleanup, it would be easier for outside teams to evaluate, adopt, and contribute to confidently.
