Cycles

Appearance

← Blog

· Albert Mavashev · 13 min read

agentsgovernanceruntime-authoritylocal-firstbyokbudgetscost-controlcomparisonsbest-practicesmarketplace
Share Share

Local-First Agent Runtimes Need Budget Authority ​

A twelve-engineer software shop standardizes on local-first agent tools. Three engineers prefer Cline in VS Code. Four use Aider in a terminal. The rest are split between Continue and Cursor's agent mode. Most are running BYOK — each developer supplies an OpenAI, Anthropic, OpenRouter, or local-model key from their own machine. Even on the runtimes that also offer managed account-based setup, agent execution is distributed across local processes, editor windows, and developer-controlled credentials. One Wednesday, an engineer runs a research-mode Cline session that gets stuck on a refactor, calls the API two hundred times overnight, and burns $187 of personal Anthropic budget by morning. The same session also fired a deploy tool — twice — that took down staging until the on-call engineer rolled back. Nobody noticed the spend, and nobody had a way to know the deploy tool was reachable from a research-mode session in the first place. There's no shared dashboard. There's no central operator. There's no rate limiter that aggregates across the twelve developers, because each developer is on their own key, on their own machine, in their own process.

Four days later, the engineer files a Slack message titled "is this normal?" The CTO realizes the answer they need isn't "fix it for Cline" — it's what governance layer applies across all four of these runtimes at once?

The shape of the answer is the topic of this post. Local-first, BYOK, on-device agent runtimes are converging into a recognizable category — and the category has a structural governance gap that no individual runtime, provider cap, or framework limit closes by itself. The gap closes by adding an authority at a layer above the runtime, the same way Agents Are Cross-Cutting closes the gap above any single tool.

What "local-first" means as a category ​

The term covers a family of agent runtimes that share four structural characteristics:

  • Runs on the user's machine. A CLI binary, a VS Code extension, a JetBrains plugin, a terminal-native tool, a desktop app. Not a hosted SaaS. The runtime process is the user's process.
  • BYOK economics. The user supplies their own API key for OpenAI, Anthropic, Google, OpenRouter, or a local model. The provider relationship is per-user, not per-organization. Spend hits the user's account.
  • No managed control plane. There's no central operator, no admin dashboard above the runtime, no service that sees all users' sessions at once. The runtime is the binary, full stop.
  • Often, a plugin or skill marketplace. OpenClaw has ClawHub. Cline has the MCP marketplace. Continue supports cloud-managed configuration flows and local YAML configuration. Cursor has its own MCP catalog. The marketplace is upstream of every individual user's runtime, and once a developer installs a plugin, the local runtime can treat it as trusted enough to participate in the workflow.

Representative members of the category:

RuntimeSurfaceBYOKMarketplace
OpenClawLocal agent runtime; plugin lifecycleYes — user-supplied keysClawHub
ClineVS Code / JetBrains / Cursor / Windsurf / Zed / Neovim sidebar; CLI previewSupports BYOK across many providers, plus local Ollama / LM Studio; also offers managed setupMCP Marketplace
AiderPython CLI in the terminalYes — Claude / GPT / Gemini / Llama via Ollama / othersNone (CLI-only)
ContinueVS Code / JetBrains extension and agent/check workflowsSupports local and hosted model configurationCloud-managed configs / local YAML

