Skip to main content
airmux uses a canonical model as the shared format between callers and providers. Each ingress dialect translates into canonical once; each provider family translates out once. With N caller dialects and M provider families, this requires N + M translators. Routing, policies, capability checks, parameter reconciliation, streaming accounting, and usage measurement operate on canonical values once.

​
Typed content

Canonical messages have system, user, or assistant roles. Their typed parts include: Nested shapes are closed and reject unknown fields. The canonical request top level is open so provider-specific parameters can travel to a compatible provider profile.

​
Public protocol paths

The endpoint path selects the caller protocol:
  • /inf/v1/chat/completions uses OpenAI Chat Completions
  • /inf/v1/responses uses OpenAI Responses
  • /inf/v1/messages uses Anthropic Messages
Headers and request-body fields cannot change the response protocol. The canonical model is an implementation boundary, not a public HTTP surface.

​
Visible translation

Translation loss is never silent. The response gateway.adjustments array names any parameter that was clamped, emulated, or dropped and explains why. A strict-parameter policy can turn a would-be drop into a denial. The selected ingress adapter also owns the response and error shape. A Messages caller receives Messages events and errors even when airmux routed the request to a different provider family.