Model Adapters and Routing
Model Adapters and Routing
Fact-check status
Key jargon
| Term | Plain-language meaning |
|---|---|
| Model adapter | Code translating a common application request into one provider's API format. S1 |
| Router | Logic that selects a model or provider for a request. S1 |
| Fallback | A planned alternative used when the preferred route is unavailable or unsuitable. S1 |
| Capability matrix | A dated record of supported modalities, tools, limits, privacy, latency, and cost. S1 |
Key concepts
- Adapters normalize interfaces, not model semantics. S1
- Routing should use measured task performance and policy constraints, then record why a route was chosen. S1
Concept map
flowchart LR
A["Classify request needs"] --> B["Apply policy and capability matrix"]
B --> C["Call selected adapter"]
C --> D["Measure and revise routing"]Diagram semantics verified against S1 and S2 on 2026-09-02.
A model adapter normalizes messages, multimodal inputs, structured outputs, tool calls, streaming, errors, usage, and model identity. It should not hide meaningful capability differences. S1
Routing inputs
- Task class and required modalities. S1
- Quality tier demonstrated by evals. S1
- Context length and output size. S1
- Latency/service-level objective. S1
- Data location and provider policy. S1
- Cost ceiling and current budget. S1
- Tool/structured-output support. S1
- Availability and fallback safety. S1
Dangerous fallback
A cheaper or available fallback may lack the privacy, context, tool, or reasoning properties assumed by the workflow. Fallback is a policy decision, not merely an exception handler. S1
Exercise
Define one normalized request/response schema and a route table for extraction, drafting, research, and high-risk approval. Include a “no eligible model” outcome.