Gateway
A routing layer for text, image and audio model requests. It speaks three client APIs and sends each request to a provider you choose.
What it is for
A given model is usually available from more than one provider. The gateway lets you choose which of them serves each request, so the provider is a configuration decision rather than something baked into your application. One endpoint, one credential, and the ability to move a workload between providers without changing client code.
Fallback routing is optional. Where you nominate an alternate provider for a target, a request that fails against the selected provider can be retried against the alternate. Where you do not, requests go to the selected provider only.
Compatible APIs
The gateway exposes three client-facing APIs. Each is a drop-in replacement for the API it is named after, so an existing client needs only its base URL and credential changed.
| API | Base URL | Notes |
|---|---|---|
| Anthropic | api.euw1.modelpond.eu/anthropic |
Messages endpoint |
| OpenAI | api.euw1.modelpond.eu/openai |
Chat completions and the rest of the OpenAI surface |
| TypeScript AI | api.euw1.modelpond.eu/ai |
For clients built on the TypeScript AI SDK |
The path segment for each API is shown as a placeholder pending confirmation; the host api.euw1.modelpond.eu is the one in use. Update the three rows above and the snippets below when the final paths are settled.
Pointing an existing client at the gateway
Only the base URL and credential change. Model names are the target model identifiers from the catalogue, with the provider prefix retained so the target is unambiguous.
Hosting
The gateway runs only on infrastructure Model Pond manages. Requests are terminated there, routed, and forwarded to the backend provider that serves the model.
Nothing else inspects the data flowing through the gateway. The only parties that see a request or its response are Model Pond's own routing layer and the backend provider serving it. No third-party inspection, analytics or content moderation sits in the path.
What is recorded
The gateway does not log requests. It records a fixed set of counters and amounts, and nothing else:
| Recorded | Detail |
|---|---|
| Time taken | Duration of the request |
| Success and failure counts | Number of requests that succeeded or failed |
| Total input tokens | Including cached input tokens |
| Cached tokens | Counted separately from total input |
| Output tokens | Tokens generated in the response |
These figures are attributed to the API key that made the request and to the target model it was sent to. Requests are recorded as having taken place within a billing period; the exact time of an individual request is not recorded. That is the whole of the record: no prompt, no response, no per-request timestamp.
Catalogue
Models available through the gateway, with the provider behind each one, the modalities it accepts and produces, and its rates, are listed on the catalogue page. Where a model is offered by several providers, each appears as its own row with the provider prefix naming the target.
What to read next
The parts of the platform people usually read after this page.