Run your first analysis

An analysis takes traffic you already captured, replays a sample of it against other models, grades the answers, and reports whichever swaps come out cheaper without costing you quality. It is the reason the hosted cloud stores content at all.

This page walks one run end to end. It assumes you have sent a trace and named at least one route. Analysis is a hosted-cloud and BYOC feature. The open-source server does not have it.

Before you start

Three conditions have to hold, and the dashboard tells you when one does not.

• There has to be traffic in the window. A run reads the last four completed UTC days. Started today, it will not see anything you sent an hour ago.
• Every model in that window has to be priced. If your production traffic used a model the catalog does not know, the run fails with “This analysis needs pricing for every production model before it can start” rather than quietly reporting a saving it cannot compute.
• One run at a time per workspace. Starting a second is refused while the first is active.

1. Start the run

   Open Optimize and choose Analyze production traffic. Before it starts, the confirmation view shows you exactly what is fixed about the run: the capture window, the sample size, how many workloads it will look at, the objective, and every candidate model by name. You do not configure any of it, and neither does support. The profile is server-owned and snapshotted onto the run, so a report can always be read against the settings that produced it.

   The objective is lower cost, same or better quality. A candidate has to come in under your current spend and hold quality to be reported at all.

2. Watch it move

   A run passes through four stages, and the card shows which one is live.

   Stage	What is happening
   Queued	The run row exists and an isolated task is being launched.
   Exporting traffic	Your captured calls for the window are being extracted.
   Analyzing	The pipeline samples, replays and grades. This is the long stage.
   Importing report	Results are validated and written back to your workspace.

   Nothing here touches your application. The run is a separate task, reading a snapshot of data you already sent.

3. Read the outcome

   A completed analysis lands on exactly one of four outcomes. Three of them contain no recommendation, and only one of those three means something went wrong.

   Opportunities found. One or more candidate swaps beat what you run today. Go to step 4.

   “Your current models are already the cheaper choice.” Workloads were evaluated, candidates were replayed and graded, and none of them won. This is a real result, not a failure. You now have evidence that your current choice is defensible, which is the answer most teams actually want and almost never get. Run it again as your traffic changes.

   “Not enough traffic in any single workload.” No workload reached the minimum sample count. The card names the largest workload it found and how many traces it had. The usual cause is that traffic is spread across many unnamed template: groups instead of a few named routes, which is what naming a route fixes.

   “This analysis could not evaluate every candidate.” Something did not complete. The card names the candidates that dropped out. Run it again, and tell support if it keeps happening.

4. Read the evidence, then decide

   A recommendation is not a verdict handed down. It is a claim with the working shown, and you are expected to check the working.

   • The swap. Which workload, which model today, which model instead.
   • The measured effects. Cost, latency and quality as ratios against your current model, not absolute numbers borrowed from a vendor page.
   • The grade distribution. How many replayed samples came back A, B, C or F against the answer your system actually produced, and the resulting safe switch rate.
   • Coverage. How many cases were evaluated and how many were complete. A strong ratio over few cases is a weaker claim than a modest ratio over many.
   • The samples themselves. The actual replayed request, your recorded answer, the candidate’s answer, and the grade with its reason. Read a few. They are the only part of the report that can tell you the grader misunderstood your task.

   A recommendation arrives either as recommended or recommended pending validation. The second is the engine saying the evidence points one way but is not strong enough to stand alone, so try it on your own traffic before committing.

5. Act on it

   The change is yours to make. Edit the model in your code and ship it, the same as any other change. If you have installed MetergraphBot and your traces carry repository identity, it can prepare the pull request for a supported recommendation after you approve it. It never merges anything.

   Then leave the route alone and let it accumulate traffic under the new model. The next analysis compares the same route against itself.

An empty report is not a broken one

The engine reports what the evidence supports and nothing more. A run that evaluated your workloads and found no worthwhile swap has done its job. Treat a run that finds nothing twice in a row as a reason to look at something other than model choice: prompt size, retry behaviour, or whether the route is doing two jobs that should be split.

Next

How analysis works Replay, equivalence grading, and what the confidence in a report is actually made of.

Record real outcomes Tell Metergraph what actually happened to a request, without sending any more content.