# Managed providers (/execution/managed-providers)



The managed-provider profile is what every project runs on until it has a measured reason to do
otherwise. Requests resolve to a model and execute against Zumik's contracted accounts across the
five first-class providers, reached through the [Bifrost gateway](/infrastructure/bifrost). You write
no provider keys, you manage no infrastructure, and you still get every provider-native discount.

This is the path the `Agent-Execution-Profile: managed_provider` header reports.

## The default path [#the-default-path]

```text
Client
  ↓
Bifrost gateway (Tier 1)        auth, quotas, global rate limits, failover, 23+ providers
  ↓
Product API Core                alias resolution, project policy, the Execution Broker
  ↓
Managed provider adapter
  ↓
Company-managed provider account
```

The Core resolves the model through its immutable [alias release](/concepts/model-aliases), the
[Execution Broker](/concepts/execution-profiles) selects this profile when there is no subscription
or BYOK credential, and Bifrost holds the contracted keys and normalizes the provider behind an
OpenAI-style surface. In development, with no gateway configured, the Core returns a deterministic
placeholder instead of calling a provider, and the `Agent-Execution-Mode` header reads `placeholder`.

<Note>
  Bifrost is an upstream, not a hard requirement. With `BIFROST_BASE_URL` set, managed requests route
  through the gateway; otherwise the Core calls provider adapters directly. Either way the
  managed-provider profile means Zumik's accounts pay the provider, and the customer pays Zumik.
</Note>

## What you get for free [#what-you-get-for-free]

The managed profile turns on the provider-native economics without any client instrumentation. Each
provider does this differently; the [capability manifest](/concepts/capability-manifests) records the
exact facts the broker routes on.

| Provider                          | Prompt cache                           | Batch API         | Service tiers          |
| --------------------------------- | -------------------------------------- | ----------------- | ---------------------- |
| [OpenAI](/providers/openai)       | Automatic, 50% read discount           | Yes, 50% off, 24h | flex / default / scale |
| [Anthropic](/providers/anthropic) | Explicit, 90% read discount            | Yes, 50% off, 24h | standard               |
| [xAI](/providers/xai)             | Cached context, 75% read discount      | No                | standard               |
| [Gemini](/providers/gemini)       | Implicit + explicit, 75% read discount | Yes, 50% off, 24h | standard               |
| [Fireworks](/providers/fireworks) | None                                   | Async batch       | serverless / dedicated |

### Caching [#caching]

The platform's bias is to capture provider-native caching before it considers anything heavier.
Stable content at the front of the request, volatile content at the tail, and the discount lands on
whichever provider answers. The per-provider mechanics are recorded in the
[capability manifest](/concepts/capability-manifests); Zumik reports realized reuse with an evidence
level so a predicted discount is never reported as a measured one.

### Batch and service tiers [#batch-and-service-tiers]

Non-interactive work (background evaluations, diagnostic reprocessing, pre-computable tool calls,
replay experiments) routes to a provider Batch API where one exists, for a 50% cost reduction at 24h
turnaround. Interactive and QoS `interactive` requests never go to Batch. OpenAI's flex / default /
scale tiers and Fireworks' serverless / dedicated tiers are matched to the request's QoS class so a
latency-cost tradeoff is made deliberately, not by accident.

## When the managed path is the right answer [#when-the-managed-path-is-the-right-answer]

<CardGroup cols="2">
  <Card title="You want to start" icon="rocket">
    Fastest onboarding and the lowest operational burden. One base-URL change on `/v1` and you are
    live against contracted accounts.
  </Card>

  <Card title="You need breadth" icon="layer-group">
    Broad model coverage across the five first-class providers plus the rest of Bifrost's 23+
    backends, with automatic multi-provider failover.
  </Card>

  <Card title="Caching does the work" icon="piggy-bank">
    For most workloads provider-native caching captures the available reuse, which is exactly the
    condition under which BYOC loses on cost.
  </Card>

  <Card title="You have no procurement constraint" icon="file-signature">
    No existing provider agreement to honor and no account-level retention requirement that forces
    your own key.
  </Card>
</CardGroup>

When one of those conditions changes - you hold a provider agreement, you need account-level
retention, or a few model paths concentrate hard enough to clear the replay bar - the next step is
[BYOK](/execution/byok) or, with proof, [BYOC](/execution/byoc).