Measure the cost of an investigation
Compare the calls, response bytes and local analyses behind two answers.
Did the agent get the same answer with less data?
Compare two ways of answering the same question against the same synthetic capture. Verify the answer first. A smaller reply that skipped a failed request isn’t a more efficient investigation.
The bundled CLI can read a local workflow report without starting the app, enrolling an agent, or contacting a provider. Given a workflow JSON file containing baseline and candidate attempts, run:
joesproxyctl efficiency report --file workflow.json --jsonIn a synthetic repeated-read fixture, the bundled CLI reported:
| Metric | Baseline | Candidate |
|---|---|---|
| Calls | 9 | 9 |
| Response bytes | 12,474 | 6,266 |
| Local analysis executions | 9 | 1 |
Both runs had nine calls. The difference was what came back and how often the Mac repeated the analysis, not fewer round trips. These are recorded fixture inputs processed by the report, not a prediction for your capture. Neither run supplied provider usage, so token and cost savings are unknown.
Read your own comparison
Use the offline report reference for a complete small input you can copy. Inspect failures and retries before reading the candidate-minus-baseline fields. Use matching fixture, version, environment and measurement boundaries. If the contexts differ or an attempt failed, the tool withholds comparative deltas. Missing measurements aren’t zeros.
Count discovery and approval calls if you’re measuring a first-time investigation. A short calculation result can still be part of a larger exchange than the raw input. Repeated investigations with an already connected client answer a different cost question; label them separately. The report only reads its input and writes the report to standard output.