Stripe Projects vs Keybrake

Side by side

The enforcement-layer gap

Monthly aggregation vs. pre-call blocking

Stripe Projects' spend cap works at the billing-aggregation layer. When a Project crosses its monthly limit, Stripe stops billing further charges to that Project for the remainder of the month. This means the underlying vendor call — the Stripe charge, the Twilio SMS, the Cloudflare Worker invocation — can still succeed; Stripe simply doesn't forward the billing to the agent's Project after the cap. The agent has already triggered the side effect.

Keybrake's spend cap works at the request layer. When a vault key's daily cap would be exceeded, Keybrake returns a 429 to the agent before forwarding the request to the vendor. The Stripe charge is never created. The Twilio message is never queued. Nothing happens downstream.

The difference matters most in stuck-loop scenarios. A loop that fires 400 requests per second can exhaust Stripe's monthly $100 cap in well under a second of wall time — and every one of those charges already executed before the billing system caught up. At 400 req/s on a $0.50 charge, a 10-second stuck loop is $2,000 of real charges before any monthly cap fires.

The revoke-latency gap

When something goes wrong at 2am, you want the kill switch to fire in under a second — not at the next billing cycle. Stripe Projects doesn't advertise a mid-run token-revocation path that propagates sub-second. Keybrake's vault-key revoke is a single API call; the status changes to revoked in the database, and the next request from any agent using that key returns a 401. Median propagation in our benchmarks is under 5 seconds. See the 2am playbook for the full latency analysis.

The audit gap

Stripe Projects provides billing-aggregation summaries: total spend per vendor per month. There is no per-call log of what the agent actually requested — which customer ID was passed, which endpoint was hit, what the raw response was, how long the call took. This makes incident reconstruction hard. If your stuck loop hit 50 different Stripe customers before the monthly cap fired, knowing the total was $3,400 doesn't tell you which 50 customers need refunds.

Keybrake's audit log is per-call. Every request produces a row: timestamp, vault_key, vendor, endpoint, request parameters, vendor-parsed cost, policy verdict, HTTP status, latency. The rows are queryable with SELECT … WHERE vault_key = 'vault_key_xxx' AND created_at > now() - interval '10 minutes' — the five-line SQL you run first at 2am. See the audit trail schema post for the full 16-column design.

Where Stripe Projects wins

Billing-platform integration. If you're using Stripe Billing to charge your own customers for agent usage, Stripe Projects gives you token-issuance and billing aggregation in one product — without deploying any infrastructure. The 32 named partners have first-class integration: spend from Cloudflare Workers, Vercel functions, and Hugging Face inference all flows through Stripe's billing graph natively. There is no equivalent to this in Keybrake; we are an enforcement proxy, not a billing platform.

No infrastructure to deploy. Stripe Projects is a Stripe Dashboard configuration, not a service you run. For teams that want minimal ops surface, this is real value. Keybrake requires running a proxy (or using our hosted version at proxy.keybrake.com), which adds a latency hop and an operational dependency.

32-partner billing graph. If your agent stack is built entirely on Stripe's partner ecosystem — Twilio for SMS, Vercel for compute, Clerk for auth — Stripe Projects' billing aggregation already covers the spend you care about, and adding Stripe Projects costs you nothing in marginal infrastructure complexity.

Where Keybrake wins

Pre-call enforcement. The charge is blocked before it fires. Not capped monthly after the fact.

Vendor-agnostic coverage. Stripe's 32 partners are a fixed list. Keybrake works with any API you configure — including vendors that will never be Stripe partners, your own microservices, or SaaS tools your agent calls that are not on Stripe's billing platform at all.

Mid-run revoke. One API call, sub-second propagation. The right primitive for an agent that's currently running and needs to be stopped now, not at the next billing cycle.

Per-call audit log. The row you need at 2am: which endpoint, which customer, what cost, which policy verdict, in what order. Not a billing summary — a request log.

Parameter-level scope. Keybrake's endpoint allowlist goes below HTTP path to parameter values: allow POST /v1/refunds only when amount < 5000. Stripe Projects does not expose this level of control.

When to ship both

If you're billing your customers through Stripe Projects and also want per-call enforcement, the two products compose cleanly. Stripe Projects handles the billing layer; Keybrake sits on the outbound request path and enforces policy before each call leaves the agent. They don't conflict — they cover different parts of the lifecycle: Keybrake fires at request time, Stripe Projects fires at billing aggregation time.

The practical setup: issue a Keybrake vault_key instead of a direct Stripe API key; configure the base_url to proxy.keybrake.com/stripe. Keybrake enforces per-call caps and writes to the audit log; the actual charge that goes through flows into Stripe's billing graph and gets picked up by Stripe Projects. You get both enforcement layers.