# Execution profiles (/concepts/execution-profiles)



An **execution profile** decides where a request actually runs. Zumik is provider-first: the default profile uses Zumik's contracted managed providers, and the other profiles are escalations you add only when evidence justifies them. Every profile runs over the same internal execution system, so your [handles](/concepts/handles-and-fingerprints), [aliases](/concepts/model-aliases), and [state objects](/concepts/sessions) are identical regardless of which profile serves a given request.

## The profiles [#the-profiles]

<CardGroup cols="2">
  <Card title="Managed provider (default)" icon="cloud">
    Zumik's own provider accounts. Fastest onboarding, broad model coverage, provider-native caching, automatic failover.
  </Card>

  <Card title="BYOK" icon="key">
    Your provider credentials. You keep the billing relationship and your account-level retention rules; Zumik still drives routing, state, and telemetry.
  </Card>

  <Card title="BYOC" icon="server">
    Your cloud, your runtime. For dedicated SLOs, private networking, stronger purge evidence, and runtime-confirmed reuse - activated only when [replay](/guides/replay) proves it pays off.
  </Card>

  <Card title="Hybrid" icon="shuffle">
    Managed providers for breadth and overflow, BYOC hot lanes for concentrated, reusable workloads. The common shape for a maturing coding-agent platform.
  </Card>
</CardGroup>

## Managed provider: the default [#managed-provider-the-default]

This is where everyone starts.

```
Client → Tier 1 gateway → Product API Core → Execution Broker
       → Managed provider adapters → Company-managed provider accounts
```

It gives you broad coverage, provider-native prompt caching (OpenAI automatic, Anthropic explicit cache-control, Gemini implicit, xAI context caching), provider Batch API lanes for cost reduction, multi-provider policy, and automatic failover - with no infrastructure to operate.

## BYOK: your keys [#byok-your-keys]

```
Client → Product API Core → Execution Broker → Provider adapter → Your provider credential
```

BYOK is for customers with existing provider agreements, their own rate limits and quota reservations, procurement constraints, or account-level retention policies they need to keep. Provider-native cost and speed optimizations stay active under your key. The [subscription credential](/guides/subscriptions) flow (Claude Code, ChatGPT Codex) is part of this family.

## BYOC: your cloud [#byoc-your-cloud]

```
Global product control plane → Customer-cloud data plane
  → One selected inference scheduler → Self-hosted runtime lane → KV hierarchy
```

BYOC is the heaviest profile and the last resort, not the first. It is justified by dedicated latency SLOs, sustained hot-model volume, private networking, regional isolation, custom models, explicit KV-cache orchestration, or stronger purge evidence - and only where replay data shows a material benefit over the managed bill at the same reliability.

<Warning>
  A high [Workload Reuse Score](/concepts/workload-reuse-score) does not justify BYOC on its own. The most common result of replay analysis is that provider-native caching already captures the reuse, and BYOC has no business case. Length alone never recommends self-hosting.
</Warning>

## OpenRouter: emergency fallback only [#openrouter-emergency-fallback-only]

OpenRouter is a last-resort continuity layer, used only when a primary provider has a verified total outage for a required model path.

<Note>
  OpenRouter is never used for routine routing or price arbitration. It is gated behind explicit policy checks for retention, region, procurement, and customer allowlists, disabled entirely for customers whose data-boundary or compliance requirements are incompatible with brokered execution, and every use is recorded with the failed upstream path and the policy that allowed the exception. A clear degraded response or rejection is always preferred over silently violating policy.
</Note>

## Control-plane ownership [#control-plane-ownership]

Each profile assigns one owner per responsibility, so nothing is double-owned.

| Responsibility               | Managed                        | BYOK                             | BYOC                          |
| ---------------------------- | ------------------------------ | -------------------------------- | ----------------------------- |
| Auth, quotas, project policy | Product API Core               | Product API Core                 | Product API Core              |
| Provider / profile selection | Execution Broker               | Execution Broker                 | Execution Broker              |
| Provider credential          | Company                        | Customer                         | n/a                           |
| Model selection              | Alias Resolver                 | Alias Resolver                   | Alias Resolver                |
| Cache routing                | Provider                       | Provider                         | Selected scheduler + runtime  |
| Session state                | State Service                  | State Service                    | State Service                 |
| Billing                      | Platform                       | Customer-provider + platform fee | Platform fee + customer infra |
| Purge guarantees             | Bounded by provider capability | Bounded by provider capability   | BYOC operator + State Service |

<Warning>
  Inside one BYOC profile, exactly one component owns replica selection. The platform does not run competing replica schedulers in the same path. You pick the scheduler-owned profile up front; you do not stack two.
</Warning>

<CardGroup cols="2">
  <Card title="Capability manifests" icon="clipboard-list" href="/concepts/capability-manifests">
    What each profile's targets can actually do.
  </Card>

  <Card title="BYOK setup" icon="key" href="/guides/byok-setup">
    Attach your own provider credentials.
  </Card>
</CardGroup>