Often times damage is done by non LLM calls -- tool calls like sending email, add records, files, placing order, etc. Budget enforcement at the LLM layer wont work for those.

built an open protocol + reference implementation, handles both any tool calls, LLM calls, or any other call: https://runcycles.io, open sourced under Apache 2.0

This means agents must follow this flow: reserve, use, commit or release.

Interesting how others are handling runaway agents, loops, etc, especially under concurrency.

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.

Comments URL: https://news.ycombinator.com/item?id=47417096

Points: 1

# Comments: 2

The model downgrade is the most useful feature for daily use — when budget drops below a threshold, the plugin silently swaps claude-opus to claude-sonnet, gpt-4o to gpt-4o-mini. The agent keeps running, just cheaper. Only at full exhaustion does it stop.

The prompt hint (before_prompt_build hook) tells the model its remaining budget in the system prompt. Models self-regulate when they know the constraint exists — fewer unnecessary tool calls, shorter responses.

The underlying Cycles protocol handles idempotency under retries so concurrent tool calls don't double-spend against the same budget.

Happy to answer questions about the plugin or the protocol.

Install:

    openclaw plugins install @runcycles/openclaw-budget-guard

Built on the Cycles protocol — reserve budget before execution, commit actual spend after, release the remainder.

Plugin: https://github.com/runcycles/cycles-openclaw-budget-guard

npm: https://www.npmjs.com/package/@runcycles/openclaw-budget-gua...

Comments URL: https://news.ycombinator.com/item?id=47388702

Points: 1

# Comments: 1

The pattern is always the same: an agent retries, fans out, or loops. Each iteration passes individual rate-limit checks. Observability fires an alert after the money is gone. Provider caps are per-provider, not cross-provider. None of these stop the spend before it happens.

RunCycles takes a different approach: reserve budget before the call, commit actual spend after, release the remainder if the work is cancelled. The reservation is atomic across all affected budget scopes — tenant, workspace, agent — using Redis Lua scripts so concurrent agents sharing a budget can't collectively overrun it.

The integration surface is small:

    @cycles(estimate=50_000, action_kind="llm.completion", action_name="gpt-4o")
    def call_llm(prompt: str) -> str:
        return openai.complete(prompt)

The architecture is three pieces:

- Cycles Protocol: an open OpenAPI spec defining the reservation lifecycle, idempotency semantics, scope hierarchy, and overage policies. - RunCycles Server: Spring Boot + Redis, implements the spec. Runs in Docker. - Clients: Python, TypeScript, Java/Spring Boot.

The hardest part was idempotency under retries — if a commit fails transiently and retries with the same key, it should get the original response back, not double-charge. The Lua scripts handle this atomically.

What it's not: a billing system, observability dashboard, or agent framework. It's the layer that decides whether an action may proceed before it proceeds.

Org: https://github.com/runcycles Docs: https://runcycles.github.io/docs

Comments URL: https://news.ycombinator.com/item?id=47382742

Points: 2

# Comments: 0

One thing we’ve noticed though: spend caps stop damage, but they don’t prevent pathological behavior. By the time the cap trips, the agent has already drifted.

We’ve been experimenting with pre-authorization per action (reserve → commit style) rather than just per-key ceilings. It lets you detect anomalous patterns before the burn accumulates — especially in looping or tool-chaining scenarios.

Curious — have you seen most overruns come from loops, retries, or just high-token completions?

Your external gate instinct is right, but the gate has to be structurally external, not just logically external. If the agent can reason about the gate, it can learn to route around it.

We’ve been experimenting with pre-authorization before high-impact actions (rather than post-hoc validation) - I've drafted Cycles Protocol v0 spec to deal with this problem.

What’s interesting is that anomalous reservation patterns often show up before output quality visibly degrades — which makes drift detectable earlier.

Still early work, but happy to compare notes if that’s useful.

Comments URL: https://news.ycombinator.com/item?id=42032528

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=42027409

Points: 2

# Comments: 0