PaceKeeper

Give every customer their own AI budget

PaceKeeper is a BYOK gateway that paces AI spend per customer, plan, or key – and can block new requests at a configured threshold.
Replace surprise bills with explicit budget guardrails.

Join free betaSee How It Works ↓
  • A budget per customer, plan, or key
  • Control actions show what changed and why
  • BYOK – add one header, provider keys stay yours

QUICK SELF-CHECK

Does this sound like your team?

  • One power user or runaway integration quietly eats the margin of a whole plan tier

  • A launch or viral spike turns a normal week into a surprise invoice

  • Provider dashboards show yesterday's total– not which customer burned it

  • You need separate budgets per customer, team, or tier– not one global cap

  • Provider-level caps stop your whole app– not just the tenant that misbehaves

PaceKeeper is the fix:a budget for every key, customer, and tier – enforced in the request path.
Pacing first, with a configured block threshold only when you choose it.

SOLUTION

The Missing Layer
Between Your App and Your LLM Bill

Swap your base URL to PaceKeeper's gateway and add x-pk-key.
Set a budget per API key – or per customer, with one x-pk-tenant-id header.
PaceKeeper applies each budget in the request path: pacing first, a configured block threshold as a safety valve.

Your app
Backend or BYOK app
Your SaaS backendBYOK appInternal GPT
AI request
PaceKeeper
Budget Monitor + Control Loop
Checks spend vs. budget paceAdjusts output ceiling (max_tokens)Logs every action with its reason
On-budget request
LLM Provider
Any OpenAI-compatible endpoint
OpenAIAzure OpenAIOpenRouterLiteLLM instanceClaude & Gemini next
01

Budgets that bend before they break

As a budget runs hot – a product launch, a viral moment, one heavy customer – PaceKeeper lowers the output-token ceiling gradually, long before any limit is hit.

If recorded spend crosses the configured threshold, you choose what happens: warn and keep serving, or block new requests until the next cycle. The outcome is explicit in the policy.

02

Tenant-aware with one header

Send x-pk-tenant-idfrom your app and every customer, plan tier, or team gets its own budget identity – spend, pressure, and control actions tracked separately.

No tenant id? The PaceKeeper key itself is the budget. Issue one per service, client, or environment.

03

One lever today, more coming

The beta controls one thing: the output-token ceiling (max_tokens). It is simple, visible, and reversible – recorded control actions include the original value, the applied value, and the reason.

  • Model routing – planned: shift to cost-efficient models under rules you define, never silently
  • Context optimization – planned: trim input-side cost as a separate, explicit service

Beta users get first access as each lever ships.

COMPARE

Same traffic.
Two very different bills.

Without PaceKeeper

Random drift
  • One spike can blow the whole month
  • You find out about overruns on the invoice
  • No idea which customer burned the budget
  • Caps are manual, disruptive, or missing
  • Provider dashboard reports after the fact
  • Scramble to explain variance to your boss
Planned spend by days$600Actual spend$600

With PaceKeeper

Near plan
  • Pressure rises smoothly as spend drifts
  • Output ceilings adjust before overrun
  • A block policy stops new requests past your threshold
  • Each customer can use its own budget identity
  • Request-level control-action records
  • Plan vs. actual in concierge beta reports
Planned spend by days$600Actual spend$600

Simulation only. Illustrates the concept – not a forecast.
Real results depend on traffic, prompts, and model mix.

TRY IT FIRST FOR FREE

Join the PaceKeeper Beta

Connect your endpoint. Set budgets per customer or key. Watch every adjustment in the action log. We'll onboard you personally – free during beta, no credit card.

Free concierge beta

No credit card, with direct onboarding during beta

Direct line to the engineering team

Your feedback shapes what we build next. Not a form. A conversation.

First access to new capabilities

New providers, new control levers, new policies – you get them before anyone else.

TRUST & GOVERNANCE

Built For Builders
And Budget Owners

Bring your own keys – forwarded in-flight, never stored – and keep control decisions inspectable.

CTO

Operationally simple

  • Drop-in OpenAI-compatible gateway

    Swap the base_url and add yourx-pk-key. Your SDK, prompts, and request shape stay the same.

  • BYOK — no secrets at rest

    Your provider key stays in your stack and is forwarded in-flight only. PaceKeeper never stores it – not in the database, not in logs.

  • A failure-isolated beta contract

    The local parity harness verifies unchanged pass-through on control failure and response preservation on accounting failure. The deployed beta must pass the same cases.

  • No black box

    Recorded control actions state what changed, which budget they protected, and why. Incomplete accounting is explicit instead of appearing as zero spend.

  • A thin proxy, measured in the open

    Most traffic is pass-through with an inline budget check. Gateway overhead is measured and published during beta – and you can A/B against passthrough mode anytime.

  • Multi-tenant from day one

    Issue a key per client or environment – or send x-pk-tenant-id per request. Each identity gets its own budget, pacing state, and action log.

CFO

Financially governable

  • A threshold finance can plan around

    Set the budget and overage allowance. Pacing adjusts output as traffic changes, and a block policy stops new requests after recorded spend crosses the threshold.

  • Margin per customer, not per month-end

    Per-customer, per-tier budgets keep unit economics intact when a power user shows up – without manual intervention.

  • Clear spend attribution

    Usage with known provider pricing is attributed to a budget identity. Missing usage, pricing, or persistence is marked incomplete instead of silently reported as zero.

  • Audit-ready from day one

    Control-action records capture what changed, when, why, and which budget was protected. Concierge beta reports expose those records while self-serve export remains future work.

  • Never a percentage of your LLM spend

    Provider costs stay on your own provider bill, at cost. PaceKeeper charges for the gateway – our incentives point at protecting your budget, not growing it.

