# Hybrid profile (/execution/hybrid)



Hybrid is not a third data plane. It is managed providers and BYOC running side by side, with the
[Execution Broker](/concepts/execution-profiles) sending each request to whichever fits. A small
number of hot model paths go to dedicated [BYOC](/execution/byoc) clusters; everything else - the long
tail of models, burst overflow, anything that does not clear the replay bar - stays on the
[managed-provider](/execution/managed-providers) path.

This is the shape most real platforms converge on, because real traffic is concentrated: a few model
paths carry most of the volume, and the rest is a wide, thin tail that would never pay back a GPU.

## Why the split works [#why-the-split-works]

```text
                      ┌─────────────────────────────┐
   concentrated  ───▶ │ BYOC hot lane (your GPUs)    │  Dynamo + SGLang + FlashInfer + LMCache
   hot paths          └─────────────────────────────┘
Broker ─┤
                      ┌─────────────────────────────┐
   everything    ───▶ │ Managed providers (Bifrost) │  broad coverage, failover, native caching
   else + overflow    └─────────────────────────────┘
```

The hot lane earns dedicated infrastructure because its volume sustains the utilization a BYOC cluster
needs to break even. The managed path absorbs everything that does not: it carries the breadth, it
catches overflow when the hot lane is at capacity, and it serves the tail at no fixed cost. Each
request still reports the profile that served it on `Agent-Execution-Profile`.

## Who it fits [#who-it-fits]

<CardGroup cols="2">
  <Card title="Coding-agent platforms" icon="code">
    A handful of dominant model paths (one or two coding models running constantly) plus a long tail
    of occasional models. The dominant paths justify a hot lane; the tail does not.
  </Card>

  <Card title="Enterprise tenants" icon="building-lock">
    Strict isolation for the concentrated workload on dedicated clusters, with managed providers
    covering the rest without standing up infrastructure for every model.
  </Card>

  <Card title="Predictable high volume" icon="chart-line">
    Sustained, forecastable traffic on known paths is exactly the condition under which a BYOC lane
    breaks even, while bursts spill to managed overflow.
  </Card>

  <Card title="Gradual migration" icon="arrows-turn-right">
    Move one proven hot path to BYOC at a time, leaving the rest managed, instead of an all-or-nothing
    cutover.
  </Card>
</CardGroup>

## Activation is still per-lane and replay-gated [#activation-is-still-per-lane-and-replay-gated]

A hybrid deployment does not relax the BYOC bar; it applies it one lane at a time. Each candidate hot
path goes through the same gate: a [workload diagnostic](/guides/workload-diagnostics) that flags it as
worth evaluating, then a [replay run](/guides/replay) proving the blended total cost beats the managed
path at equal reliability. A path that fails the gate simply stays managed.

<Note>
  The managed-provider fallback is not optional in a hybrid setup - it is the safety net. When a BYOC
  hot lane is at capacity or unavailable, the broker routes that traffic back to the managed path
  rather than dropping it. The [overview](/execution/overview) covers the full escalation order.
</Note>

## Putting it together [#putting-it-together]

Stand up the managed path first (it is the default and needs nothing), prove a hot path with replay,
deploy it from the [BYOC stack](/infrastructure/byoc-stack) or
[portable Kubernetes](/infrastructure/portable-kubernetes) chart, and register the cluster through the
[BYOC clusters API](/api-v2/byoc-clusters). The control-plane ownership split is the same as
for a pure-BYOC deployment - see [BYOC](/execution/byoc) for the table.