What happens to each request
Six steps, in about the time of one call
Routing adds no extra round trip: the decision is made in the gateway before the request is sent.
Check the key.
The API key is looked up by its hash. Its project, budget, access rules and allowed IP ranges are checked before the request is read.
Read what the request needs.
Images in the messages, tools, a JSON schema, reasoning effort, streaming, and roughly how many tokens go in and come out.
Shortlist the models that can do it.
For a named model, its providers. For "auto", the models in the auto pool at your quality level. Anything that lacks a needed capability, or that your rules forbid, is dropped.
Rank by price, speed and health.
Unhealthy providers go to the back. The rest are ordered by your strategy: cheapest, fastest from your region, or a balance of the two.
Send, and fail over if needed.
The first choice gets the request. A timeout, a 429 or a 5xx moves it to the next provider, up to three in all; a bad request is returned to you straight away.
Record what happened.
The model and provider that answered, tokens, cost, time to first token, total time and every attempt, in your dashboard and through the API.
In 1953 an operator put each call through by hand. DigitSpace routes every request.
Switchboard operators, NIH Clinical Center, 1953. NIH History Office, public domain, via Wikimedia Commons.
One request, start to finish
A request for "auto" that needs tools. Two models qualify; the cheaper one answers on its first provider.
Shortlist, per 1M tokens in / out
- claude-haiku-5-5Anthropic · $0.10 / $0.50
- gpt-6-lunaOpenAI · $0.10 / $0.50
- gemini-3.8-flashGoogle · $0.75 / $3.75
Chosen: claude-haiku-5-5 on Anthropic, first attempt
What you control
- Which model
- Name a model to pin it, name "provider/model" to pin the provider too, or send "auto" and let routing choose.
- How good auto should be
- Economy, balanced or best, set per project or per request with "auto:economy", "auto:balanced" or "auto:best".
- What matters most
- Price, latency or a balance, set per project or per request with the X-DigitSpace-Routing header.
- Where it runs
- Pin a project to a region, or let the caller's region decide which provider is closest.
- Who may use what
- Budgets and allow or deny rules for models, providers, prices and IP ranges, per key, member and team.
What the gateway serves
| Endpoint | Format | What it does |
|---|---|---|
| POST /v1/chat/completions | OpenAI | Chat, streaming and tools for every model |
| POST /v1/messages | Anthropic | The same models through Anthropic's Messages API |
| GET /v1/models | OpenAI | Every model with a live provider (47 today) |
| GET /v1/key | DigitSpace | The calling key's usage and limits |
Text models only for now: no image generation, embeddings or audio endpoints.
Questions
.jpg){kind=link}
Does routing make requests slower?
The decision is made inside the gateway from data it already holds, so there is no extra network round trip. What you notice is the provider's own speed.
Can I turn routing off?
Yes. Name a model to always use it, and "provider/model" to always use one provider. Routing then only handles failover between that model's providers, or none if you pinned the provider.
What happens when every provider fails?
You get a 502 with a plain message after at most three attempts, and the failed attempts appear in your logs.
Is my prompt stored?
Only if your organisation turns on retention. By default DigitSpace records the request's metadata (model, tokens, cost, time) and not its content.
Read next
Live in a minute.
Create a key, change the base URL, send a request. No card needed with your own provider keys.
Start free