Rate limits control velocity. They say nothing about what an agent is allowed to do next.
An agent can pass every rate-limit check and still delete 400 records, send 200 emails, or place orders before anyone notices. The damage isn't always in the bill — it's in the consequence. Cycles is an open protocol for pre-execution enforcement. The core mechanism: reserve exposure before the action runs, commit actual usage after, release the remainder if it fails. Every reservation is idempotent so retries don't double-count. Atomic operations mean concurrent agents can't both see "enough budget" and both proceed. It's not a rate limiter. It's not an observability tool. It's a runtime authority that answers one question before every instrumented action: is this still allowed to proceed? Three clients: Python (PyPI), TypeScript (npm), Spring Boot (Maven Central). Self-hostable server, Apache 2.0. Integrations: OpenClaw, LangChain, Vercel, FastAPI The demo shows the failure mode in 60 seconds — same agent, same bug, two outcomes: without Cycles it burns $6, with Cycles it stops at $1. Happy to answer questions about the protocol design, the idempotency semantics, or the concurrency model. |