Cross-Dialect Egress

The gateway’s /router surface lets you keep writing requests in one provider’s dialect while the gateway egresses to a different provider. You send an Anthropic Messages-shaped request to /router/anthropic and select OpenAI as the egress target. The gateway translates the request into OpenAI’s format on the way out and translates the response back into Anthropic’s format on the way in. Your code speaks Anthropic conventions end to end; the served model is OpenAI’s. This is useful when your application is already built against the Anthropic Messages API — SDKs, prompt templates, response parsing — and you want to serve an OpenAI model without rewriting the integration to OpenAI’s request/response shape.

Today the only covered cross-dialect pair is Anthropic → OpenAI: an Anthropic-shaped request routed to OpenAI. Other combinations are not substituted — the router fails closed rather than guessing at a translation it does not support.

How it differs from the provider doors

The provider doors (/anthropic, /openai, /gemini) are passthrough: you speak each provider’s native dialect at its own path, and the gateway forwards to that same provider. The /router surface adds dialect translation — you speak Anthropic, the gateway speaks OpenAI upstream — and separates authorization from provider egress: a scoped Mnemom API key authorizes use of the router, while your OpenAI key authenticates only the upstream leg.

Endpoint

POST https://gateway.mnemom.ai/router/anthropic/v1/messages

Headers

Header	Required	Value
`x-mnemom-api-key`	Yes	A Mnemom API key (`mnm_*`) with the `gateway` capability. It authorizes this request at Mnemom and is stripped before egress.
`Content-Type`	Yes	`application/json`
`x-mnemom-provider`	Yes	Routing directive selecting the egress provider. To egress to OpenAI: `{"only":["openai"]}`.
`x-mnemom-egress-key`	Yes	Your OpenAI API key, used only for the upstream leg. The gateway injects it as `Authorization: Bearer <key>` to OpenAI. It is never logged.
`x-api-key`	Yes	Anthropic’s native dialect field. The `/router/anthropic` door speaks the Anthropic Messages API, which requires this header to be present — but it does not authorize the router. Send a non-authorizing placeholder (e.g. `ph-not-real`); never put key material here. Authorization is carried solely by `x-mnemom-api-key`.

x-mnemom-api-key and x-mnemom-egress-key are two different credentials with two different jobs. The Mnemom key authorizes use of /router and never leaves the gateway. The egress key is your BYOK provider credential and is used only to call OpenAI upstream. Do not swap them, and do not send either in the request body.

A provider-dialect credential — each door’s native provider auth field, such as Anthropic’s x-api-key on the /router/anthropic door — does not authorize /router. Router authorization is carried solely by x-mnemom-api-key; browser sessions and other bearer credentials are not router credentials. That does not make the field optional: because /router/anthropic speaks the Anthropic Messages dialect, x-api-key must still be present on every request as a dialect field — send a non-authorizing placeholder (e.g. ph-not-real), never key material. The router rejects a request that omits it with 401 even when the Mnemom key is valid.

Least-privilege router key

Create or select a real Mnemom API key carrying the gateway capability. For a router-only integration, mint a gateway-only key rather than reusing a key with api:read, api:write, or admin capabilities. The full secret is shown once; store it in your secrets manager and inject it through an environment variable such as MNEMOM_API_KEY. See API Keys for personal and organization key creation.

A placeholder, provider key, or arbitrary string is not a Mnemom API key. Do not test a production cutover with a dummy value: provision a real scoped key, place it in the caller’s secret store, and verify a request before removing the old route.

Request body

Send a standard Anthropic Messages body. Use Anthropic conventions throughout — model, max_tokens, messages, system, and so on. The gateway maps them to OpenAI’s equivalents automatically (for example, max_tokens becomes OpenAI’s max_output_tokens). Supported OpenAI models are served through OpenAI’s Responses API, which lets a single request carry both function tools and a reasoning-depth setting — see Reasoning effort. The model field must name a supported OpenAI model (see Supported models):

{
  "model": "gpt-5.6-sol",
  "max_tokens": 256,
  "messages": [
    { "role": "user", "content": "Explain retrieval-augmented generation in two sentences." }
  ]
}

Supported models

The model in a cross-dialect request must be one of the supported OpenAI model IDs:

gpt-5
gpt-5-codex
o3
o3-mini
gpt-5.6-sol
gpt-5.6-terra
gpt-5.6-luna

Reasoning effort

Every supported OpenAI model on the /router surface is a reasoning-profile model, egressed through OpenAI’s Responses API (/v1/responses). That endpoint accepts function tools and a reasoning-effort setting in the same request, so you can dial reasoning depth even on tool-calling turns. Set the depth with an output_config.effort field on the request body. The gateway forwards it unchanged to the served model’s reasoning.effort:

{
  "model": "gpt-5.6-sol",
  "max_tokens": 1024,
  "output_config": { "effort": "high" },
  "messages": [
    { "role": "user", "content": "Prove there are infinitely many primes." }
  ]
}

`output_config.effort`	Behavior
`low` · `medium` · `high` · `xhigh` · `max`	Forwarded identity to OpenAI’s `reasoning.effort` — no bucketing, no clamp. Higher effort spends more reasoning tokens before the model answers.
omitted	The gateway sends no `reasoning` field; the model applies its own server-side default (`medium`).

Effort is independent of the model — pair any level with any model (a cheap model at max, the flagship at low). The gpt-5.6-* family accepts the full low–max range. Because the gateway passes the level straight through with no clamp, a level a given upstream model does not recognize surfaces as an upstream error rather than being silently downgraded.

