Myra
Description
Myra is the platform's own model fleet, hosted by Myra Security in the EU. The gateway reaches it over an OpenAI-compatible wire format, but unlike the third-party providers it uses an internal service token rather than a BYOK key, so no per-gateway provider key is needed. Myra models run inside the EU, which makes them the models a residency-restricted (Local) gateway can serve.
The Myra provider is platform-managed: it is always available on the gateway without provider configuration, and it does not appear in the provider-key list.
PII masking is skipped on a wholly-Myra leg. When a request routes entirely to Myra models — the resolved model and every failover fallback are Myra-hosted — the PII-masking guardrails (PII Protector, Custom PII, NLP-detector scrub) are not applied, on the request or the response, even on a PII gateway. The data never leaves Myra, so masking would only corrupt the user's own text. Content-safety blocks, tool egress (web search / URL fetch / MCP) masking, and agent-invoke output are still enforced; if any leg in the egress set is an external provider, masking applies as normal (fail-closed). See PII Protector — Local model legs are not masked.
| Feature | Limitation |
|---|---|
| Chat completions | — |
| Streaming responses (SSE) | — |
| Tool use | Supported. |
| Vision input | Supported on the Myra models that accept images. |
| Web search | Supported. The gateway runs the search through its EU web-search provider and feeds the results back to the model. |
| EU data residency | Requests stay in the EU. Myra models are the models a Local (residency-restricted) gateway can serve. |
💡 Note: Myra uses an internal service token, not a BYOK key. There is no key to add for the
myraprovider, and it is not part of the Provider keys (BYOK) list.
Available models
The models on offer follow the gateway's model catalogue for the selected gateway. Because the Myra fleet is EU-hosted and keyless, its models are routable without any stored key (unless a tenant admin has disabled one on the gateway — see below). For the models a specific gateway can serve, open the model picker in Chat or the Provider Costs view (Settings › Costs).
Disabling a Myra model on a gateway
Myra-hosted models are enabled by default on every gateway. A tenant admin can disable one per
gateway under Settings › Gateways › Add Model › Use Platform Key › Myra models — a
disabled model disappears from every model picker and is hard-blocked on that gateway (an
explicit API request for it returns 403 model_disabled_on_gateway; automatic fallbacks and
upgrades never select it). The model stays listed in the dialog, toggled off, so re-enabling it
is the same single click. Gateways of the same workspace are independent: a model disabled on
one gateway still serves on a sibling that has not disabled it.
The current default on-prem model is qwen3.8-27b — a dense, multimodal (vision-capable) Qwen model with a 262K context. It is what Auto selects for local chat and what handles image understanding on the Myra fleet. Its predecessor ids qwen3.6-27b and qwen3.6-35b-a3b (and the Gemma MoE gemma-4-26b-a4b-it, succeeded by gemma-4-31b-it) are no longer listed, but a request or a stored pin that still names one is upgraded to the successor rather than refused: the response carries X-AIG-Model-Upgraded-From (and, where the catalogue still holds the old row, an RFC 9745 Deprecation header), the request log records the served model, and a model you have disabled on the gateway stays disabled under its old name too. The exact rules — what is rewritten, what still returns 400/403 — are in Inference › Retired model ids.
Adaptive thinking on the fleet's Mistral model. The Chat sends its explicit thinking flag (chat_template_kwargs: {"enable_thinking": true|false}, the vLLM/Qwen form) to every non-Anthropic model. mistral-small-4 is served with a Mistral tokenizer that rejects any request carrying chat_template_kwargs (or chat_template), so the gateway never forwards either field to a Myra-served Mistral model — the request goes out without a thinking knob and the model answers with its serving default. Consequently the Chat's thinking toggle has no effect on mistral-small-4 (both positions are dropped). A reasoning_effort you set yourself on the API is passed through, but the fleet's proxy currently rejects that parameter for this model — the request then goes through the unsupported-parameter strip-and-resend. Qwen and Gemma models receive chat_template_kwargs unchanged.
Managed (keyless) Claude
Beyond the on-prem fleet, a tenant can enable a small allowlist of Myra-managed external Claude
models — currently claude-sonnet-5 and claude-haiku-4-5 — without providing an Anthropic
API key. These run on Myra's managed Anthropic pool key and are metered to the
tenant's budget, so a workspace can use current Claude models without its own BYOK setup. The
allowlist is server-side (a tenant cannot grant an arbitrary external model this way); enabling a
managed model is a tenant-admin configuration action (Settings › Gateways › Add Model › Use
Platform Key). Once a model is enabled and the workspace has a budget, it appears in every
model picker — Chat, agents, playground, and the project/preferences default-model field — even on
a gateway with no stored provider keys, and only the exact enabled models are offered (enabling
Sonnet does not surface other Claude models). Without a workspace budget the model stays listed in
the Add-Model dialog (with a set-a-budget hint) but is neither offered nor routable. See
BYOK — managed keyless models.
Subscription workspaces need no such step. A workspace on a paid self-serve plan already runs its Claude models on Myra's managed pool key, so the models its plan includes are available in every picker from the moment the workspace is created — on its first gateway and on any gateway it adds later — with nothing to enable and no key to store. "Use Platform Key" is for manually provisioned workspaces. Which Claude models a plan includes is part of the plan itself; a model outside the plan is not offered, and would be refused if requested directly.
Those plan-included models are listed but read-only in gateway management: they appear in the gateway's Platform models table with the source Included in your plan, and in the Add Model dialog under a read-only Included in your plan group with no enable/disable control. There is nothing to grant and nothing to revoke — the subscription decides them. A model the workspace has additionally been granted by an administrator keeps its own toggle and is listed as a managed grant instead.