Frequency
How often does the same request shape, tool plan, or output schema recur? One expensive exception rarely justifies a new serving path.
// operating guide
AI agent cost optimization starts with evidence, not a cheaper model.
The largest invoice line is not always the best optimization target. Start with work that repeats, can be checked, has clear freshness requirements, and can fall back safely when the candidate is not eligible.
Product-fit boundary
Punk is useful when supported traffic contains repeatable, reviewable work. It can establish a workload-specific baseline and test eligible alternatives. It does not promise savings for open-ended, high-risk, sparse, or poorly instrumented work.
// diagnose before changing routes
Measure four things together.
Cost + latency
Use observed per-run cost and time, not a provider list price. Include failures, retries, and the work surrounding the model call.
Verifiability
Can you compare an alternative with a schema, deterministic fields, a reference set, or a defined reviewer?
Safety + freshness
Identify identities, permissions, tool state, and time-sensitive inputs that make a superficially similar request unsafe to reuse.
// match the mechanism to the work
“Optimize” is not one technique.
| Path | Best fit | Question to answer first |
|---|---|---|
| Exact response cache | Identical, stable, side-effect-free requests | Does the key include tenant, app, subject, policy, and freshness dimensions? |
| Tool-result cache | Declared read-only data with an explicit TTL | Who is authorized to see this result, and when does it become stale? |
| Plan reuse | Stable tool sequence with fresh reads | Can the plan repeat while source data is fetched again? |
| Deterministic artifact | Checked transforms or classifications | Can replay and shadow evidence demonstrate the required output behavior? |
| Model substitution | Work with measurable quality and fallback | What quality, policy, and drift threshold keeps the route eligible? |
Do not use cost as the only route signal. A cheaper answer that crosses a tenant boundary, misses fresh data, or violates policy is not a saving.
// a safe first experiment
Run this sequence on one narrow workload.
Keep the live response
Route supported model traffic through an observe-only integration. Capture a baseline without changing the customer-visible answer.
Find repeatable candidates
Prioritize recurring classifications, structured summaries, and read-only lookup plans with a visible owner and acceptance criteria.
Define the comparison
Choose structural, semantic, side-effect, and freshness checks before looking at a candidate’s cost estimate.
Prove and scope
Use replay and shadow evidence, then restrict a successful route to the same policy and identity conditions under which it was qualified.
Keep the exit path
Track route explanations, mismatch signals, and fallback so a drifted or ineligible request returns to the configured live provider.
Find expensive repetition in your own traffic.
Start with observe-only traffic analysis, or bring a bounded workload with examples, acceptance criteria, and known side effects for a review.