FLUX.2 [flex] — model profile

FLUX.2 [flex] (bfl/flux-2-flex) is a image model via the unified inference gateway — one endpoint to access bfl provider backends. FLUX.2 [flex] uses non-token pricing on the unified inference gateway (image, video, or per-request units). Gateways simplify API access; o10 sits above the gateway to enforce eval-gated routing and CFO-grade spend envelopes per use case.

FLUX.2 [flex] uses non-token pricing on the unified inference gateway (image, video, or per-request units). Per-provider endpoint pricing may differ — see the provider endpoints table on this page. Cache read pricing applies when supported. o10 records fully loaded cost per call in an immutable ledger so finance sees unit economics, not blended invoices. Savings are verified against your own shadow baseline per use case — not industry averages or vendor marketing claims. o10 mirrors a week or more of production traffic, segments by workload, and compares what you actually spent versus what you would have spent on the cheapest eval-passing route at the same quality floor. Finance signs off on the delta before enforce mode flips. Gainshare pricing ties o10 fees to this verified number, so savings must be real and auditable.

FLUX.2 [flex] context limits vary by provider endpoint — check the specifications table. o10 routes by use-case eval floor, not context size alone.

FLUX.2 [flex] is available via bfl through the unified inference gateway. Multi-provider routing lets you compare latency, uptime, and per-endpoint pricing. o10 selects the cheapest compliant endpoint across all venues — gateway, OpenRouter, Bedrock committed capacity, and owned models — not just within one gateway.

o10 can route FLUX.2 [flex] via the unified inference gateway when evals clear at your quality floor. Compare against cheaper compliant tiers in shadow mode before enforcing — The 638× figure is the observed ratio between the most and least expensive compliant routing options for identical enterprise workloads at the same per-use-case quality floor across venues — not a guarantee for every team. o10 measured this across unified inference gateway, OpenRouter, Amazon Bedrock committed capacity, and owned open-weight in June 2026. Actual savings depend on your venue mix, volumes, and eval floors; shadow mode proves your organization's number against your baseline.

No. o10 does not replace your AI gateway or developer-facing APIs. It sits above gateways and clouds, adding spend enforcement, eval-gated routing, policy, and CFO-grade ledger — not proxy compatibility. Teams keep their per-token API gateway, OpenRouter, or LiteLLM for access; o10 changes which model and venue serve each request based on cost, eval floor, and governance rules. The split is intentional: gateways provide doors; control planes enforce economics. Keep your per-token API gateway for developer API access to FLUX.2 [flex]; add o10 above it for spend enforcement and KYI governance.

Shadow mode mirrors live inference traffic through o10 without changing production routes. For every request, o10 evaluates candidate models against your per-use-case quality floors and records which route would have been cheapest and compliant — along with the cost delta — while the original provider still serves the response. Engineering sees proof without production risk; finance gets a verified savings figure tied to your traffic, not industry averages. Most teams run shadow for 7–14 days segmented by use case (support, RAG, code, batch) before flipping enforce mode.

Enforce mode places o10 in the request path. On every call, o10 selects the cheapest model and venue that clears your eval-defined quality floor, holds the budget envelope, and applies residency and retention policy before the request reaches the provider. Failed eval candidates are never routed. Each enforced call writes an immutable ledger entry: model, venue, policy, jurisdiction, and fully loaded cost. Enforce without shadow proof is possible but discouraged — shadow establishes trust with engineering and finance first.

A quality floor is the minimum eval score a model must achieve for a specific use case before o10 routes production traffic to it. Floors are per workload — support, RAG, code, and batch clear at different bars — and measured by replaying representative traffic through eval suites, not assumed from vendor benchmarks. Once a cheaper candidate passes the floor, o10 can route to it in shadow (proof) or enforce (live). Floors without evals are hopes; evals without floors are expensive defaults.

The 638× figure is the observed ratio between the most and least expensive compliant routing options for identical enterprise workloads at the same per-use-case quality floor across venues — not a guarantee for every team. o10 measured this across unified inference gateway, OpenRouter, Amazon Bedrock committed capacity, and owned open-weight in June 2026. Actual savings depend on your venue mix, volumes, and eval floors; shadow mode proves your organization's number against your baseline.

Savings are verified against your own shadow baseline per use case — not industry averages or vendor marketing claims. o10 mirrors a week or more of production traffic, segments by workload, and compares what you actually spent versus what you would have spent on the cheapest eval-passing route at the same quality floor. Finance signs off on the delta before enforce mode flips. Gainshare pricing ties o10 fees to this verified number, so savings must be real and auditable.

Use model ID `bfl/flux-2-flex` with your gateway's OpenAI-compatible `/v1` endpoint. Compatible with AI SDK, OpenAI Chat Completions, and Anthropic Messages formats. o10 intercepts the routing decision above the gateway — pointing your app at o10 in enforce mode changes which model ID is selected per request based on eval floors and budget envelopes.