> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mnemom.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Cross-Dialect Egress

> Call the gateway with an Anthropic Messages request and route it to OpenAI — the gateway translates dialects in both directions, using your own OpenAI key for the upstream leg

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](https://docs.anthropic.com/en/api/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.

<Note>
  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.
</Note>

## How it differs from the provider doors

The [provider doors](/quickstart/gateway) (`/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`. |

<Warning>
  `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.
</Warning>

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](/guides/api-keys#creating-a-key) for personal and organization key creation.

<Note>
  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.
</Note>

## 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](https://platform.openai.com/docs/api-reference/responses), which lets a single request carry both function tools and a reasoning-depth setting — see [Reasoning effort](#reasoning-effort).

The `model` field must name a supported OpenAI model (see [Supported models](#supported-models)):

```json theme={null}
{
  "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`
* `gpt-6-astra`
* `gpt-6.1-sol`

## Reasoning effort

Every supported OpenAI model on the `/router` surface is a **reasoning-profile** model, egressed through OpenAI's [Responses API](https://platform.openai.com/docs/api-reference/responses) (`/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`:

```json theme={null}
{
  "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`). |

<Note>
  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.
</Note>

<CodeGroup>
  ```bash effort:high theme={null}
  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."}
      ]
    }'
  ```
</CodeGroup>

## Example

<CodeGroup>
  ```bash Non-streaming theme={null}
  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."}
      ]
    }'
  ```

  ```bash Streaming theme={null}
  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."}
      ]
    }'
  ```
</CodeGroup>

## 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.

```json theme={null}
{
  "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:

```json theme={null}
{
  "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`:

1. Mint a separate Mnemom key with only the `gateway` capability and store it in each caller's secret manager.
2. 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`.
3. 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.
4. Verify non-streaming and streaming requests, plus the expected negative cases (`401` with no Mnemom key and `403` with an authenticated key lacking `gateway`).
5. Remove obsolete caller configuration only after production traffic is healthy. Never copy a provider key into the Mnemom-key slot as a fallback.

## Related

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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.