The production runtime for the Cycles protocol.

Cycles defines how agents reserve budget, commit spend, and release unused reservations.

RunCycles enforces those rules in production — atomically, under concurrency, across retries.

Think: Cycles is an open protocol. RunCycles is your server.

RunCycles enforces one rule:

reserve exposure before execution, then commit actual usage or release the remainder afterward.

👉 Start with Cycles Docs
👉 Experience Cycles with Runaway Demo

👉 Read the Protocol
👉 Deploy the Reference Server

New to Cycles? Start with the protocol, then choose the implementation surface you need.

• cycles-protocol — protocol definitions, semantics, and API contract
• cycles-server — reference enforcement server for reservations, commits, releases, and balances
• cycles-server-admin — tenant, budget, API key, funding, and audit management
• cycles-spring-boot-starter — easiest way to integrate Cycles into Spring AI / Java apps
• cycles-client-python — integrate Cycles budget and risk control into Python apps
• cycles-client-typescript — budget and risk control for Node.js / Vercel AI / LangChain/ OpenAI
• cycles-openclaw-budget-guard — OpenClaw plugin for budget-aware model and tool execution using Cycles
• cycles-runaway-demo — self-contained demo showing a runaway agent failure mode and RunCycles stopping it

👉 Learn more: Cycles Docs

Autonomous systems do not fail like traditional software.

They loop.
They retry.
They fan out across tools and models.
They continue after partial failure.
They create costs and side effects that are difficult to predict in advance.

Traditional controls like rate limits, timeouts, and quotas help manage velocity.

They do not reliably bound total exposure.

RunCycles exists to enforce bounded execution under real production conditions.

Cycles is a protocol for deterministic exposure accounting in autonomous systems.

It defines:

• reserve → commit / release semantics
• hierarchical scopes for budgets and policy inheritance
• idempotent behavior under retries and concurrency
• shadow evaluation before hard enforcement
• portable invariants across runtimes and languages

Cycles is protocol-first and runtime-agnostic.

RunCycles is a production runtime that enforces Cycles semantics.

It is built for systems with:

• long-running agent loops
• tool-calling workflows
• multi-step decision systems
• normal retries, crashes, and concurrency

RunCycles turns Cycles from a specification into something you can deploy.

At a high level, RunCycles enforces a simple pattern:

1. Declare intent
2. Reserve exposure
3. Execute
4. Commit actual usage or release the remainder

This makes it possible to:

• stop work before budgets are exceeded
• avoid double-spend under retries
• reconcile actual vs estimated usage
• enforce limits across parent and child scopes
• observe and tune policies before blocking production traffic

Reserve exposure before execution.
Commit actual usage after execution.
Release unused reservation when work is canceled or costs less than expected.

Apply budgets across scopes such as:

• tenant
• environment
• application
• workflow
• agent
• tool
• run

A request can be evaluated against both local limits and inherited parent limits.

RunCycles is built for real failure modes:

• duplicate requests
• worker crashes
• partial retries
• concurrent execution
• delayed commits

Simulate, observe, and tune policies before turning on hard enforcement.

RunCycles is designed for systems where retries, crashes, partial completion, and concurrency are normal operating conditions.

RunCycles is useful when you need deterministic control over systems that:

• call LLMs repeatedly or recursively
• invoke tools with external cost or side effects
• execute background jobs or long-lived workflows
• operate across tenants with separate budgets
• need hard boundaries around autonomous execution
• must distinguish observation from enforcement

RunCycles is for teams building autonomous systems that can create meaningful cost, side effects, or operational risk.

Typical users include:

• AI platform teams enforcing tenant and workload budgets
• Agent developers building looped or tool-calling workflows
• Spring AI / JVM teams adding hard budget limits to production systems
• SaaS teams needing multi-tenant usage isolation and controls
• Infrastructure engineers handling retries, concurrency, and partial failure safely
• Gateway builders adding reservation and commit semantics to AI traffic

RunCycles is most useful when you need more than rate limits or dashboards — you need pre-execution budget enforcement.

Think of RunCycles as a budget authority for autonomous execution.

Not a billing dashboard.
Not a workflow engine.
Not a rate limiter.

It is the runtime layer that decides whether an action may proceed, how much exposure is reserved for it, and how that usage is reconciled afterward.

The open, language-agnostic specification for exposure accounting, reservations, commits, releases, scopes, and invariants.

A production implementation that enforces Cycles semantics efficiently.

Client libraries for integrating Cycles into applications and runtimes.

Current implementation focus includes:

• Python
• TypeScript Node.js / Next.js
• Java / Spring Boot

Additional language clients can be added without changing the protocol.

RunCycles integrates with systems that produce cost, risk, or irreversible side effects, including:

• LLM and inference calls
• external APIs
• database writes
• message dispatch
• payments
• deployments
• workflow fan-out
• EVM and other blockchain transactions

Web3 is one surface area, not a requirement.

RunCycles is not:

• a billing system
• a token or rewards engine
• an observability-only dashboard
• an agent framework
• a generic workflow scheduler
• an AI safety silver bullet

Its purpose is specific:

make autonomous exposure explicit, bounded, and enforceable.

Use RunCycles when your system needs:

• hard spend boundaries
• pre-execution budget checks
• retry-safe accounting
• tenant-aware limits
• hierarchical policy control
• progressive rollout from shadow mode to enforcement

If all you need is request throttling or simple usage analytics, RunCycles is probably not the right tool.

RunCycles is built around a few core ideas:

• account before enforce
• reserve before execute
• commit actuals, release remainder
• make retries safe
• keep the protocol independent of the runtime
• support shadow mode before hard stops
• treat side effects as governable exposure

RunCycles is under active development.

The protocol is stabilizing through real implementation work and will evolve with strong compatibility discipline as it moves toward v1.

• Cycles Manifesto
• Cycles Docs and API Reference

If you are building autonomous systems and need deterministic control over exposure, RunCycles is the runtime layer for that job.