How to Set Up Per-Engineer Claude Code Keys with Hard Daily Spending Limits

If your team is running Claude Code on a single company-wide Anthropic API key, two problems are eventually guaranteed: who spent what last week, and how do you stop a runaway agent at 2 AM from burning through the rest of the month's budget?

The honest answers under a shared-key model are: "no idea" and "nothing can stop it." The fix isn't glamorous, but it works — give each engineer their own key, set a hard daily limit per person, and enforce those limits before requests reach Anthropic. This article walks through the reasoning, your options, and a complete configuration walkthrough using the TokenRouter gateway.

Why Shared Keys Don't Work

Shared keys have three structural flaws.

No attribution. Anthropic's usage dashboard reports spending at the key level. With everyone on one key, all you see is one combined number. Anthropic's own Claude apps gateway docs put it plainly: when there's a single upstream credential, "billing attributes all costs to that credential rather than to specific developers."

No per-person limits. Any limit applied to a shared key is effectively a limit on the entire team. One runaway session can eat everyone's budget.

Offboarding means rotating for everyone. When someone leaves, you have to reset the shared key for security — and that affects the whole team.

From a security audit perspective, shared keys also create compliance exposure. Frameworks like SOC 2 and ISO 27001 generally require the principle of least privilege and traceable access controls — meaning every principal needs its own credential, and every action must be traceable to a specific person. A key shared by everyone is effectively equivalent to no access control at all, and won't survive that kind of audit. On top of that, if the key is accidentally leaked (say, committed to a code repository), the blast radius covers your entire organization's API access. Per-engineer keys limit the blast radius to a single person — revocation and reissuance takes seconds without affecting anyone else.

What an Effective Limit Actually Looks Like

A spending limit is only useful if it satisfies four conditions:

1. It must block, not just report. An alert that fires after the money is already spent is just a receipt.
2. It applies to an individual, not the whole company.
3. Its failure mode must be machine-readable. Agents should receive a clear error, not a response that looks like a normal reply. There's a public Claude Code issue (anthropics/claude-code#98441) where plan-limit cutoffs returned a regular assistant turn, making it impossible for sub-agents to distinguish them from real responses.
4. It enforces before the call, not after. Claude Code's --max-budget-usd flag checks spending after each call returns — one issue (#100111) showed a 1 USD limit not stopping until $1.38. That's fine for a single headless run, but it's too loose as a daily boundary for agent traffic.

These four conditions reflect two fundamentally different philosophies: "post-hoc accounting" vs. "pre-flight enforcement." Most cloud services default to post-hoc — they let requests through, reconcile at month's end, and alert or charge on overages. That's acceptable for storage or compute, where consumption is gradual. LLM API calls are different: a looping agent with no exit condition can fire hundreds of requests in minutes and exhaust a monthly budget instantly. Agent workload limits need to be reservations — estimate the cost of a request before forwarding it, reject with an error code if it would exceed the limit, rather than waiting for the call to complete. That's the fundamental reason Claude Code's built-in --max-budget-usd isn't sufficient for agent traffic: it's a post-hoc check.

Your Options

• --max-budget-usd: A per-run boundary for headless jobs — not a per-person daily budget.
• Claude Team or Enterprise seats: Provide member-level limits for seat users, but don't cover raw API keys used directly in scripts and CI.
• Anthropic's Claude apps gateway: Self-hosted, supports per-user, per-group, and organization-level spending limits for Claude traffic.
• Self-hosted proxy with virtual keys and budgets: LiteLLM is the main open-source option here.
• Managed gateway with per-person budgets: TokenRouter is positioned here.

Full Configuration with TokenRouter

The structure is: Organization → Team → Member → Key.

1. Connect your Anthropic key. In the console, go to Provider Keys → Add Provider Key, select Anthropic, and paste your key. Provider keys are AES-encrypted at rest and decrypted in memory only at request time — they're never written to logs. Anthropic still bills you directly at your negotiated rate; TokenRouter charges a flat subscription fee, not a per-token cut.

2. Create a team and invite engineers. Under Teams → Create team, create a team (e.g., platform or mobile), then go to Members → Invite member, enter the engineer's email, leave the role as Member, and assign a team. Seat count depends on your plan: the free tier allows 1 seat and 1 team; Starter allows 5 seats; Team allows 25.

3. Set a hard daily limit for each engineer. Open Budgets → Create budget, set the scope to Member and select the engineer, set the period to Daily, enter the dollar amount, and enable Hard cap. The dialog will clearly state: "Requests exceeding the limit will be rejected with a 429 until the period resets." Alert thresholds default to 50%, 80%, and 100% — adjust as needed.

