Runcap vs Langfuse vs LiteLLM: Where Each One Fits

You let a coding agent loose on a task. It loops. It re-reads the same files, re-summarizes the same context, retries the same failing call. Forty minutes later you check the provider dashboard and the run cost more than the feature was worth. You had four tools that could have told you, and none of them stopped it.

This is the gap most people do not notice until it costs them. The tools in this space look interchangeable from the outside, but they sit in three different places in the request lifecycle and solve three different problems. Here is the honest breakdown of where each one fits.

The three categories

Observability (Langfuse, Helicone, LangSmith). These record what your LLM calls did after they happened. Traces, token counts, latency, cost per call, evals. They are excellent for understanding behavior over time and debugging quality. They live beside the request path: the call completes, then the data flows to the dashboard. They can alert you that a budget was crossed. They cannot reach back and block the call that crossed it, because by the time the trace exists, the call is already paid for.

Gateways (LiteLLM, OpenRouter, Portkey). These sit in the request path and route. One API surface across many providers, key management, fallbacks, caching, and per-key rate limits and budgets. Their budgets are real, but they are billing-period guardrails: spend X per key per month, reset on a window. That protects you from a leaking key over weeks. It does not estimate what this specific run will cost before you press go, and it does not hard-stop a single agent that goes into a tight, expensive loop inside its allowance.

Pre-flight cost control (Runcap). Runcap is a local-first control layer for AI coding agents. For requests you route through its local gateway, its job is different from the other two: estimate the cost of a run before it starts, and enforce a configured cap that returns an HTTP 429 before a routed call is sent once spend would cross it. That cap applies only to routed requests, not to direct provider calls, subscriptions, or unrelated tools. It is built around the moment before the money is spent on a routed call, where the other two act after or on a billing window.

Side by side

The point of the table is not that Runcap wins every row. It does not. Langfuse will out-trace it; LiteLLM will out-route it. The point is the rows about the moment before a routed call is sent: estimate a routed run's cost before it starts, and cap routed requests before they leave your machine. Those are the rows that decide whether a runaway loop on a routed agent costs you a dollar or a hundred, plus the Proof Gate row that decides whether an AI-generated PR can be trusted to merge.

How the cap on routed requests works

Runcap runs a small local gateway. You point your agent's base URL at it, set a cap, and run your agent as normal. Every call you route through the gateway flows through it. Before a routed call is forwarded upstream, Runcap prices it against the live model rate and checks the running total. If forwarding the call would cross your cap, it never goes to the provider: the gateway returns HTTP 429 and the spend stays at zero for that call. Your agent sees a budget error, not a surprise bill. This applies only to requests routed through the gateway, not to direct provider calls, subscriptions, invoices, cards, or unrelated tools.

So which should you use?

This is not a cage match. These tools stack.

• You want to understand and improve quality over time across many runs in production: use Langfuse or Helicone. That is what they are for.
• You serve many users or rotate many providers and need routing, fallbacks, and per-key billing limits: use LiteLLM or OpenRouter.
• You are a developer running a coding agent (Claude Code, Codex, Cursor) on your own key and you want to estimate what a routed run will cost and enforce a cap on routed requests, plus a Proof Gate before an AI-generated PR can merge: use Runcap. It is free, MIT-licensed, and local-first.

The most common real setup is a gateway for routing, observability for after-the-fact analysis, and Runcap in front of the agent you actually let run unattended. They answer different questions: what did it do, where did it go, and how much before I let it go.

Try it

Runcap installs in one line and runs locally:

npm install -g runcap

Source and docs are on GitHub, and there is a plain-language walkthrough on the Runcap page. Everything is free, MIT-licensed, and local-first.

Cost control is one half of the story. The newer half is the Proof Gate: a pinned GitHub Action (runcap ci --mode adjudicate) that reads policy and verification rules from a pull request's base commit, checks the candidate diff against allowed scope and protected paths, replays permitted changes in a clean base checkout, and returns PASS, BLOCKED, or HUMAN_APPROVAL_REQUIRED before an AI-generated PR earns merge eligibility. It is a CI-attested replay under a documented hardened GitHub profile, not an unspoofable or fully independent check, not cryptographic proof, and not a replacement for human review. Current Proof Gate scope: GitHub Actions on Node/npm repositories. For the full walkthrough, read why a green CI check is not proof, or see the Runcap page.

The hard cap is one example of a broader principle: a serious system models the consequence of an action before it commits. The same idea shows up in making a bulk update across many locations all-or-nothing instead of letting it corrupt half of them on a failed write. I build AI cost-control and stabilization systems for solo founders and small teams. Runcap is the open-source piece of that work. If you are wiring agents into production and want a second set of eyes on where the spend and the failure modes hide, email me at kirill@launchsoloai.com with your stack and what you are running. Within 24 hours you get back a free written teardown of that one bottleneck - what I would automate, what it would take, and a fixed price - or a straight no.