A model trained for the work your agent actually does.
Traces show us the workload. Your evals define success. We train a smaller model on the repeatable portion, measure what it can safely handle, and deploy it with your current frontier model as fallback.
A model you own.
Why a trained model wins on repeated work.
Nothing exotic: the model stops re-deriving what your workload already told it.
Fewer thinking tokens
A frontier model reasons its way to work it has never seen. A trained model has seen yours ten thousand times, and spends far fewer thinking tokens getting there.
Your evals are the gate.
We do not assume a smaller model replaces the frontier model across your full task distribution. We measure where it does, on your evals, never a parallel suite we invent.
Quality
Measured against your current production model, on your evals.
Coverage
The share of traffic the trained model can safely handle.
Cost and latency
At that traffic split, not in isolation.
Failure slices
The work that still requires the frontier model, named.
Simulation helps us train. Your evals decide whether the model ships.
The simulation.
Built from your traces: your tools, your data shapes, your failure modes.
Scenarios from your real distribution, including the rare failures.
Candidate models run them end to end, without touching production.
Every outcome checked; the loop calibrated against your evals.
It makes retraining cheap to repeat. It does not decide what ships: your evals do.
Training.
The method follows the signal your workload actually has. It is not a fixed recipe.
GRPO + OPSD, over scenarios
Verifiable outcomesThe policy improves against verified results in the simulation, not static examples.
Distillation
A frontier teacherTeacher trajectories and hindsight supervision compress into a small model you own.
Supervised fine-tuning
Gold responses in your trafficFull trajectories, with validator retries cleaned so the model never learns to loop.
Updates to the model.
Base models and harnesses move every couple of months. The lifecycle is built for that, and nothing in it happens without your approval.
Keep the current route
Existing provider keys and models remain the baseline.
Shadow a candidate
Replay real traffic without changing production behavior.
Evaluate
Your quality, cost, and latency criteria decide.
Approve the route
You change the alias only after the result is clear.
Retraining is a managed cadence, warm-started from the current checkpoint. New base models are evaluated as they ship, every promotion is yours to approve, and the previous checkpoint stays one alias change away.
Serving.
Speed is a target we reproduce in your deployment, not a claim you take on faith.
A ~1 ms overhead target, measured in the open. The engine's public CI badge shows today's number: about 20 ms p50 through the gateway against a local mock. The acceptance target stays ~1 ms, and the number that counts is measured at p50 and p95 in your deployment before cutover, provider and network time excluded.
Serving speed, same bar. Tokens per second measured on your real agent path, against your current setup.
If the bar is missed, remove it. A written report shows overhead and output parity. You decide whether it stays.
One real agent path
You select a representative long-running task. We deploy alongside the workload using your provider keys.
Direct versus gateway
Replay or shadow the same requests. The report covers p50 and p95 processing overhead, end-to-end latency, streaming, errors, and failover.
You decide whether it stays
No automatic changes. You keep your providers, your evals, and your application behavior.
What changes in your application.
- 01The request and response schema stay exactly as they are.
- 02You select a new model alias. That is the integration.
- 03Your current observability keeps working; every call is attributed as before.
- 04You approve the deployment and the traffic percentage.
- 05The trained model serves the qualified slice.
- 06Your current frontier model remains the fallback path.
- 07You can download the weights and self-host at any time.
- model: "gpt-5.6"
+ model: "acme-support-v3"Where this has worked.
Both studies are public, measured on held-out tasks, with the methodology written down.
97% cheaper than Opus 4.8, and 50% better than baseline.
9.4× faster and 90% lower cost, with 10.9% higher verdict accuracy.
Start with one workload.
A managed evaluation and model-training engagement, starting with one managed workload. If the model is deployed, the engagement fee is applied toward inference.
Questions
How much work is this for my team?
Choose one representative path and provide the existing eval criteria. We handle deployment, instrumentation, replay, and the written result. It is built for teams with no bandwidth for another migration project.
What happens when a better model ships?
Models change roughly every two months. We shadow the candidate against your traffic and your evals; you see quality, cost, and latency, then approve any route change. Nothing switches automatically.
Will fine-tuning actually close the gap?
We are not assuming it will. The trained model is tested on a held-out set against your current production model. If the metric does not move, we do not deploy.
What do we own?
The weights. Every checkpoint is downloadable; self-host it or let us serve it, and hosted inference is optional. Your data trains your model and nothing else, with retention agreed per engagement. The full posture is at /security.
Is my workload a good candidate?
Good candidates repeat: the same kind of work at volume, heavy general-model spend, an existing eval or validator, and a reasonably stable tool space. We would tell you to wait if the task is open-ended with little repetition, the workflow is still changing weekly, there is no trustworthy eval signal yet, or the failures live in the harness rather than the model. The audit is honest in both directions.