Cap What Copilot Spends, Not What It Ships

Between July 1 and July 2, GitHub shipped three separate controls for managing AI spending in Copilot: per-session AI credit limits in Copilot CLI and SDK, AI credit pools for cost centers, and enterprise defaults for auto model selection. All three address the same problem: how much money an AI agent can burn through in a given session or billing period.

None of them address what the agent actually wrote.

That's not a criticism. It's a description of what these features are designed to do. Spending controls and quality controls are orthogonal problems, and confusing one for the other is the fastest way to end up with a well-budgeted disaster in production.

What GitHub Actually Shipped

The three announcements look like a coordinated rollout, and they are. Together they form GitHub's initial suite of spend controls for AI usage at scale. Here's what each one does.

Session limits in Copilot CLI and SDK

Available in Copilot CLI 1.0.66+ and SDK 1.0.5+, session limits let you cap how many AI credits a single agent session can consume. In an interactive session, you use /limits to view or set your cap. For automation, you pass --max-ai-credits to bound a single run.

The limit tracks everything: model calls, subagents, background work like compaction. When the cap is hit, the agent wraps up what it's doing and stops. It's a soft cap, though. A response already in flight finishes before the agent halts, so actual usage can slightly exceed the number you set.

This is the feature that matters most for agentic workloads. Without it, an unattended agent can loop through expensive model calls indefinitely. With it, you get a hard-ish ceiling per run.

AI credit pools for cost centers

Copilot licenses come with monthly included AI credits that pool across the enterprise. Before this update, one cost center could drain credits that another cost center's licenses paid for. The new AI credit pool feature stops that by capping each cost center's draw from the shared pool based on how many Copilot Business or Enterprise licenses it actually has.

GitHub calculates the limit automatically from assigned licenses and adjusts it as you add or remove seats. You can also decide what happens at the cap: block further included usage or let it continue as metered spend. Currently this is REST API only; the settings UI is coming.

Enterprise auto model selection defaults

Enterprise admins can now set model to auto in managed-settings.json so that new conversations start with Copilot choosing the model it thinks is best for the task. Users can still switch models per-conversation. This is an indirect cost control: auto selection tends to route simpler tasks to cheaper models, which reduces credit consumption without anyone thinking about it.

What Spending Limits Actually Protect

These features solve real, painful problems. Before session limits, a Copilot agent running in CI could chew through an entire quarter's credit budget in a single runaway loop. Before credit pools, the machine learning team's heavy agent usage could eat into credits the frontend team's licenses paid for. These were genuine gaps in enterprise AI billing, and GitHub closed them.

But notice what every one of these controls has in common: they all operate on the input side of the agent. They constrain how many tokens go in and come out. They say nothing about what the agent produced.

An agent that hits its session limit at exactly 500 AI credits might have written perfect code. Or it might have introduced a SQL injection, deleted a migration file, and silently downgraded a dependency. The spending limit doesn't know and doesn't care. Its job was to stop the meter, and it did.

What Spending Limits Don't Protect

Here's the structural issue: billing guardrails sit at the cost layer. Quality guardrails sit at the merge boundary. They're different layers of the stack, and neither substitutes for the other.

Think about it from the perspective of a platform engineer setting up Copilot for 200 developers. You configure cost centers with credit pools. You set session limits at 300 credits for CLI runs. You turn on auto model selection to keep routine tasks cheap. Great. Your CFO is happy.

Now one of those developers asks Copilot to refactor an authentication module. The agent stays within its credit limit, opens a PR, and CI passes. The diff is 400 lines across 12 files. Who reviews it?

If the answer is "another human developer who's already behind on their own PRs," you've got a bottleneck that no amount of billing optimization will fix. If the answer is "nobody, we trust CI," you've got a governance gap. CI tests what you wrote tests for. It doesn't catch what you didn't anticipate.

The spending controls GitHub shipped this week answer the question: "How do I stop Copilot from costing too much?" The question they leave open: "How do I stop Copilot from shipping something broken?"

The Two-Layer Model

A complete governance setup for agentic coding needs both layers:

1. Cost layer — caps how many tokens the agent can consume. This is what GitHub's new features cover. Session limits, credit pools, model routing.
2. Merge layer — gates whether the code the agent wrote is safe to merge. This requires reviewing the actual diff for bugs, security issues, logic errors, and things your test suite doesn't cover.

You can have perfect cost governance and still merge garbage. You can have perfect code review and still blow your AI budget. The two layers are independent. Deploying one without the other leaves a gap.

This distinction gets more important as agents get more autonomous. An agent that opens PRs on its own, without a developer actively watching the session, needs a guardrail at the merge boundary that's just as robust as the one at the billing boundary. The billing guardrail ensures the agent doesn't run forever. The merge guardrail ensures what it produced is fit for production.

Where Tenki Fits

Tenki Code Reviewer operates at the merge layer. It installs as a GitHub App, reviews every PR automatically, and can be configured as a required status check. That last part matters: a required status check can't be bypassed by a billing tier, an admin override, or a developer who's in a hurry.

The pricing model is designed for the world these GitHub features are creating. At $1 per review, it's per-review rather than per-seat. When agents start opening more PRs than your human developers do, per-seat pricing breaks down because the cost scales with headcount, not workload. Per-review pricing scales with the actual volume of code that needs reviewing, which is what you actually care about governing.

On the benchmark side, Tenki caught 84 out of 122 real production bugs in independent testing (68.9% recall), compared to GitHub Copilot's 30 out of 122 (24.6%). That's the difference between a reviewer that catches most issues before merge and one that catches about a quarter.

The practical setup looks like this: use GitHub's spending controls to manage your AI budget, and use Tenki as the required status check on your protected branches to manage what actually reaches main. The two systems don't compete. They cover different risks.

What to Do This Week

If you're a platform engineer or engineering manager configuring Copilot for your org, here's the short version:

• Turn on session limits. Update to Copilot CLI 1.0.66+ and set sensible defaults for --max-ai-credits in your automation scripts. This prevents runaway agent sessions immediately.
• Configure credit pools. If you're on Enterprise Cloud, use the REST API to enable AI credit pools on your cost centers. Keep your chargeback boundaries clean.
• Enable auto model selection. Set model: auto in your enterprise managed-settings.json. It's a low-effort way to reduce credit consumption.
• Add a merge-layer gate. None of the above tells you whether the code is good. Set up Tenki as a required status check so every PR gets reviewed before it reaches main, regardless of whether a human or an agent wrote it.

Spending controls and quality controls aren't competing priorities. They're complementary ones. GitHub just made the first half easier. Don't skip the second half.