Member budgets apply to every key that engineer owns. You can layer a team budget on top as an overall ceiling — a request must satisfy both to proceed.

When does "daily" reset? Budget periods use UTC calendar day boundaries. Daily budgets reset at 00:00 UTC — which is 8 PM ET in summer (EDT) and 7 PM ET in winter (EST). The organization's timezone setting only affects how times are displayed in the console; it doesn't change when budgets reset.

4. Each engineer creates their own key. Engineers log in individually, go to API Keys → Create key, select a team, and name it something like claude-code-alice. Keys created by members are automatically bound to that member, which activates their member budget and ensures accurate attribution in analytics. Keys created by admins in the console belong to the team but not to any member — only team budgets apply to them. For per-person limits, have each person create their own key.

5. Add a rate-limit throttle. The same dialog has RPM limit and TPM limit fields, plus an optional expiry. Exceeding a rate limit returns 429 rate_limit_exceeded with a Retry-After header. Budgets handle slow consumption over a full day; TPM limits can cut off a retry loop within minutes before it burns the whole day's allowance.

6. Optional: restrict models. Each team can have a model allowlist (under Model Access or the team page). Requests for unlisted models fail with 403 model_not_allowed.

7. Point Claude Code at the gateway. On each engineer's machine:

export ANTHROPIC_BASE_URL=https://api.tokenrouter.io
export ANTHROPIC_AUTH_TOKEN=tr_your_key_here
claude

Do not append /v1 to the base URL. Claude Code appends /v1/messages automatically — adding /v1 yourself results in /v1/v1/messages and a 404. ANTHROPIC_API_KEY=tr_... also works. Recommend adding these exports to your shell profile.

8. Verify.

claude -p "Reply with exactly: routed via TokenRouter"

If the response comes back, traffic is flowing through the gateway. The request will appear under Logs within seconds, attributed to that engineer's key. Claude requests are passed through as-is, so extended thinking, tool calls, and vision capabilities behave identically to direct Anthropic access.

What Happens When the Limit Is Hit

The budget check happens before the request is forwarded. The gateway reserves a worst-case cost: an estimate of the prompt tokens, plus the maximum output token count for the request, priced at that model's rate. If "already spent + other in-flight reservations + this reservation" would exceed the limit, the request is rejected with 429 budget_exceeded and never reaches Anthropic. Once the response completes, the reservation is replaced with the actual cost calculated from precise token counts and the provider's published pricing.

Two practical implications:

• Near the limit, large requests get rejected first while small ones may still fit.
• The prompt portion of the reservation is an estimate. Treat this limit as a fairly tight guardrail, not cent-perfect accounting.

The worst-case cost reservation mechanism exists because of streaming responses: at the moment a request is sent, the server hasn't generated any tokens yet, so actual consumption is unknown — but an allow/block decision must be made immediately. The common approach is to take the max_tokens field in the request, multiply by the model's output token price, add the estimated prompt token cost, and use that pessimistic upper bound. This has a side effect: if engineers habitually set max_tokens to large values but actually generate short outputs, reservations will be significantly higher than actual spend, making the remaining balance look smaller than it really is. It's worth setting max_tokens in your prompts or configuration to something close to your actual expected output — not the model's default maximum — for more accurate reservations and fewer false rejects near the limit.

Things to Test Before Going Live

These issues apply to any gateway or proxy, including TokenRouter:

• The desktop app's Code tab currently ignores ANTHROPIC_BASE_URL in ~/.claude/settings.json, while the terminal CLI does respect it (anthropics/claude-code#97574).
• A public issue notes that any non-default base URL — even one that passes bytes through unchanged — causes lost message threads and significantly reduced parallel tool calls in headless runs (#98464). If parallelism matters to your workflow, measure before and after switching.
• Plugins that make model calls on their own may not carry custom headers (#99857).

How to Set the Right Limit

There's no universal answer, and this article won't pretend there is. A reasonable approach: disable the hard cap, enable alerts only, run for a week, observe the heaviest normal day of usage per engineer, then turn hard cap on and set the limit meaningfully above that number. The limit's job is to stop runaway loops — not to ration legitimate work. Set your TPM limit tight enough that a loop can't burn a full day's budget in a few minutes.

Handling Offboarding

Revoke the member's key on the API Keys page and remove them under Members. Everyone else continues working without rotating anything.

---

The core value of this setup is pushing attribution and enforcement down from the team level to the individual level, and making the block happen before money is spent rather than after. For any engineering team using Claude Code at scale, this is the essential step from "no idea, can't stop it" to actually being in control.