Budget Limits for Claude Code, Cursor, and Windsurf via MCP

Budget Limits for Claude Code, Cursor, and Windsurf via MCP

A developer starts a Claude Code session to clean up an auth flow.

A few hours later, the agent has read a bunch of files, rewritten services, generated tests, retried a few times, and kept going longer than expected. The work may still be useful, but the bill is now much higher than planned.

That is the gap with coding agents in Claude Code, Cursor, and Windsurf.

They are designed for long, mostly unsupervised sessions. That is the benefit. It is also the risk.

Most of the time, there is no built-in way to say:

stop after this amount

Not after one more retry.

Not after one more tool call.

Just stop.

That is where MCP becomes useful.

Why MCP matters

MCP gives coding hosts a standard way to discover and call external tools.

That makes it a clean place to add budget enforcement without wrapping every model call in application code.

With Cycles, the idea is simple:

• agent estimates the next step
• Cycles reserves budget for it
• action runs
• actual usage is committed
• unused budget is released

In other words:

estimate -> reserve -> execute -> commit/release

That is stronger than dashboards or alerts, because the decision happens before the next expensive step.

Why provider caps are not enough

Provider caps help, but they are usually the wrong layer.

They are often:

• account-level, not session-level
• vendor-specific, not workflow-wide
• blind to tool calls and other side effects

What you actually want is a runtime question:

Is this session still allowed to take the next expensive step?

That is the question a budget authority should answer.

Thin MCP setup

For Claude Code:

claude mcp add cycles -- npx -y @runcycles/mcp-server

Then set the API key:

export CYCLES_API_KEY=cyc_live_...

For Cursor or Windsurf:

{
  "mcpServers": {
    "cycles": {
      "command": "npx",
      "args": ["-y", "@runcycles/mcp-server"],
      "env": {
        "CYCLES_API_KEY": "cyc_live_..."
      }
    }
  }
}

That is the appeal here: no SDK in the project, no custom wrapper around every call, no deep integration work.

Better than a kill switch

A useful budget control system should not only say yes or no.

It should be able to return:

• ALLOW
• ALLOW_WITH_CAPS
• DENY

That middle state matters.

If budget is getting tight, the agent can finish in a constrained way instead of crashing abruptly. For example, it can reduce scope, use smaller token limits, skip expensive tools, and wrap up cleanly.

Wrapper vs authority

You can absolutely vibe-code a lightweight wrapper that tracks spend.

That is fine for a demo.

But wrappers usually break where real control matters:

• retries
• concurrency
• partial failures
• non-LLM tool actions
• inconsistent enforcement across hosts

A wrapper observes.

An authority decides whether the next action is allowed.

That is the real difference.

Closing

Coding agents are great at compressing lots of work into one session.

They are also very good at turning a simple task into many model calls, tool invocations, retries, and side effects before anyone notices.

Dashboards help.
Alerts help.
Provider caps help.

But they do not answer the only question that matters inside the loop:

should this agent be allowed to continue right now?

That is the role Cycles is trying to fill through MCP.

Original post: Budget Limits for Claude Code, Cursor, and Windsurf via MCP

Project: runcycles.io