See where time and calls went

IDEA 1

Follow a trace and its spans

A trace records observable events during one run, such as a tool request, its response, and an error. A span describes an operation within that trace, often with start and end times. These records help explain where work happened. They do not reveal a model's private reasoning, and a long trace is not automatically a thoughtful one.

The browser runner records your real JavaScript tool calls and a measured overall duration. Its data and decisions are authored simulations. It does not send tokens to a model or receive an API bill. Read the metrics according to what was actually measured, and keep private inputs out of logs when designing a real application.

Connect an output to observable events

1. Request. The controller asks for item A.
2. Response. The tool returns the fixture value.
3. Run report. Inspect real call count and measured duration.

Follow this authored example, then test the idea in the lab.

Read the example

const item = tools.readItem("A");
return { value: item ? item.value : null };

The trace can show that readItem was called and what it returned. It cannot establish an unrecorded live-model cost.

Think it through: What can this lab's trace directly establish?

IDEA 2

Find repeated work

Look for repeated operations with the same inputs. If a task reads item A three times from a fixed catalog, the second and third reads may add no information. Reusing the first observation can reduce work while preserving the requested result. First identify the repetition in the trace, then make a small change and compare behavior.

Correctness still comes first. A program that makes zero calls and guesses values is cheaper by call count but does not satisfy the evidence requirement. In this lab the output must preserve request order, including repeated values, while reading each distinct item only once. The trace exposes whether the code achieves both goals.

One observation can serve repeated requests

1. Requests. The caller asks for A, B, then A again.
2. Reads. Fetch each distinct item once.
3. Output. Return values in the original request order.

Follow this authored example, then test the idea in the lab.

Read the example

if (!cache.has(id)) cache.set(id, tools.readItem(id));
const item = cache.get(id);

Map.has distinguishes a cached missing result from an item that has never been requested. A truthiness check would read missing items repeatedly.

Think it through: Why can if (!cache.get(id)) cause extra reads for missing items?

IDEA 3

Cache only when the key and lifetime are valid

A cache is a stored observation reused instead of a new lookup. Its key must include everything that affects the result. An item ID is enough for this fixed catalog within one run. In a real service, the result might also depend on the user, location, permissions, catalog version, or time. Leaving those out can reuse the wrong information.

This cache is created inside solve and disappears when the run ends. A new case receives a new catalog and a new cache. That deliberately avoids pretending that old availability or prices remain fresh forever. Also distinguish caching a confirmed missing record from caching a temporary failure: the latter may hide recovery. Our readItem tool returns a record or confirmed fixture absence, not a transient network error.

Give every cache a scope

1. Key. Item ID is valid within this one fixed catalog.
2. Lifetime. A new solve call starts an empty cache.
3. Fresh run. Changed fixture values are read again.

Follow this authored example, then test the idea in the lab.

Read the example

function solve(input, tools) {
  const cache = new Map();
  // This cache belongs to this run only.
}

Local scope is the expiration rule here. It is not a production cache invalidation strategy for changing external data.

Think it through: A real room-availability result depends on both room and date. Which cache key is sufficient?

Put it into practice

Return one value for each request in order while reading each distinct ID at most once per run.

1. Read the selected case and predict its expected result.
2. Run the starter once. Use the failed check and tool trace to locate the missing rule.
3. Insert the explained snippet at the TODO, then run the case again.
4. Test all three cases. Change the experiment input and explain whether the same rule still works.

Your next experiment: Add two more requests for A and one new request for C. Predict the output length and the number of distinct tool reads before running.

Measure the work that actually happened, then reduce repetition without weakening evidence or freshness.

Key terms

Trace

A record of observable operations and results in a run.

Span

A recorded operation within a trace, often with start and end times.

Cache key

The inputs used to identify which stored observation can be reused.

Sources and scope

Original Stemtiq teaching, reviewed 2026-09-14. The named researchers and organizations do not endorse this course. Classroom cases are authored exercises, not published findings.