curl https://gateway.mnemom.ai/router/anthropic/v1/messages \
  -H "x-mnemom-api-key: $MNEMOM_API_KEY" \
  -H "Content-Type: application/json" \
  -H 'x-mnemom-provider: {"only":["openai"]}' \
  -H "x-mnemom-egress-key: $OPENAI_API_KEY" \
  -H "x-api-key: ph-not-real" \
  -d '{
    "model": "gpt-5.6-sol",
    "max_tokens": 1024,
    "output_config": { "effort": "high" },
    "messages": [
      {"role": "user", "content": "Prove there are infinitely many primes."}
    ]
  }'

Example

curl https://gateway.mnemom.ai/router/anthropic/v1/messages \
  -H "x-mnemom-api-key: $MNEMOM_API_KEY" \
  -H "Content-Type: application/json" \
  -H 'x-mnemom-provider: {"only":["openai"]}' \
  -H "x-mnemom-egress-key: $OPENAI_API_KEY" \
  -H "x-api-key: ph-not-real" \
  -d '{
    "model": "gpt-5.6-sol",
    "max_tokens": 256,
    "messages": [
      {"role": "user", "content": "Explain retrieval-augmented generation in two sentences."}
    ]
  }'

curl -N https://gateway.mnemom.ai/router/anthropic/v1/messages \
  -H "x-mnemom-api-key: $MNEMOM_API_KEY" \
  -H "Content-Type: application/json" \
  -H 'x-mnemom-provider: {"only":["openai"]}' \
  -H "x-mnemom-egress-key: $OPENAI_API_KEY" \
  -H "x-api-key: ph-not-real" \
  -d '{
    "model": "gpt-5.6-sol",
    "max_tokens": 256,
    "stream": true,
    "messages": [
      {"role": "user", "content": "Explain retrieval-augmented generation in two sentences."}
    ]
  }'

Response

The gateway returns a standard Anthropic Messages response, even though an OpenAI model served it. You parse the same content blocks, stop_reason, and usage fields you already parse for the /anthropic door. The model field echoes the OpenAI model that served the request.

{
  "id": "msg_...",
  "type": "message",
  "role": "assistant",
  "model": "gpt-5.6-sol",
  "content": [
    { "type": "text", "text": "Retrieval-augmented generation ..." }
  ],
  "stop_reason": "end_turn",
  "usage": { "input_tokens": 18, "output_tokens": 42 }
}

Streaming

Add "stream": true to the body and the gateway streams the response back as Anthropic Server-Sent Events — not raw OpenAI chunks. You receive the same event sequence the /anthropic door emits:

message_start
content_block_start
content_block_delta
content_block_stop
message_delta
message_stop

Client code written to consume Anthropic streaming events works unchanged. The gateway translates OpenAI’s streaming chunks into this Anthropic event shape for you.

Errors

Errors surface in the Anthropic error envelope — the same shape the /anthropic door returns — so your existing error handling applies:

{
  "type": "error",
  "error": {
    "type": "...",
    "message": "..."
  }
}

Condition	Status	Detail
Missing, malformed, unknown, expired, or revoked `x-mnemom-api-key`	`401`	The request is not authenticated. Supplying a provider-dialect key instead does not satisfy router authentication.
Valid Mnemom API key without the `gateway` capability	`403`	The caller is authenticated but not authorized for gateway traffic. Mint a least-privilege replacement with `gateway`; do not add admin capabilities.
Router authentication service unavailable	`503`	Authorization could not be established. The router fails closed; honor `Retry-After` when present and retry rather than bypassing authentication.
Routing directive set but `x-mnemom-egress-key` missing	`400`	Error code `cross-dialect-egress-credential-required`. A cross-dialect egress needs your OpenAI key on the request.
Upstream provider error	Upstream status preserved	The gateway wraps the upstream error in the Anthropic error envelope above and preserves the upstream HTTP status.

Coordinated cutover

Coordinate the authentication change with the router deployment and every caller that uses /router:

Mint a separate Mnemom key with only the gateway capability and store it in each caller’s secret manager.
Update callers to send that value as x-mnemom-api-key while continuing to send the provider BYOK value separately as x-mnemom-egress-key.
Deploy the router auth enforcement and caller configuration in one agreed window. A caller using only x-api-key will receive 401 after enforcement is live.
Verify non-streaming and streaming requests, plus the expected negative cases (401 with no Mnemom key and 403 with an authenticated key lacking gateway).
Remove obsolete caller configuration only after production traffic is healthy. Never copy a provider key into the Mnemom-key slot as a fallback.

Gateway Quickstart — the passthrough provider doors (/anthropic, /openai, /gemini)
Provider Support — per-provider feature coverage across Anthropic, OpenAI, and Gemini
Headers reference — the full set of gateway response headers

Overview

Identity & Cards

Posture & Policy

Detection & Safe House

AEGIS

Reputation & Risk

Lifecycle

Gateway

Pricing

Migrations

Policy

Specifications

Changelog

How it differs from the provider doors

Endpoint

Headers

Least-privilege router key

Request body

Supported models

Reasoning effort

Example

Response

Streaming

Errors

Coordinated cutover

​How it differs from the provider doors

​Endpoint

​Headers

​Least-privilege router key

​Request body

​Supported models

​Reasoning effort

​Example

​Response

​Streaming

​Errors

​Coordinated cutover

​Related

How it differs from the provider doors

Endpoint

Headers

Least-privilege router key

Request body

Supported models

Reasoning effort

Example

Response

Streaming

Errors

Coordinated cutover

Related