USE CASES

Built For Teams
Shipping AI Into Production

  • B2B SaaS

    Your customers use AI features at wildly different rates. PaceKeeper keeps LLM COGS stable per customer, seat, or plan tier – so your margins don't collapse when a power user shows up.

  • Multi-Tenant Platforms

    Enforce per-tenant budgets with an API key or a single tenant-id header. When one tenant spikes, their output paces down – not everyone else's. No noisy-neighbor cost blowups.

  • Internal AI Rollout

    Give every department an AI budget. Engineering, marketing, support – each gets their own cap with a shared audit log that finance and security can actually defend.

  • Burst & Seasonal Traffic

    Support queues spike. Product launches surge. Incident response floods your AI pipeline. PaceKeeper smooths the cost curve so bursts don't become budget emergencies.

  • Pre-Scale Launch

    Shipping a new AI feature? Set the budget before go-live. If adoption exceeds forecasts, PaceKeeper paces output and can block new requests at your configured threshold.

FAQ

How does integration work?
Two small integration changes – swap your base_urlto PaceKeeper's gateway and add your x-pk-key. Your existing SDK, prompts, and request shape stay exactly the same.

It's BYOK only: your provider key travels in the Authorization header as usual, is forwarded in-flight, and is never stored. Optionally send x-pk-tenant-id to give every customer, team, or tier its own budget.
Is this a hard spending cap?
PaceKeeper can block new gateway requests at a configured threshold – per budget.

By default PaceKeeper paces: as a budget runs hot, the output-token ceiling lowers gradually. At the hard-limit threshold, you decide whether PaceKeeper warns and keeps serving or blocks new requests. The threshold can include an overage allowance, and usage already in flight can still land above it, so it is a request-path guardrail rather than an exact provider-bill cap.
What exactly does PaceKeeper change in my requests?
In beta, one thing: max_tokens– the output-token ceiling.

The model is never switched, prompts and responses are never modified, and each recorded control action includes the original value, the applied value, and the reason. Model routing and context optimization are future levers that will always be explicit, user-configured controls.
Will my users notice a quality drop?
At low budget pressure, PaceKeeper keeps your requested output ceiling when it is within the configured normal cap. If max_tokens is omitted or higher than that cap, PaceKeeper applies the normal ceiling and logs the change.

Running hot: responses can get shorter. That's the honest mechanism, not a side effect – a lower output ceiling is how spend is paced. PaceKeeper never lowers its applied ceiling below your configured floor, although callers can request less and models can finish earlier. Recorded control actions let you inspect the trade-off with real data.
Can I set separate budgets per client, team, or tier?
Yes – this is the core feature, not an add-on.

Issue a separate PaceKeeper key per client, tier, or service – or simply send x-pk-tenant-idon each request and PaceKeeper tracks a budget per tenant automatically. Each identity gets its own budget, pacing state, and action log. When one client spikes, their output paces down – not everyone else's.
What happens if PaceKeeper's control path fails?
The beta contract is fail-open after PaceKeeper validates your key and provider route: controller failures forward the original request once, while accounting failures preserve the successful provider response.

The local parity harness verifies those cases; the beta is not release-ready until the deployed gateway passes them too. Invalid or revoked PaceKeeper keys still fail closed, and a total gateway or DNS outage is a separate availability problem.
How is this different from LiteLLM or Helicone?
LiteLLM is a great self-hosted proxy – if you want to deploy, monitor, and upgrade your own gateway. Helicone leads with observability: seeing what you spent.

PaceKeeper is hosted budget enforcement for product budgets: a threshold per customer or plan tier, paced in the request path before an optional block policy stops new requests. The hosted beta uses one gateway URL and one PaceKeeper header – and BYOK means trying it costs nothing to reverse.
Which providers are supported?
OpenAI-compatible chat completions first: OpenAI, Azure OpenAI, OpenRouter, or any endpoint that follows the OpenAI API spec – including your own LiteLLM deployment.

Streaming requests pass through incrementally with the same pre-flight decision. PaceKeeper records usage from the final stream event when the provider includes it and marks accounting incomplete when it does not. Anthropic (Claude) and Google (Gemini) native protocols come after beta.
What exactly do you log or store?
We do notstore prompt content, response content, or provider API keys – ever.

When provider usage and pricing are available, PaceKeeper keeps request-level metadata such as timestamp, token counts, model, and computed cost, plus the control action record. Missing usage, pricing, or persistence is treated as incomplete accounting rather than invented zero spend. Nothing your users say to your app is retained by ours.
How do I know it's actually working?
Recorded control actions include the original max_tokens, the applied value, the budget pressure that caused it, and the budget identity it protected.

During the concierge beta, PaceKeeper provides those records and spend summaries directly. A self-serve dashboard and exports are future control-plane capabilities, not part of the current promo application.
What does PaceKeeper cost?
The concierge beta is free – no credit card, with direct onboarding and a direct line to the engineering team.

Paid plans come after beta and will be priced on gateway usage – never a percentage of your LLM spend, which stays on your own provider bill. Beta users get advance notice and early-user pricing before anything changes.
What if I want to switch PaceKeeper off to compare?
You can – without touching your setup or keys.

During the concierge beta, ask us to put the applicable budget policy into passthrough mode: traffic flows to your provider unchanged, with no budget control applied. Self-serve account and key controls belong to the future control plane.