Model Adapters and Routing

Key jargon

Term	Plain-language meaning
Model adapter	Code translating a common application request into one provider's API format.
Router	Logic that selects a model or provider for a request.
Fallback	A planned alternative used when the preferred route is unavailable or unsuitable.
Capability matrix	A dated record of supported modalities, tools, limits, privacy, latency, and cost.

Key concepts

Adapters normalize interfaces, not model semantics.
Routing should use measured task performance and policy constraints, then record why a route was chosen.

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"]

A model adapter normalizes messages, multimodal inputs, structured outputs, tool calls, streaming, errors, usage, and model identity. It should not hide meaningful capability differences.

Routing inputs

Task class and required modalities.
Quality tier demonstrated by evals.
Context length and output size.
Latency/service-level objective.
Data location and provider policy.
Cost ceiling and current budget.
Tool/structured-output support.
Availability and fallback safety.

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.

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.

Checklist

Pin or record exact model versions when possible.
Run regression evals before route changes.
Expose actual provider/model in traces.
Never silently weaken data or action policy.