Routing: How Your Input Reaches the Right Model
Every model accepts every modality. Which upstream handles your turn is decided server-side, from live measurement — here is exactly how.
A ZYRAXON model id is a stable name for a routing policy, not a fixed machine. When you send a turn to zyraxon-apex, the line looks at what the turn actually carries, finds an upstream model measured able to process exactly that, and sends it there. You address a brand; the brand addresses a model. This is why every model can truthfully advertise input_modalities: ["text","image","audio","video","pdf"] — the media is always handled, whichever name you used.
What happens to one request
- ▸1. Your media is resolved. Any part you sent as an
http(s)URL is fetched and inlined (see Sending Images, Audio, Video and PDFs). After this step the turn is fully inline and looks the same no matter how you sent it. - ▸2. The turn's requirement is read. The line collects which modalities the turn actually carries:
textalone, ortext + image,text + audio,text + video, and so on. This set is the only thing that decides the routing. - ▸3. A capable upstream is chosen. Candidates are filtered to those measured able to take every modality in the set — measurement, not declaration, because the pool's self-descriptions are known to be wrong in both directions.
- ▸4. Speed breaks the tie. Among the capable models, the fastest measured one leads. If it fails, the chain walks to the next capable model.
- ▸5. A refusal is caught, not served. A model that returns 200 while ignoring the media is detected and the turn is re-asked on the next capable model, instead of handing you an answer that pretends to have read the file.
Which model leads, by what the turn carries
| Your turn carries | The line routes it to | Why |
|---|---|---|
| Text only | A text model when one is available and equally able | Text models are the fastest and cheapest, and using an omni model for plain text spends the one upstream a media turn may need. If no text model is live, a media-capable model answers — you get a correct reply either way. |
| Text + image | A model measured able to see images | The image is only processed if the model receives it. An image turn is never routed to a text-only model. |
| Text + audio | A model measured able to take audio | Audio capability is the least reliably declared, so it is only trusted after measurement. |
| Text + video | A model measured able to take video | Video is the rarest capability; the chain prefers a model that handles both text and video. |
| Image only (no text) | A model measured able to see — never a text-only model | With nothing to read as text, the media *is* the request. |
| Video only (no text) | A model measured able to take video | Same rule, for the rarest modality. |
| Anything + PDF | A model that can take the document, plus whatever else the turn carries | A PDF is treated as a document, not as text. |
When the pool changes under you
The upstream pool is added to and retired without notice. The line re-reads it on a short interval and re-binds every brand to a live model, so a retired upstream degrades to a capable sibling rather than a dead end. You keep calling the same ZYRAXON name and it keeps working. A brand whose preferred upstream is temporarily absent reports status: "rotated" in the models list; it still answers.
GET /api/public/zyraxon/v1/models publishes input_modalities (what the brand accepts — always all five) alongside routed_modalities (what the upstream currently bound to that brand was measured to accept). The second field is the live, operational view, and it is safe to log for debugging. Do not branch your client on it: the routing already did that work.