spend less on ai. prove you didn't make it worse.
optiml measures the ai your product already runs, tests cheaper models, prompts, and configurations against that record, and gives you a safe way to roll out the ones you approve.
optimization found
support triage · production
12,481 historical production cases tested
current
frontier model · full context
cost / successful request
$0.184
quality score
94.7%
p95 latency
2.4s
candidate
smaller model · compressed context
cost / successful request
$0.091
quality score
94.9%
p95 latency
1.8s
50.5% lower cost
+0.2 quality
-25% latency
rollout
benchmark
approve
5% canary
25%
100%
auto-rollback armed — any stage that misses its quality or error budget reverts to the current configuration.
illustrative example. the numbers above are a worked demonstration of what a recommendation looks like — not live data, and not a benchmark of any named model.
running on optiml today
the idea
the cheapest way to run a workload changes. your setup doesn't.
most teams pick a model once, write a prompt once, and never revisit either. meanwhile prices move, smaller models catch up, and half the context you send does nothing. optiml connects to the ai you already run and records what each request costs and how good it was — the evidence you need to argue for a cheaper way to serve the same workload, and to prove it is not worse.
not just a dashboard
observability tells you what happened. optiml turns that record into a cheaper configuration you can test, approve, and roll out in slices.
not only a proxy
the call does pass through us — that is the point. every request becomes a measured record a cheaper configuration can be argued against.
not a rewrite
your workloads keep working the way they do today. what changes is the model, prompt, and context underneath.
integration
change the base url. that is the whole integration.
point an openai-compatible client you already have at optiml with an optiml server key. no rewrite, no workflow, no studio — and from the first call, every request is recorded against a workload.
from openai import OpenAI
client = OpenAI(
# was: the provider's own base url and your provider key
base_url="https://api.optiml.one/v1",
api_key="YOUR_SERVER_API_KEY",
)
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": "..."}],
)import OpenAI from "openai"
const client = new OpenAI({
// was: the provider's own base url and your provider key
baseURL: "https://api.optiml.one/v1",
apiKey: process.env.OPTIML_SERVER_KEY,
})
const resp = await client.chat.completions.create({
model: "gpt-4o-mini",
messages: [{ role: "user", content: "..." }],
})curl -X POST "https://api.optiml.one/v1/chat/completions" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_SERVER_API_KEY" \
-H "X-OptiML-Workload: support-answer" \
-d '{"model": "gpt-4o-mini", "messages": [{"role": "user", "content": "..."}]}'X-OptiML-Workload is optional. every request resolves into a workload and a baseline execution strategy on its own — the header just puts your own name on it. business outcomes can be attached after the request has finished, and corrected later.
nothing to rebuild
a client you already have, pointed at a new base url. no workflow, no endpoint slug, no studio. optiml decrypts the provider credential you configured, server-side, and calls the real provider.
every request leaves a record
provider, model, latency, and success on each call, correlated by the request id returned on the response. cost is recorded where the provider reports usage; where it does not, pricing is estimated and labelled estimated.
routing you can predict
a bare model id is always direct inference. only optiml/<endpoint-slug> addresses a deployed optiml workflow, so a production request can never silently become one.
this is the evidence layer, and it is the part that is live today: optiml observes the ai workloads you already run in production and builds the record that optimization is argued from. nothing about what runs changes until you approve a change.
the optimization loop
measure, search, verify, roll out — then do it again
the record is the part that never stops. the cheapest way to serve a workload keeps moving, so the question is worth asking more than once.
connect
change one line — point the client you already have at optiml. from the first call it records the provider, model, latency, outcome, and cost where the provider reports usage.
measure
each workload gets a baseline from your own traffic — cost per successful request, quality, p95 latency. not a public leaderboard.
search
optiml builds candidate configurations: smaller models, tighter prompts, compressed context, different routing strategies.
verify
every candidate is replayed against your historical production cases. if quality drops, it never leaves the bench.
roll out
you approve the winner, then it ships in canary steps — a small slice of traffic first — with auto-rollback tied to the quality and error budget you set.
measurement, experiments, canary rollout, and rollback ship in runtime today. the surfaces that turn those into automatic recommendations — optimizations, workloads, and evals — are in preview, and they are labelled that way inside the product too.
what gets optimized
four things decide what a request costs
these are the four the runtime can actually change. the record optiml keeps on your traffic is what tells you which one is worth moving, instead of guessing one at a time.
which model runs
move a workload between providers and model sizes, or route per request — cheapest, fastest, balanced, or fallback.
how the prompt is written
shorter system prompts and tighter output contracts. same behaviour, fewer tokens on every single call.
how much context you send
retrieved documents and conversation history trimmed to what actually changes the answer, instead of everything you have.
how the work is shaped
collapse redundant steps, and send the easy cases down a cheaper path so the expensive one only handles what needs it.
safe by construction
cheaper only counts if quality holds
a saving you cannot prove is just a regression you haven't noticed yet. every change walks the same four gates.
01
eval
define what good looks like first — structural checks, regression cases, and ai-graded rubrics built from your own examples.
a candidate that fails an eval never gets scored.
02
benchmark
replay recorded production cases through the candidate and the current configuration side by side. cost, quality, and latency, on the same inputs.
you see the trade before anyone else does.
03
canary
weighted routing sends a small slice of real traffic to the winner — 5%, then 25%, then everything — while the rest stays on what works.
you widen the slice; the numbers are what you widen it on.
04
promote or roll back
promote when the candidate holds up. rollback rules watch error rate and latency, and revert to the last good version without waiting for you.
every version stays one click from coming back.
today the pre-traffic check is a replay against recorded production cases. mirrored live shadow traffic is on the roadmap, not shipped.
product · runtime
runtime is the part that can change what actually runs
optimization only means something if someone can ship it. runtime puts your workloads behind a versioned endpoint, which is what makes a recommendation testable, shippable in slices, and reversible.
one endpoint, many versions
your app posts to a stable url. every configuration change is a numbered version behind it, so swapping a model never means shipping app code.
per-step cost and traces
each request records what ran, how long every step took, and what it cost where the provider reports usage — estimated pricing is labelled estimated. that record is the baseline everything else is argued from.
nine providers, one integration
openai, anthropic, gemini, mistral, cohere, groq, together, deepseek, fireworks — moving a workload between them is a config change, not a refactor.
connect
start from the code you already have
paste a github repo url. optiml scans it for ai calls and opens a pull request that routes them through a versioned endpoint — so there is something to measure on day one.
works with openai, anthropic, gemini, and more
studio
for advanced work
when a workload is more than a single call, studio is where you shape it — steps, tools, conditions, and the ai router on a canvas. most teams never open it. the optimizer works on whatever you already run.
preview · not connected to your tools
product · workforce
the same question, asked about your internal ai
runtime optimizes the ai inside your product. workforce points the same loop at the ai your team uses to do its work — which tools get used, what they cost, and where the spend is not earning its keep.
one view of internal ai spend — seats, subscriptions, and api usage together instead of four separate invoices.
which internal workflows people actually run, and what each one costs to run.
the same recommendation shape as runtime: a cheaper way to do the same work, with the evidence attached.
workforce is a preview of where optiml is going. it is not connected to any tool yet, and no part of this section shows live or measured data.
providers
bring your own providers and keys
optiml runs the workload; your billing relationship with each provider stays yours. that is also why moving a workload to a cheaper model is a config change rather than a migration.
openai
anthropic
gemini
mistral
cohere
groq
together
deepseek
fireworks
paste a call you make today
drop in an openai, anthropic, or gemini snippet and we'll show the single request your product would make instead — the version optiml can measure, test, and swap underneath.
token-level streaming is supported for single-step openai workloads. other workload shapes return their step events once the run completes.
pricing
start free. upgrade when the volume is real.
what you pay optiml is separate from what you pay providers — you keep your own keys and your own provider bill.
free
$0
validate the idea before you scale.
2 projects, 5 workflows
1,000 requests/mo
1 seat, 1 server key
all providers, your own keys
traces, cost, and latency
startup
$49/mo
founding teams shipping to real users.
10 projects, 25 workflows
50,000 requests/mo
5 seats, 5 server keys
a/b experiments
auto-graded evals
rollback + version history
team
$149/mo
growing engineering teams.
unlimited projects & workflows
500,000 requests/mo
20 seats, 20 server keys
up to 5 organizations
everything in startup
enterprise
custom
high volume and a contract to match.
everything in team
unlimited requests and seats
unlimited organizations
dedicated support channel
custom contract
every plan includes direct inference — point the client you already have at optiml and start recording. the free plan is free to keep. paid plans are month to month and take a card at checkout — there is no trial period. sso, saml, and audit logs are on the roadmap and are not part of any plan today.
find out what your ai actually costs
change one line in the client you already have. you get a baseline from your own traffic, and every request after it is measured against that baseline.
optiml observes the ai workloads you already run in production and builds the evidence layer that optimization is argued from.