Option to stop Claude turns at the plan limit instead of using extra usage

[nikpietanze]

Problem

Many teams use Claude work plans (Team or Enterprise) with extra usage turned on for the whole org. When the 5-hour or weekly limit runs out, Claude Code keeps going and bills each request as extra usage, and T3 Code keeps those turns running. One long agent session can run up real cost after the limit without anyone deciding it should.

A user can't turn this off from their side. Claude Code has no flag or env var for it. Extra usage is an account or org setting on claude.ai, it's often controlled by an admin, and it applies to every tool on the account. Someone who wants to stay inside the plan their company already pays for, and only spend extra when it's really needed, has no switch to flip.

Idea / Proposal

Add a Use extra usage switch to each Claude instance in Settings › Providers › Claude. It defaults to on, so nothing changes unless a user turns it off.

When it's off and Claude reports that a request went to extra usage, T3 Code stops the turn and treats it like any other usage limit. The thread gets the usual notice with the reset time, the Limited badge, and Resume at reset / Snooze until reset. Turning the switch back on restores today's behavior.

Scope:

• Claude only. Codex reports a credit balance but not which requests used credits, so there's nothing reliable to stop on. The other providers don't separate plan usage from extra usage.
• Enforced on the server, so it applies to turns started from any client, remote connections, MCP agents and scheduled tasks.
• Known limitation: Claude only reports extra usage after a request, so the request that crosses the limit is already billed. Each send past the limit can still bill one request. Blocking sends up front would leave the message out of Claude's own transcript and break resuming after the reset. For a hard cap, a spend limit on the Claude account is still the right tool.

Related

• Option to automatically hand off to a fallback provider when hitting usage limits #15846 proposes switching to another provider when a limit hits. This idea is the simpler half: just stop. The comment there about not wanting to turn on extra usage in Claude Code comes from the same need.
• I've opened feat(server): option to stop Claude turns instead of using extra usage #17841 with an implementation, tests and screenshots. I'm happy to change the direction or scope based on feedback here, or to close it if this isn't something you want in T3 Code.

[lukelabonte]

I'd like to extend this to credit-use visibility and per-account controls across providers, where their integrations support it. The distinction between a hard spending block and a best-effort stop matters here too.

I ran into this with Codex. My included weekly allowance was exhausted, but chats kept working using an account with available credits. I didn't realize what had happened until a separate title-generation failure led to an investigation. I filed that routing bug as #27792. It shouldn't need to wait for this feature.

Status and controls in Usage → Limits

I'd like each account's limits to show:

• Included allowance and reset time.
• Whether credit or paid-overage use is allowed.
• Whether T3 activity is using credits, when the provider exposes enough information to establish that.
• Remaining credit balance or reported spending limit, when available.

Keep spendable credits, monthly spending limits, and quota-reset credits distinct. Accounts that always use paid API billing should also be separate from subscription accounts that switch to credits after their included allowance runs out.

Controls should be per account, not just per provider type. Personal and work accounts may need different policies. Keep T3-local policies per connected machine and show their scope. If a provider setting affects the whole account across machines or apps, make that clear before changing it.

Enforcement and existing quota recovery

Prefer provider-enforced “included usage only” controls where supported. If T3 can't change those through a supported integration, link to the provider's controls.

Otherwise, call the local option “Pause at included limit” rather than promising a guaranteed credit block. Stop starting further work and attempt to stop ongoing work when T3 detects exhausted allowance. Delayed usage updates, concurrent requests, provider-internal continuations, and cancellation timing can still allow credit spending. Work outside T3 isn't covered by a local policy.

When credits are unavailable or disallowed, preserve whatever T3 would normally do for an exhausted account without credits. Use the user's configured fallback where applicable, or retain the existing resume, reset, and snooze options. Check the fallback account's own credit policy too.

The policy should cover chats, subagents, schedules, retries, titles, commit messages, and review guides. Any gaps in controlling provider-internal activity should be explicit.

My preference is credit use off by default. I recognize that differs from today's behavior and this proposal's default-on approach. The final default needs implementation review. Existing and new accounts should follow the chosen default until overridden, with any change to existing behavior made clear.

Desktop and mobile visibility

A persistent indicator would make the switch visible while working. On desktop, that could be a “Using credits” label beside the lower-left usage graph or a small badge. On mobile, the narrow navigation rail doesn't have room for a label. An icon change or a small $ overlay on the existing bar-chart icon could work.

Tap or click should open the details. Hover can be an extra desktop shortcut, but shouldn't be required. Preserve the mobile tap target and straightforward access to Usage → Limits.

The global indicator should cover credit-funded activity T3 can observe, including background work on account A while the open session uses account B. Its details should identify the account, machine, and activity. Session details should identify the account serving that session.

Don't show “Using credits” just because an idle account has credits available or credit use enabled. Permission, balance, and actual use are different states. Codex may only support an inferred state rather than confirmation for each request, as the original proposal notes. Label inferred, stale, or unavailable information honestly. Clear the state when included allowance becomes available again, including after a reset.

This wouldn't buy credits, enable auto-reload, redeem reset credits, or change account-wide spending settings without an explicit action.

Related: #17704 proposed showing ChatGPT credit balances. This extends that visibility into everyday use and ties it to account-specific controls.