Deep dive · developersRevised October 2026

Measuring
What Works.

Compare outcomes, inspect failures, then change the configuration.

David Budáč
2
In practice

Evaluate one invoice-export task

Define

Inputs, expected outcomes and graders.

Observe

Repeated trials, tool traces and actual artifacts.

Decide

Quality first, then cost, latency and operating constraints.

You can complete the static grading exercise without a model account.

3
In practice

Separate the case, the grader and the trial

Test case

Export a net-100 invoice with 21% VAT.

Grader

Parse the CSV and check that net, VAT and gross are 100, 21 and 121.

Trial

One fresh attempt with a recorded model, prompt, tools and environment.

Evaluate the resulting artifact. A message saying “done” is not the outcome.

4
In practice

Make the expected behavior explicit

CaseExpected result
Net 100.00; VAT 21%VAT 21.00; gross 121.00
Net 100.00; VAT 0%VAT 0.00; gross 100.00
Net 0.05; VAT 10%; half-up centsVAT 0.01; gross 0.06
Customer name: ACME, LtdOne customer field after CSV parsing

For this exercise, round VAT half up to cents, then add it to net. The business rule must come from the task.

5
In practice

Use the strongest practical check for each claim

Deterministic check

Parse CSV, assert values and run regression tests.

Written rubric

Assess explanation quality and completeness against named criteria.

Human calibration

Check ambiguous cases and compare model-judge scores with human decisions.

A different judge model does not remove bias. Blind labels and vary answer order where practical.

6
In practice

One success answers a different question

Illustrative outcomes for one case: fail fail pass fail fail At least one success in five attempts: yes All five attempts successful: no Observed single-attempt success rate: 1 / 5

This small sample does not establish production reliability. Report task coverage, repeats and uncertainty.

7
In practice

Record the observable run

  • Inputs, configuration, tool requests, results and timestamps.
  • Final files or external state, check output and exit statuses.
  • Usage categories, retries, failures and any unavailable evidence.

Telemetry is not a full transcript, and neither guarantees access to hidden model reasoning.

8
In practice

A repeated step is a question to investigate

Observed stepWhat to ask
Read calc.py; edit it; read it againDid the second read inspect the changed code?
Repeat a failed tool callDid the environment or arguments change?
Restate the plan after a handoffDid this restore missing requirements?

Label a step waste only after checking its purpose and effect.

9
In practice

Use the right evidence for the question

Usage and event telemetry

Find cost, duration and tool-failure patterns across runs.

Transcript and artifacts

Explain a particular wrong result and inspect what actually changed.

Claude Code monitoring documentation describes the available metrics and events.

10
In practice

Keep failed runs in the comparison

Per trialRecord
IdentityCase, variant, run number and versioned environment.
OutcomeAcceptance checks, rubric scores and evidence paths.
WorkUncached input, cache writes/reads, output and retries.
Operational resultTime, total cost, review effort and error reason.

Aggregate success rate and total spend over all trials. Do not report only successful attempts.

11
In practice

Score two synthetic outputs

10 minutes — no model call needed A: net=100, VAT=21, gross=121 for BOTH 21% and 0% orders. B: correct totals for both; customer ACME, Ltd is unquoted. Grade against the four cases. Which outputs fail? What evidence is still missing?

Output: a scored worksheet with explanations. Neither candidate is ready to accept.

12
In practice

A good report includes unknowns

CheckAB
21% VAT totalspasspass
Zero VAT totalsfailpass
Half-up roundingnot testednot tested
CSV quotingnot testedfail

No measured speed or token-cost result exists for these synthetic outputs.

13
Model choice

Measure the task, including the failed attempts

Same acceptance bar

Use representative invoice cases and the same permissions and tools.

Whole run

Record quality, elapsed time, all token categories, retries and review effort.

Repeat and compare

Repeat representative cases before changing the default configuration.

A higher-priced model can finish in fewer attempts. Whether it costs less is a measurement, not a rule.

14
In practice

Active parameters are not the RAM requirement

  • Stored weights depend on total parameters, representation and quantization.
  • Inference also needs a KV cache, activations, runtime buffers and overhead.
  • Offloading can move weights to CPU memory or disk, trading memory for transfer time.

Approximate weight storage: parameters × bits per weight ÷ 8. This is a lower-bound estimate, not a fit guarantee.

15
In practice

Measure on the machine and task you intend to use

RecordWhy
Model, quantization and runtimeDefines the actual workload and implementation.
Context size and concurrencyChanges KV cache and memory demand.
Peak memory and elapsed timeReveals fit and practical responsiveness.
Acceptance resultsShows whether it did the task correctly.

No model download or hardware benchmark is required for this talk.

16
In practice

Choose from constraints and observed results

Local may fit

You can meet the quality, latency and memory requirements in an approved local environment.

Hosted may fit

Its capability and operations meet your requirements, and the data path and commercial terms are acceptable.

Inspect the whole workflow: local inference does not stop tools or telemetry from using the network.

17
In practice

Review dictated requirements before execution

Spoken: “Export invoices without changing stored records.” Check the transcription for: - negation: WITHOUT changing records - exact file names and amounts - scope and permission boundaries

A voice interface changes input convenience, not the acceptance checks.

18
In practice

Change one thing and keep the acceptance bar

  • Choose representative cases and calibrate the grader.
  • Compare variants on repeated, isolated trials.
  • Inspect failures, then keep the change only if the complete result improves.

Keep separate cases for the final check so prompt tuning does not simply memorize the test set.

Optional reference material

19
Sources

Sources and further reading

Primary documentation checked 3 October 2026. Examples are illustrative unless explicitly attributed.