Put a Cost Fuse on Every Copilot CLI Run

Put a per-session AI credit limit on every unattended Copilot CLI or SDK run. Treat it as a soft fuse for one task, then keep a user-level budget as the hard monthly stop.

The limit belongs at task scope

A session limit should answer one question: how much work may this agent spend on this task before it must stop and surface a decision?

GitHub released AI credit session limits for Copilot CLI and the Copilot SDK on July 1, 2026. The feature is in public preview for Copilot for Individuals, Business, and Enterprise, and it requires Copilot CLI 1.0.66 or later or Copilot SDK 1.0.5 or later. Within the accounting window, Copilot counts model calls, subagents, and background work such as compaction. Those boundaries come from GitHub's session-limit release note.

That scope is the useful part. A monthly budget can stop a user after cumulative spend has become material, but it cannot express that a dependency update should be cheap while a cross-service migration may deserve a larger envelope. The per-session limit lets the caller attach a cost policy to the unit of work.

Each GitHub AI Credit is worth $0.01 USD. A limit of 40 credits therefore represents $0.40 of metered value for the accounting window. The 40-credit setting in this guide is an illustrative starting point, not a universal recommendation. GitHub says limits work best above 30 credits because most model calls cost more than 20 credits.

Wire the CLI limit before automation

An unattended Copilot run needs both a credit fuse and a wall-clock timeout. The credit limit bounds metered model work; the timeout bounds elapsed execution when a tool, test, network call, or permission request stalls.

1. 1

   Bring every runner to the feature floor

   Run copilot update, then keep the automation disabled on machines below Copilot CLI 1.0.66. A mixed fleet creates a policy that appears present in orchestration but is absent on older runners.

2. 2

   Use an explicit limit for interactive work

   Set the current session's allowance before the task begins:

   /limits set max-ai-credits 40

   The allowance depletes across the whole interactive session, independent of message count. Remove it only with an intentional policy change:

   /limits unset

3. 3

   Make the non-interactive flag mandatory

   Put the flag in the shared runner, not in individual prompts:

   #!/usr/bin/env bash
   set -euo pipefail
   
   : "${TASK_PROMPT:?set TASK_PROMPT}"
   : "${TASK_TIMEOUT:?set TASK_TIMEOUT}"
   
   timeout "$TASK_TIMEOUT" \
     copilot -p "$TASK_PROMPT" \
     --max-ai-credits=40

   TASK_TIMEOUT remains a deployment decision because repository size, test duration, and network dependencies differ. The fixed requirement is that both controls exist.

GitHub's Copilot CLI limit guide documents the interactive command and the --max-ai-credits flag. Interactive exhaustion prompts the engineer to reset or adjust the limit and can continue from where the agent stopped. A non-interactive run ends when it reaches the limit.

Do not map process completion directly to task success. The runner still needs evidence for the requested outcome: a passing test command, the expected files changed, a clean policy check, or an artifact ready for review. A stopped run with a partial diff is a controlled interruption, not a successful delivery.

A soft cap can overshoot

The configured number is not a guaranteed maximum charge. Copilot checks usage after a model response returns, so a response already in flight can finish before the runtime blocks the next call. A 40-credit session can therefore finish above 40 credits, and GitHub does not promise a fixed maximum overshoot.

This is why the feature is a fuse, not a finance ledger. It bounds the next decision point without terminating a response halfway through. That behavior preserves a coherent agent state, but it also means you should not promise finance that --max-ai-credits=40 is a hard $0.40 ceiling.

For a platform engineer running repository maintenance, the practical test is simple: can the orchestrator distinguish task_complete, limit_exhausted, timed_out, and failed? If those states collapse into one red status, the limit creates noise instead of control.

Make exhaustion a first-class SDK state

An SDK integration should treat budget exhaustion as a domain event that requires policy, not as an exception to retry automatically.

Set maxAiCredits when creating the session and again when resuming it. The SDK forwards that value to Copilot CLI for the current accounting window. A null sessionLimits value means no limit is active, so a resume path that omits the setting can quietly remove the fuse.

GitHub's SDK session-limit contract exposes the state you need:

• session.session_limits_changed tells the application when the active limit changes.
• session.usage_checkpoint records durable aggregate usage for resume and accounting.
• session_limits_exhausted.requested carries requestId, maxAiCredits, and usedAiCredits when the session reaches the decision point.
• session_limits_exhausted.completed records whether the response added credits, set a new maximum, removed the limit, or cancelled.

