Integration path
Drop-in first, not rebuild first.
BTL Runtime starts with the API shape teams already expect: chat completions, responses, models, pricing, workspace bootstrap, and machine-key auth.
BTL Runtime technical brief
Same API shape.
Better runtime economics.
Proof before cutover.
BTL Runtime is a self-serve OpenAI-compatible gateway with workspace auth, machine keys, request-level savings proof, and a customer-facing dashboard. The point is to make adoption feel boring at the API boundary and convincing everywhere after it.
Product truth
Drop-in first.
Proof immediately after.
Teams adopt faster when integration is one base-URL swap, then the product earns trust with quote previews, live request headers, stable routing, and customer-readable billing state.
Proof path
Quote and verify before cutover.
The product can quote a representative request before live traffic, then show x-btl-benchmark-cost, x-btl-customer-charge, and x-btl-saved on the live path.
Commercial path
Hosted credits or connected provider keys.
Teams can add paid hosted credits, or connect upstream provider keys while keeping the same dashboard, request logs, and routing layer.
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
The sales path and product path are the same story.
The landing page, docs, model catalog, quote route, and dashboard all map to product surfaces that already exist. That matters because buyers can verify the story without learning an internal flow first.
Public surfaces
/v1/models, /v1/providers, and /v1/account/pricing let prospects inspect the catalog and pricing context before they route traffic.
Request path
/v1/chat/completions and /v1/responses stay OpenAI-compatible while the runtime handles routing, cache, dedupe, and prompt-efficiency controls underneath.
Economic proof
/v1/account/quote and the x-btl-* headers make benchmark cost, customer charge, and savings visible without spreadsheet work.
Workspace product
Dashboard pages for requests, credits, cache, providers, keys, and settings make the gateway usable by a real team after signup.
Good fit
When BTL Runtime
is worth deploying.
01
You already have meaningful model traffic and want lower effective cost without changing the app integration shape.
02
Repeated prompts, burst traffic, or tool-heavy flows make cache, dedupe, or prompt-efficiency savings realistic.
03
You want a team-facing workspace product with machine keys, request history, credits, and billing visibility, not just a hidden backend proxy.
04
You need to prove the economics before cutover by quoting representative payloads, not by promising savings in the abstract.