Token Pass Credits Now Automatically Apply to AI Gateway: No Dedicated Key Needed

From dedicated keys to automatic coverage: Token Pass billing logic has changed

In the past, using Token Pass credits often required a dedicated API key, which added extra management overhead for developers. Now, Token Pass credits automatically apply to model calls made through AI Gateway that fall within the Token Pass scope, regardless of whether the request uses a standard API key, an OIDC token, or fx login. This means you no longer need to deliberately switch keys just to consume Token Pass credits.

Of course, dedicated Token Pass keys can still be created—via the dashboard or the CLI—but their purpose is now narrowed to selected models and providers only. For most scenarios, standard credentials suffice.

The core value of this change is reduced cognitive load: teams no longer need to decide "which key to use"—billing is automatically routed by the platform.

AI Gateway is the unified entry point through which teams access various AI model providers, handling routing, authentication, billing, and observability. It abstracts away the API differences between providers, letting developers call multiple models with a single set of credentials, while centrally enforcing quotas, fallback, and data retention policies. In this article, whether Token Pass credits apply automatically depends on whether the call is made through AI Gateway—meaning the Gateway is the actual enforcement point for billing routing.

OIDC tokens (OpenID Connect tokens) are short-lived credentials based on a standard identity protocol, typically issued by an identity provider for service-to-service authentication. Compared with long-lived API keys, OIDC tokens have short validity periods, can be rotated automatically, and carry lower leak risk. In the Token Pass scenario, requests using OIDC tokens are treated the same as standard API keys—both automatically consume Token Pass credits and fall back once exhausted.

Fallback mechanism after credits run out: two key types behave differently

When Token Pass credits for a billing cycle are exhausted, the system applies different strategies depending on the credential type used for the request. Requests made with standard keys or OIDC tokens automatically fall back to the team's AI Gateway credits, and the request is not interrupted. Requests made with a dedicated Token Pass key, however, stop directly until the next billing cycle begins.

This difference has practical implications for production environments. If your services rely on continuous calls, using standard keys or OIDC tokens avoids sudden failures caused by credit exhaustion; dedicated Token Pass keys are better suited for cost-controlled experimental scenarios or boundary tests where you explicitly want "stop when used up."

From a platform design perspective, the fallback mechanism decouples "credit management" from "service continuity": credits are a budget concern, fallback is an availability concern, and the two are no longer tightly coupled.

Fallback in a billing context refers to the mechanism that automatically switches to a backup billing source or channel when the primary credits are unavailable. The fallback in this article is a billing-level switch: once Token Pass credits are exhausted, requests consume the team's AI Gateway credits instead, rather than downgrading the model or switching providers. This design turns budget exhaustion from a service outage into a cost transfer—provided the team's AI Gateway credits still have a balance.

Cognitive load refers to the hidden mental cost developers must continuously remember and actively manage—for example, remembering which key to use, when to switch, and how many credits remain. The core goal of this Token Pass adjustment is to eliminate the "choose a key" decision point, letting the platform route billing automatically and thereby reducing communication and configuration costs in team collaboration.

Zero data retention policy continues along the fallback path

On the data privacy side, requests processed through Token Pass providers still maintain zero data retention (ZDR). Fallback requests follow the team's own ZDR settings: if the team has enabled global ZDR, fallback requests are only routed to providers that support ZDR.

This is worth noting because it shows that fallback is not simply "downgrading to any available channel," but routing within the team's existing compliance framework. For teams with data retention requirements, the fallback path does not quietly bypass privacy policies.

However, the original text does not elaborate on the specific routing rules for fallback requests when the team has not enabled global ZDR; this part may require consulting the Token Pass documentation for finer-grained details.

Zero data retention (ZDR) is a privacy commitment: the provider does not store prompts, outputs, or related logs after processing a request, typically used to meet compliance or sensitive data scenarios. ZDR is not a global default but a policy that teams must explicitly configure. This article emphasizes that fallback requests follow the team's own ZDR settings, not the Token Pass provider's ZDR—meaning the privacy protection level of the fallback path depends on the team's configuration, not the Token Pass channel. With global ZDR enabled, the system only routes fallback requests to providers that support ZDR, preventing compliance policies from being bypassed during fallback.

Who it applies to and migration recommendations

This feature is currently available to Token Pass subscribers in Pro teams. If you created a dedicated Token Pass key during initial setup and want fallback capability after credits are exhausted, you need to switch to a standard API key or OIDC token.

The migration itself is not complicated, but keep two things in mind: first, confirm which services within the team still use dedicated Token Pass keys and assess whether they rely on the "stop when credits run out" behavior; second, if these services need continuity, verify after switching credentials that the fallback path routes to the team's AI Gateway credits as expected.

From a product evolution standpoint, this adjustment turns Token Pass from a separate channel requiring explicit configuration into an automatic tier within the AI Gateway billing system. For developers, that's one less key to remember and one more buffer when credits run out.

FAQ

Q: When using a standard API key, will Token Pass credits be consumed first? A: Yes. Models within the Token Pass scope automatically use Token Pass credits, with no dedicated key required.

Q: After Token Pass credits run out, will all requests fall back? A: No. Requests with standard keys and OIDC tokens fall back to the team's AI Gateway credits; requests with dedicated Token Pass keys stop until the next billing cycle.

Q: Do fallback requests still maintain zero data retention? A: Fallback requests follow the team's ZDR settings. When the team has global ZDR enabled, fallback requests are only routed to ZDR providers.