For an attended developer tool, the exhausted request can open a review prompt. For a headless maintenance job, default to cancel, persist the checkpoint, attach the partial evidence, and queue a human decision. Automatically adding credits turns the fuse into a notification that cannot stop anything.

Three controls protect three scopes

The reliable policy uses all three layers because each one stops a different failure.

GitHub's budget control documentation says user-level budgets apply across both shared-pool and metered phases. The broader spending-limit controls apply after the shared pool is exhausted, and their stop setting is off by default. A configured dollar amount without that switch is an alert, not a cap.

The per-run fuse also gives the monthly data a cause. Pair its task-class and exhaustion records with Copilot usage metrics, and a spend spike becomes traceable to a workload rather than merely attributable to a seat. For a broader tool decision, the team pricing and usage-limit comparison covers where vendor-level allowances break first.

Tune from completed tasks, not average spend

The right limit is the smallest allowance that lets a well-scoped task pass its acceptance evidence reliably. Optimizing credits per invocation rewards cheap failures; optimize credits per passing run.

1. 1

   Define stable task classes

   Separate dependency updates, test repairs, documentation changes, and multi-package migrations. Each class should share a prompt shape, tool policy, and acceptance check. A single global cap cannot express their different work envelopes.

2. 2

   Start above the documented floor

   GitHub's CLI guidance says live limits work best above 30 credits because most model calls cost more than 20 credits. The SDK documentation uses 30 in its sample, but that example is not the live threshold. Start above the documented floor, then let your own passing runs set the policy.

3. 3

   Record the decision evidence

   For every run, store the task class, configured limit, used credits at exhaustion, completion state, model, repository revision, acceptance command, and whether a human added or reset credits. Do not store source content merely to measure cost.

4. 4

   Adjust against a fixed eval set

   Replay representative tasks after changing the cap, prompt, model, or enabled tools. Track completion with valid evidence and credits per passing run. Raise the limit only when the extra allowance converts controlled stops into correct results rather than longer exploration.

GitHub's AI usage optimization guidance recommends separating research, planning, and implementation so each session carries only the context it needs. That split makes the limit easier to tune: a planning session and an implementation session can have distinct policies instead of sharing one growing conversation.

The failure modes are operational, not cosmetic

The first failure is an allowance below the cost of a useful model call. The run stops predictably but accomplishes nothing, and teams misdiagnose the result as agent instability. GitHub's above-30 guidance exists to avoid that floor.

The second failure is policy loss on resume. An upgrade bot may pause after discovering a breaking dependency, then resume later without sessionLimits. Because null means no active limit, the resumed work now has a different cost boundary from the job that created it. Test create and resume paths as one policy surface.

The third failure is an automatic top-up loop. If every session_limits_exhausted.requested event immediately adds credits, no condition can stop scope drift. Require a reviewer to see the partial diff, failed acceptance evidence, used credits, and the proposed next step before choosing add, set, unset, or cancel.

The fourth failure is using spend as the only completion signal. A run can finish under its cap and still be wrong. Keep the acceptance command as the primary gate; the cost fuse decides how long the agent may pursue that gate.

For unattended coding work, the per-run fuse is the control to install first. It creates a decision at the exact place scope and spend diverge. Monthly budgets and dashboards remain necessary, but they act after many task-level decisions have already accumulated.

Frequently asked questions

Is --max-ai-credits a hard limit?

No. It is a soft cap. A model response already in progress finishes before Copilot blocks the next model call, so actual usage can exceed the configured value.

What happens when a Copilot CLI session reaches its AI credit limit?

In an interactive session, Copilot asks whether to reset or adjust the limit and can continue from where it stopped. In non-interactive mode, the run ends.

Do subagents count toward the same Copilot session limit?

Yes. GitHub says the accounting window includes model calls, subagents, and background work such as compaction.

Does a session limit replace a Copilot user-level budget?

No. The session limit bounds one accounting window and is soft. A user-level budget governs the billing cycle across shared-pool and metered usage and always enforces a hard stop.

Which versions support AI credit session limits?

GitHub documents support in Copilot CLI 1.0.66 and later and Copilot SDK 1.0.5 and later. The feature remains in public preview.

Start the AI Coding Rollout

Turn coding-agent access, cost policy, evals, and repository controls into one rollout your engineering team can operate.