Settings

Model routing and data flow

Every model call you make travels a path: out of Runtype, through zero or more gateways, and into the company that actually runs the model. This page explains how that path is chosen, what changes when you bring your own key, and which third parties can see your prompts based on the choices you make.

How a model name becomes a provider

Runtype accepts model names in two shapes, and the shape decides who picks the provider.

Model nameExampleWho picks the provider
Routed nameclaude-sonnet-4-5Runtype, using its routing configuration for that model family
Provider-pinned nameanthropic:claude-sonnet-4-5You. The call goes to that provider and nowhere else

The model picker in the dashboard uses routed names. They keep working as providers add and retire model versions, which is why flow and agent templates use them.

For most popular families (Claude, Gemini, GPT, Grok), the routed name resolves to the Vercel AI Gateway, with the model’s first-party provider as the fallback when the gateway is not available to your account. A few models route through the Cloudflare AI Gateway or run on Cloudflare Workers AI instead. The gateway is a routing and metering layer in front of the provider: it sees the request, and the provider still does the inference.

To take the choice out of Runtype’s hands, use the provider-pinned form. Set it on a prompt step or an agent when you define the model through the API, the SDK, the MCP server, or a flow definition you author as code.

Which key pays for the call

Every model in your catalog is attached either to one of your provider keys or to the Runtype platform key, which you choose in Settings → Models. From those choices Runtype resolves a credential per provider, preferring a key you configured and falling back to the platform key for that provider when you have not configured your own and your plan allows platform-key spend.

The important part is that resolution is per provider, not per model. All of a provider’s calls run on the one credential that resolves for it. So when a provider has several enabled models and they do not agree (some attached to your key, some to the platform key), the setting on an individual model is not a guarantee: a model can end up running on the other credential.

Keep every enabled model for a provider on the same choice when key custody or billing matters to you. To confirm the result rather than infer it, open Settings → Models → Providers: each provider states whether its calls run on your key or on the Runtype plan key.

Platform keys exist for Anthropic, OpenAI, Google, xAI, Mixlayer, and Cloudflare Workers AI, plus the Vercel and Cloudflare AI gateways. Every other provider (Amazon Bedrock, Vertex AI, Together.ai, Tinfoil, and any OpenAI-compatible endpoint) is BYOK only, so those models never run on a Runtype credential.

Provider selection and key selection are two separate decisions. A routed name can resolve to the Vercel AI Gateway even when you have your own key for the model’s first-party provider, in which case the gateway’s platform credential pays for the call. If you added a provider key specifically so that your calls run on your own account, pin the provider in the model name.

Provider failover and the uptime tradeoff

The same model is often sold by more than one company. Claude models, for example, are served by Anthropic directly, by AWS Bedrock, and by Google Vertex AI. A gateway that fails over between them keeps requests succeeding during an outage. It also means a prompt you expected to reach Anthropic can be processed by AWS or Google without you ever seeing it happen.

Runtype pins gateway traffic for Anthropic models to Anthropic’s first-party API. Silent cross-cloud failover is turned off.

Stated plainly, that is a tradeoff and not a free win:

  • What you get: the set of companies that can see a given prompt is decided entirely by your build. It does not change under load or during an incident.
  • What you give up: during an Anthropic outage, an Anthropic request fails instead of being quietly served from another cloud.

We chose a predictable data path over invisible resilience. Resilience is still available. It is just something you configure, and something you can see in the run afterwards.

Configure your own failover

Prompt steps support a fallback chain that runs in order until one entry succeeds. Each entry is a retry of the same model, a different model, or a fixed message. You choose what triggers the chain: the step erroring, the reply coming back empty, or the call running past a duration you set.

A cross-provider fallback (Claude on Anthropic first, a Google or OpenAI model second) gives you the same continuity a silent gateway failover would, with two differences that matter: it is written down in your flow, and every run that used it is marked. See Using prompt steps for how to build the chain, and Handling batch failures for the batch-scale version.

Who can see your data, based on your choices

Runtype engages a model or tool provider only when something you built selects it. There is no background pool of vendors processing your content.

What your build doesWho processes your prompt content
Runs a model on a platform keyRuntype’s own infrastructure, the gateway in the path, and the model provider you selected
Runs a model on your own provider keyThe same path, except the model provider bills you and processes the request under your agreement
Calls a built-in tool (web search, scraping, code sandbox)That tool’s provider, and only the query, URL, or code you send it
Runs the self-hosted runtime with your own keysYour model provider only. Calls go from your infrastructure straight to it, and Runtype is not in the path

Three consequences worth being explicit about:

  • A provider you never selected is never in the path. Pinning removes the one case where that could previously have happened without your knowledge.
  • BYOK moves the relationship, not just the bill. When a call runs on your key, the provider’s terms with you govern that content, not Runtype’s terms with the provider.
  • Self-hosted isolation depends on telemetry staying off. The self-hosted runtime has an opt-in telemetry reporter that is disabled by default. Leaving it off is what keeps execution content on your infrastructure: when it is enabled, lifecycle events sent to Runtype can carry step output and error messages, not just counts and timings.

Checking what actually happened

Routing is observable after the fact. Open any run from Logs and look at the execution detail:

  • Model is the model the step ran on.
  • Model resolved appears when the name you configured resolved to a different provider-specific name, and shows both.
  • Fallback appears when a fallback chain fired, along with the model that produced the answer.

For an account-wide view, go to Settings → Models and open the Providers tab. Each provider shows whether its calls run on your key or on the Runtype plan key, and links to the flows and agents that use it.

Next steps