(Cursor's agent mode and Claude Code sit on the boundary — they support BYOK but route through their respective vendors' infrastructure, which is closer to the MCP-host shape covered in Budget Limits for Claude Code, Cursor, and Windsurf via MCP. The post here is about runtimes that route directly to providers from the user's machine.)

The category's product values — local privacy, no-vendor-lock-in, BYOK economics, free-tier-friendly — are real, and they're why developers and shops adopt these tools. The same values produce the governance gap.

Where each "obvious" control falls short for this category ​

Take the four controls a CTO would reach for first, and walk through why each one fails in the local-first / BYOK shape.

Provider-side spending caps ​

Provider controls are improving, but their semantics differ. Anthropic uses prepaid usage credits, usage tiers, workspace attribution, and rate limits; exhausted credits stop API access unless the balance is reloaded. OpenAI offers soft spend alerts and optional hard monthly limits at organization and project scope; it documents that hard-limit enforcement is not instantaneous and tracked spend can slightly exceed the amount. Prepaid-credit exhaustion is a separate control. These controls are useful, but none should be described as a universal per-session boundary.

But four structural mismatches keep them blind to the local-first failure mode:

  • Provider windows and balances are not application runs. A monthly threshold, prepaid balance, or throughput interval does not automatically express a per-session or per-task budget.
  • BYOK distributes the spend across accounts. When developers use truly personal accounts (signing up with personal email, paying on a personal card), each engineer's key sits on their own billing boundary and the provider's cap sees one engineer's monthly spend — never the team's. Anthropic and OpenAI do support shared organization workspaces where billing admins can see spend across keys, which closes the cross-account aggregation gap inside the org. The cross-session, cross-runtime, and per-action governance gaps below still apply either way.
  • The granularity is provider-defined, not automatically session-defined. Projects, workspaces, keys, and cloud projects can isolate some traffic, but shared credentials do not infer a local editor session or distinguish background research from a deploy tool.
  • They don't see action risk at all. A provider cap is a cost protector. It has no concept of "this tool deletes data" vs "this tool reads files" — it can't deny a deploy call while allowing twenty read_file calls. The deploy that took down staging in the opening vignette was perfectly happy from the provider's point of view; the provider doesn't know what the tool does, only what the model call costs. The risk-tier framing is in AI Agent Risk Assessment.

Provider controls primarily protect usage within the provider's account model. They aren't designed to govern an organization's cross-user, cross-runtime, cross-session, cross-provider surface, and they don't make per-action decisions on either spend or risk. A longer treatment of the granularity / scope / delay analysis is in Cycles vs Provider Spending Caps.

Framework-internal limits ​

Some runtimes expose local request, context, approval, or configuration controls. Those can help with the simplest runaway shape, such as one process repeatedly calling a tool.

The structural problem appears when such a ceiling is stored only in one local process. Multiple editor windows, terminals, runtimes, or restarted workers then do not share one durable accounting state. Cloud-managed runtime features may close part of that gap for their own product, but they still do not automatically aggregate every local agent and provider.

Step or request limits also do not necessarily represent money or caller-assigned action exposure: two model calls can have different prices, and a file read has a different consequence from a deploy. Local circuit breakers remain useful, but a deployment needs shared state if it wants a cross-process budget authority, plus host authorization if it wants action authority. The same boundary issue appears in hosted orchestrators, as described in Agents Are Cross-Cutting. Your Controls Aren't..

Observability and cost-attribution tools ​

Helicone, Langfuse, OpenLLMetry, and others give excellent retrospective visibility. They trace, attribute cost, surface anomalies, and produce dashboards.

For local-first / BYOK runtimes, two structural mismatches keep them in the wrong layer:

  • They sit on the proxy path. Capturing spend means routing the runtime's API calls through a proxy or wrapper that the observability tool controls. Local-first runtimes hit provider APIs directly from the user's machine. Each user can install a local proxy, but that's per-user infrastructure and produces a per-user dashboard, not a team view. A team-wide proxy means routing every developer's API traffic through a shared service, which violates the BYOK / privacy values the category was chosen for in the first place.
  • They are post-hoc by design. Even if every developer agreed to a shared proxy, the dashboard reads from already-completed traces. The runaway is recorded in faithful detail; it isn't stopped at call number 50, when the damage was still $1.50. The same retrospective-vs-pre-execution argument from Runtime Authority vs Guardrails vs Observability applies — the layer is wrong for enforcement, not just for this category.

Marketplace blast-radius controls ​

This is the local-first-specific failure mode that doesn't have a hosted-SaaS equivalent. Plugin and skill marketplaces — ClawHub, Cline's MCP marketplace, Continue's hosted configs, Cursor's MCP catalog — are upstream of every user's runtime. Once a developer installs a plugin, the local runtime can treat it as trusted enough to participate in the workflow.

This is the npm / PyPI / Docker Hub trajectory, ten years compressed. Our earlier analysis cited 1,184 malicious skills reported on OpenClaw's ClawHub in early 2026; the exact number matters less than the pattern. Marketplace operators do what every package registry eventually does — they scan, they delist, they warn — but the controls are detection-after-publish, not blast-radius-at-runtime. A skill that calls send_email ten thousand times is still going to call it ten thousand times unless something on the runtime side is willing to say no. Cost limits help here only incidentally; the real defense is action-tier classification — knowing that send_email, deploy, and delete_* belong to risk tiers that warrant tighter caps regardless of how cheap each call is.

Agent Skills Are the New Supply Chain makes the broader argument. The local-first version is sharper because each user's runtime is independently trusting the same marketplace, and there's no shared service to enforce per-skill caps across the team.

What's structurally missing ​

Each control above fails for a different reason. The reasons share a shape:

ControlWhat it can seeWhat it can't see
Provider controlsVendor account/project/workspace usageCross-provider sessions, application tools, and action-risk decisions
Framework limitOne processOther processes, other users, other runtimes
ObservabilityPast traces (if proxied)Pre-execution decisions
MarketplacePublished skillsPer-runtime per-skill blast radius

Nothing in that table sees the team-level, cross-runtime, cross-user, pre-execution decision surface that local-first agents collectively act on — for either spend or action risk. No individual control evolves into that thing, for the same reason no provider cap evolves into a cross-provider authority — it's a layer mismatch, not a feature gap.

The missing piece has a recognizable shape:

  • External to the runtime. Lives outside Cline, Aider, Continue, OpenClaw, so it can see across whichever ones the team uses simultaneously.
  • Per-user and per-session scoped. Each developer's spend and action attempts are visible to the team's enforcement layer even though the API key isn't. Spend lands on the user's provider account; the decision lands on the team's authority.
  • Pre-execution. A reserve-commit primitive that runs before the action. By the time the bill — or the deploy — lands, it's too late.
  • Cost and caller-assigned risk in the same budget primitive. A reservation can ask whether the remaining USD, token, credit, or RISK_POINTS budget can cover an estimate. The application assigns risk points; the current server does not infer an action tier or maintain an action registry. The risk-tier framework in AI Agent Risk Assessment is an application pattern.
  • Three-way decision. ALLOW, ALLOW_WITH_CAPS, and DENY let a dry-run or preflight decision suggest graceful degradation. A live reservation instead returns ALLOW or ALLOW_WITH_CAPS, or rejects insufficient budget. The general framing is in Caps and the Three-Way Decision Model.
  • Marketplace context supplied by the caller. A hook or wrapper can record plugin, skill, and MCP-server identifiers as action or metadata fields and reserve against a relevant budget. Cross-runtime tool permission rules still have to be enforced by the host, gateway, handler, or another mandatory policy boundary.

These properties don't fall out of any one runtime's roadmap. They fall out of "the team needs to govern across the four runtimes its developers chose, on both cost and side-effect risk, and none of those runtimes is going to grow into the others."

The OpenClaw chapter ​

OpenClaw was the first runtime in this category where the Cycles team shipped a complete cost-and-action-authority integration end-to-end. Its five-hook plugin lifecycle — before_model_resolve → before_prompt_build → before_tool_call → after_tool_call → agent_end — is well-suited to hosting one: pre-execution decision points on every model and tool invocation, plus a session-end reconciliation hook. The same hooks that decide spend also decide whether a tool with a higher risk tier (send_email, deploy) is allowed in this session at all. (Cline and Continue have MCP support that could host an external authority via the MCP-server pattern; the OpenClaw integration just happened to ship first.)

The four existing posts in this series document what that integration looks like end to end:

That stack is one runtime's chapter of the category-level pattern. The reusable parts are a pre-execution decision, scoped budgets, three-way decisions, and caller-supplied marketplace context. Other local-first runtimes may need similar controls in shapes that fit their own hook and execution models.

What the rest of the category looks like at scale ​

Cline, Aider, and Continue today rely on user-side discipline: your own monthly cap, your own self-imposed session ceiling, your own habits. At single-developer scale this works. At team scale — five developers, twelve developers, fifty developers, all on personal keys — it doesn't, for the same reasons it didn't work for OpenClaw before the plugin existed.

Possible integration shapes when these runtimes need a governance layer:

  • Native plugin lifecycle, the OpenClaw shape. Cleanest. Requires the runtime to expose hook points; not all of these runtimes do.
  • MCP server, the Claude Code / Cursor / Windsurf tool-exposure shape. MCP support makes Cycles tools available, but a host hook or wrapped handler is still required for hard enforcement. CLI-first runtimes that don't host MCP natively need a different shape.
  • CLI wrapper, the Aider-friendly shape. A script around the runtime that intercepts each API call and consults an authority. Works for any binary; trades elegance for portability.
  • Shared local proxy, the team-deployed shape. A small process every developer's runtime points at, which talks to a central authority. For a hard budget, the proxy creates a live reservation before allowing the local runtime to call the provider, applies any returned caps, then commits best-known actual usage or releases only an unused hold. Prompt bodies and provider responses need not pass through it. A non-locking decide call alone is advisory and can race under concurrency.

None of these is the right answer for every runtime. The constant is the layer: an authority that sees what no individual runtime can see, that decides before the action runs, and that scopes per-user/session/team rather than per-account/month.

The takeaway ​

Local-first agent runtimes are a category, and teams using several of them can develop a governance gap that no single runtime, provider control, or observability product sees end to end. The gap spans uncontrolled cost and action risk. Cycles can reserve and settle spend or caller-assigned RISK_POINTS; the application still classifies actions and enforces permissions at a mandatory execution boundary. OpenClaw's plugin and the four-post series above are one worked example when a runtime exposes the necessary hooks. Other runtimes need an integration shape that fits their own execution model.

The pattern recurs because it's structural. Provider caps are at the wrong granularity. Framework limits are at the wrong scope. Observability is at the wrong moment. Marketplaces are at the wrong layer. None of them sees both spend and side-effect risk on the same decision. The only thing that closes a layer gap is a layer.

Resources ​

Last updated: