LandingModelsDocsBriefBetaDashboard
BTL Runtime technical brief

Same API shape.
Better runtime economics.
Cleaner customer UX.

This page goes one level deeper than the landing promise. The frontend port keeps the Whisper visual system, while the product details are now fully Gateway-specific: routing, cache, credits, keys, requests, and route-health visibility.

Product truth

Drop-in first.
Proof immediately after.

Teams adopt faster when the integration feels boring in the best way, then the dashboard earns trust with visible savings, stable routing, and customer-readable billing state.

API surface

Drop-in endpoints first.

The customer contract starts with the endpoints teams already expect: chat completions, responses, models, pricing, usage, and account bootstrap routes.

Savings engine

Routing plus repeated-traffic savings.

Cheaper compatible routes, exact cache, in-flight dedupe, and token-efficiency controls stack together instead of relying on one trick.

Commercial proof

Credits and benchmark pricing visible in-product.

The dashboard exposes charges, savings deltas, and top-up state so runtime improvements are measurable without an internal spreadsheet project.

Runtime stack

Savings come from layers
working together.

Gateway is strongest when routing logic, request optimization, billing controls, and product visibility are all part of the same system.

Architecture note

Customer-facing frontend and runtime visibility stay aligned.

The dashboard routes in `web/app/dashboard` are intentionally mapped to the backend contracts the runtime already exposes, so the port does not stop at marketing pages.

Routing
Multi-provider execution with route health, provider catalogs, and tenant constraints.
Optimization
Exact cache, semantic cache sharing, follower dedupe, and prompt-budget shaping.
Billing
Credits, settlements, top-ups, ledger rows, and customer-readable pricing endpoints.
Visibility
Usage timeseries, request drill-down, route-health views, and pricing previews.
Good fit

When this frontend plus runtime
is worth deploying.

01
You already have meaningful monthly model spend and want cheaper execution without another rewrite.
02
Repeated prompts, burst traffic, or tool-heavy flows make cache and dedupe savings realistic.
03
You need a customer dashboard that explains the gateway clearly after launch, not just a backend runtime.
04
Your team wants one clean frontend and one clean API story instead of stitching together internal tools and docs.