1. Send a real path
Use representative payloads, not abstract savings talk.
Paste one to three redacted request shapes that are actually hot, expensive, repeated, or operationally messy.
Quote review
Send one real route.
We map the likely win
before cutover.
The fastest way to evaluate BTL Runtime is not a broad migration discussion. It is one representative request path, a quote preview, and a clear view of whether the win is routing, cache, dedupe, prompt shaping, or provider control.
Best use
One route first.
Not a big migration pitch.
If you already know the hot path, send it. If not, send one realistic payload shape and we will tell you where Runtime is likely to help and where it is not.
2. Quote before cutover
The goal is one believable wedge first.
We look at the route, benchmark direct cost, likely Runtime charge, and where the first win would realistically come from.
3. Keep the contract stable
Change the runtime layer, not the app integration first.
BTL Runtime stays OpenAI-compatible so the first conversation can be about economics and control, not a rewrite project.
Fit check
When quote review
is the right next step.
Good fit
You already have real AI traffic and know at least one route that is expensive, slow, repeated, or hard to manage cleanly.
Good fit
You want to compare benchmark direct cost against Runtime charge before moving live traffic.
Less useful
You are still in pure prototype mode and do not yet know what the hot route is.
Async first step
Paste the route,
not just the problem.
Redacted JSON is fine. A structured prompt summary is fine. The goal is one realistic request shape that makes the cost, latency, or control question concrete.