Compatibility layer
Your application always speaks one OpenAI-compatible shape. AIx normalizes each request, selects an eligible route and returns a consistent response so infrastructure details never leak into your product code.
One stable contract
| Capability | AIx behavior |
|---|---|
| Plain chat | Standard messages request and chat.completion response |
| Streaming | Valid OpenAI SSE chunks terminated by [DONE] |
| Tool calling | Preserves tools, tool_choice and tool_calls |
| Structured output | Routes only through paths that support response_format |
| Vision | Preserves multimodal content arrays on eligible models |
| Usage | Normalized token counts for settlement and observability |
Capability-aware execution
AIx checks both the selected model and request features before execution. A plain chat request can use any healthy path for that model; an advanced request is automatically restricted to paths that support the complete payload.
▲ Heads up
A model can support plain text while a specific advanced feature is unavailable. Check the model catalog and use a model marked for the capability your workload needs.
Practical guidance
- Use canonical model ids from the live catalog instead of hardcoding availability.
- Keep standard OpenAI client types; AIx handles normalization internally.
- For tools, JSON mode or vision, choose a model explicitly marked for that feature.
- Treat unknown additive response fields as optional to keep clients forward-compatible.