Unified subscription and API usage with configurable fallback

[PrivateVictories-Main]

I'd like T3 to show subscription allowances and API funding together, with an optional way to continue on an approved API connection when subscription usage runs out.

In the version I'm using, adding an Anthropic API key to my Claude connection changes it to API billing, and that connection stops showing my Max subscription limits. Both forms of access still exist. Separate provider instances let me select subscription or API billing manually, but they do not solve the Usage display: Limits shows the subscription's Session, Weekly, and model-specific weekly allowances without a separate API credit balance. The Cost metric is an API-equivalent estimate, not a reading of funds remaining. I'd like both access types represented together in Usage, rather than only being available as separate connections in settings.

This applies to people who buy API access as well as people who receive credits with a subscription. Claude Max and Team currently include monthly API credits. Those credits are separate from subscription usage and can cover the Agent SDK with an API key from the linked Console organization. Other providers and API services have different billing arrangements, so the feature should support those differences rather than assume every API account has a prepaid balance.

What Usage should show

• Subscription allowance remaining, applicable model limits, and reset times for each connected subscription account, including when an API connection is also configured.
• Total usable API credits, with promotional credits and purchased or other credits shown separately. Include expiration and refresh dates where the provider reports them. The total should not count the same credit twice.
• For pay-as-you-go accounts, actual accrued spend for the billing period, the configured spending cap, and remaining budget when a cap exists. An uncapped account should say that it is uncapped, rather than display an invented credit balance.
• Auto-reload status, threshold, purchase amount, and any provider-supported limit on reloads or monthly spending.
• The active billing source for a conversation and the reason for a switch or stop.

Figures should identify the provider, account or organization, and workspace where needed. Show when they were checked and distinguish provider-reported balances from estimates. Use the provider's authoritative total and flag inconsistent or differently timed components instead of deriving a precise total from rounded or stale values. If a provider doesn't expose a balance, show that limitation and link to its billing page. Keep subscription cost estimates separate from money actually charged to an API account.

Billing options to support

The settings should represent monthly promotional credits, a fixed prepaid amount, prepaid credits with auto-reload, uncapped pay-as-you-go billing, and pay-as-you-go billing with a spending cap. Support direct provider accounts and third-party API services through the same interface where their reporting and controls allow it.

A promotional balance is not the same as permission to buy more credits or incur additional charges. Users should choose which funding sources T3 may use. Where a provider decides the order in which promotional and purchased credits are consumed, show that order and any limits on T3's control over it.

Reflect an existing provider auto-reload policy accurately. Enabling fallback should not itself enable auto-reload, raise a cap, purchase credits, or approve uncapped spending. Changes that can create additional charges need a separate, explicit choice.

Optional fallback

Offer Off, Manual, and Automatic modes. A user could continue with a manual switch, or configure an ordered set of eligible subscription accounts and API connections. Multiple subscriptions should be supported when the user explicitly chooses that order.

In Automatic mode, start with the preferred subscription. On a confirmed subscription usage limit, check the allowed fallback's funding and spending policy. Continue only when that policy permits the request. Preserve the conversation and model where the destination supports them, and clearly identify any unavoidable model or context change before proceeding.

If subscriptions and permitted API funding are exhausted, stop with one clear message explaining what ran out and when usage or credits refresh, if those dates are known. A network error, overload, or ordinary API rate limit should not be mistaken for subscription exhaustion or trigger a billing change.

After a subscription reset, an optional setting should return new work to the subscription after checking that allowance is available. Users should also be able to stay on their selected API connection or switch manually.

Spending controls and reliable readings

Allow spending caps and alerts per connection, with optional conversation, daily, and monthly limits. Account for concurrent requests and pending spend. Explain the difference between a T3 budget and a provider-enforced spending limit; delayed usage reporting and requests already in flight can affect when a local stop takes effect.

Refresh readings when Usage opens, after relevant turns, and before an automatic billing switch. Show stale or unavailable data explicitly. Unknown funding should not silently authorize paid fallback. A failed refresh should retain the previous reading as stale, rather than hide the subscription or present it as a current balance.

The normal conversation picker should be able to present one Claude option with its billing policy behind it, while Usage shows the separate subscription and API details. The same behavior should work for other supported providers and across desktop, web, mobile, and connected environments.

Claude subscription plus direct Agent SDK API credits would be a useful first implementation. The design should leave room for other providers, third-party services, and the billing types above.

[kdy1]

This overlaps with an idea I had before discovering T3 Code. I was considering building my own app, and the attached screenshot is from that project.

Models like Luna felt affordable enough to use via an API, which led me to a concept I called an Agent Worker: a reusable configuration that combines a model, reasoning effort, and one or more accounts.

For example, I could register Luna + xhigh + several accounts as a worker, then use that worker. The screenshot shows an early configuration with multiple ChatGPT subscription accounts followed by an OpenRouter API option, with accounts tried in order.

Your proposal covers much of the subscription/API routing I had in mind. The additional idea is to package that configuration as a reusable worker.

I don't yet know how to fit this into T3 Code with a good UX, or whether it would be useful in practice, so I'm sharing it here for discussion.