Back to case studies
Case study · Aviation Retail · Weeks

Cutting agent token costs 75% with an agentic eval loop.

Sporty's

Sporty's — Cutting agent token costs 75% with an agentic eval loop.
Brief

After a migration to the Assistants API and a wave of new features sent token costs through the roof, we built an agentic eval loop that graded candidate variants against a rubric — and shipped the cheapest config that held accuracy.

After migrating the agent from the direct OpenAI API to the Assistants API — and shipping a wave of new user-facing features on top of it — Sporty’s token costs skyrocketed. The features were the right bet; the cost curve wasn’t. The brief was to bring it back down without losing what made the agent worth running in the first place.

~75%
Token cost reduction
~95%
Agent accuracy, held constant
Faster
Per-request latency, not just cheaper

The shape of the loop

The approach was an agentic eval loop: the agent itself checked out git worktrees and wrote variations on its own code — different models, different caching strategies, different combinations — and the loop graded each variant against a rubric.

Baseline → variants → rubric → ship the cheapest one that holds accuracy
BaselineMost expensive model, ~95% rubric score
Worktree variantsAgent-authored code changes
Models × cachingGPT · Bedrock · Ollama
Rubric gradeSame grader, same eval set
ShipCheapest config that holds ~95%

The grader never changed — it was the original GPT model that set the baseline, so every variant was judged by the same standard that approved the expensive version.

The rubric was the whole game. We set up a separate grader model — the original GPT model that had produced the baseline — and used it to score agent output against the rubric across a representative eval set. That same rubric, applied to production on the most expensive model, scored ~95%. That number became the floor: any variant that didn’t hold it was out, no matter how cheap.

What we swept

  • Models — swapped across providers (OpenAI, AWS Bedrock, Ollama) and across tiers within each, looking for the cheapest model that still passed the rubric on this workload.
  • Caching strategies — different prompt-caching and response-caching configurations, since a lot of the new features reused overlapping context.
  • Combinations — the loop ran models and caching strategies in combination, not isolation, because the cheap option on paper wasn’t always the cheap option once caching interacted with it.

What the agent did itself

The “agentic” part wasn’t a slogan. The agent checked out git worktrees and wrote variations on the code — its own prompts, routing, and caching logic — then handed each variant to the eval loop. We weren’t hand-tuning prompts and re-running the suite; the agent was generating candidates, the grader was filtering them, and the loop was converging.

Where it landed

Same agent, same ~95% rubric score, ~75% lower token cost, and faster per request — because the cheaper configurations also tended to be the ones that didn’t carry the overhead of the expensive path. The features stayed. The cost curve didn’t.

What's next

Have a similar problem worth solving?

We work with a small number of teams at a time. If you've got a system to build, audit, or automate, let's talk.

Start a project

Tell us what you're building.

A few lines is plenty — we'll reply from a real inbox, usually within a day.

What do you need?

Prefer email? mike@sourcemain.com