Skip to main content
When you call a model by slug, TokenChange picks one of the model’s endpoints for each request. This page explains how that choice is made and the request fields that change it.

How an endpoint is chosen

TokenChange considers the model’s endpoints that are serving, that your key’s scope allows and that fit your price options. Among those:
  • Endpoints that are up come first. Degraded endpoints are only used when no endpoint that’s up can take the request.
  • Traffic is shared by capacity. An endpoint with more slots receives a proportionally larger share of requests.
  • Similar requests stick together. Requests with the same prompt prefix go to the same endpoint, so the provider’s prompt cache is reused. See Prompt caching.
  • Busy endpoints are skipped. If an endpoint is near capacity, the request goes to the next choice instead of queueing.
Routing ignores price unless you set price options.

Failover

If an endpoint fails before it sends you any output, TokenChange retries the request on another endpoint. You only see the stream from the endpoint that succeeds, and the failed attempt isn’t billed.
  • A request is tried on up to three endpoints, and no new attempt starts more than 30 seconds after the request arrived.
  • Once output has started streaming, the request stays on that endpoint. If the stream breaks after that, it isn’t retried.
  • Failover stays within your key’s scope and your price options.
  • Pinned requests never fail over.
If every attempt fails, you receive an error. See Errors.

Prompt caching

Providers cache the processed start of a prompt. When the next request starts the same way, the cached part is faster to process and billed at the endpoint’s cached input price. By default, TokenChange groups requests by the start of the prompt:
  • For chat completions, the tools, the system and developer messages and the first user message.
  • For text completions, the start of the prompt.
Every turn of a conversation shares its first messages, so a conversation keeps landing on the endpoint whose cache is warm. Sampling fields such as temperature and max_tokens don’t affect this. To control grouping yourself, set prompt_cache_key. Requests with the same key go to the same endpoint while it has capacity.
Use a stable prompt_cache_key per conversation or per user session when your prompts share a long prefix that the default grouping wouldn’t detect.

Price options

Add a provider object to a request to filter or order endpoints by price. These options use the same shape as OpenRouter’s provider field.
number | string
Highest input price you accept, in USD per million tokens. Endpoints priced above it are skipped.
number | string
Highest output price you accept, in USD per million tokens. Endpoints priced above it are skipped.
string
Set to "price" to try the cheapest endpoints first. Endpoints are ordered by input plus output price, and requests are shared among endpoints at the same price. No other value is accepted.
  • If no endpoint fits within max_price, the request fails with 400.
  • Failover never moves a request above your ceiling.
  • You’re always billed at the prices of the endpoint that served the request.
To pay one exact price, pin the request to an endpoint instead.

Use price options with an OpenAI SDK

OpenAI SDKs don’t know the provider field. Pass it as an extra body parameter: