Research Workbench
Research Workbench

Evidence and activity

The record of every AI call, kept before it is asked and never changed, what the calls added up to over a period, and what the workbench is doing in the background.

Evidence and experimentstokensevidencetimelinecostimportsactivitytracebackground workusagecall tree9 min read

Activity has five tabs: Work in the background, Imports, Evidence, Runs and Usage.

Evidence: every call to a model

Every question the workbench puts to a model is written down before it is asked, and kept exactly as it was made. It is never changed afterwards, and failed calls are kept too, because they are as much a finding as the ones that worked. If the record cannot be written, the call is not made.

The evidence: one row per call

Each row shows:

Column What it says
When The day and time it was asked
What for The job (summarise, answer, claim check, critique…) and the document it was about
Model The provider, the model and its version
Tokens How much went in and how much came out
Took How long it took. While a call is running: so far, and how long it usually takes
Cost From the prices you entered. Hover to see which prices were used
How it ended Finished, Ran out of room, Stopped by a filter, Failed, Left unfinished, Still answering

What was asked, and what came back opens a call in place:

One call opened: what it was told, what it was asked, and the answer

  • Asked: what the model was told it was, any picture it was shown, and the full prompt.
  • Answered: the answer, with any diagrams and tables drawn.
  • How repeatable the call was (temperature 0, seed 1), and whether the document was longer than what was sent.

Left unfinished means the workbench was probably closed while the model was still working. The record of the attempt is kept anyway.

Why this matters: the evidence is what lets you say exactly how an AI-assisted result came about: which model, which version, what it saw, and what it said. You can cite it in your methods, or use it to check a doubtful answer.

The call tree: what ran inside what

One call is often part of something larger: a step of a workflow, a loop that went round twice, or a sub-agent working for another run. The Trace page shows the whole of it as a tree.

Open it in either of two ways:

  • From a call: on the Evidence tab, press Trace beside the call's job, in the What for column. The page opens on everything that call was part of, with the call chosen.
  • From a run: on the Runs tab, open a run and press Trace at the top.

Reading it

Each row is one part, indented under the part it ran inside, with how long it took. Its label says what kind of part it is:

Label What it is
Run A workflow run: the whole of it, or a sub-agent's own run inside a step
Model A step that asked a model. A retry shows under it as (attempt 2)
Tool A step the workbench did itself, such as compiling and testing code
Search A search of your vault made for a step, with what it looked for and found
Sub-agent A step that handed its work to another workflow, whose run sits inside it
Gate A step that waited for a person to approve it

Choose a row to read it on the right:

  • Chat: what the model was told, what it was asked, and what it answered, always shown as plain text.
  • Inputs and outputs: what the step was given and what it wrote.
  • Details: the model, tokens, cost, timings and identifiers, to cite or to find it again.
  • Events: what happened along the way, such as a provider refusing a call before the retry worked.

Show hides kinds of part you do not need, for example the searches. Timeline draws each part as a bar where it ran in time, so you can see at a glance where a run spent its minutes.

The summary under the title adds it all up: when it started, how long it took, what it cost, the tokens, and how it ended.

Example: sharpening a summary

The critique loop as a tree, with the first critique chosen

Sharpen on a document's summary runs the critique loop. Here a model on the computer wrote the summary; a hosted model critiqued it and rated the problems 3 out of 3, because the summary said reviewers were "not more accurate" where the paper reports accuracy falling by 6 points. The summary was revised, critiqued again, and rated 1, so the loop stopped. The tree shows the four steps in order, and choosing the first critique shows exactly what it said.

Example: code checked before it is trusted

Writing code: two model steps and two checks, with the first check's report open

A model wrote a function and its tests. The Tool step check compiled them and ran the tests in the sandbox: 3 passed and 1 failed, and it wrote again: true. The model revised the code from the failing test's name, and the second check passed. Choosing a check shows its report under Inputs and outputs; a tool step asks no model, so it has no chat.

Example: an experiment across several models

A run with a search, a retried call, a sub-agent and a gate

One run, with three providers' models taking part:

  1. find searched the vault by words and meaning, then asked Claude to propose an answer from eight passages. The provider was overloaded on the first attempt, so the call was made again, and (attempt 2) is the one that answered. Both attempts are kept.
  2. implement asked GPT to write the code.
  3. critique handed the result to the critique loop as a sub-agent: its own run, with Gemini summarising and Claude critiquing, sits inside the step.
  4. approve is a gate: the run waited for a person to approve adding the code to the study's repository.

The timeline of the same run makes the waiting visible: the models took seconds; the person took six minutes.

The same run as a timeline

Tip: the trace is how to answer "where did this come from?" for anything a model produced: which steps led to it, which models and versions took part, what each was shown, and what a person approved along the way.

Work in the background

Work in the background

After an import, the workbench keeps working: reading text, making working copies, drawing first-page pictures, cutting passages, indexing code, and searching by meaning (embedding). This tab shows how many items wait in each queue, and what each queue means. It refreshes every few seconds. When there is nothing left, it says Everything is done. There is nothing waiting.

Imports

The Imports tab is the history of every file brought in, with its outcome. Finished imports are cleared after the number of days set in Settings → Imports. Failed ones are kept until you deal with them.

Runs

See Experiments and runs.

Usage: what the calls added up to

Usage adds up every call in the evidence over a period of days: how many there were, how much they read and wrote, what they cost, how many failed and how long they took. Nothing is recorded for it separately; it is all summed from the calls' own records.

Usage over the last 30 days

Choosing the days

Pick Today, Yesterday, Last 7 days, Last 30 days (the default), This month or Last month. For any other days, set From and to and press Show these days. The days are your computer's days.

The totals

Tile What it says
Requests How many calls, and on how many of the days any were made
Tokens The total, split into what the models read and what they wrote
Cost From the prices you entered. A model on your computer costs nothing. If some calls went to a hosted model with no price, the tile says how many, for example + 11 calls not priced, and they are not in the total
Failed Calls that did not finish, and their share of all requests. The tile turns red when there are any
Usually How long a call usually took (the median), with the slowest underneath

When calls are missing a price, a note under the tiles links to the place to set it: Settings → Writing, under What this model costs. A cost that is entirely unpriced shows as unknown, never as free.

Day by day

On a period longer than one day, a chart shows a column for each day. The answered calls are blue, and the failed ones red at the top of the column. The number at the top left is the busiest day's count. On a long period only the first day, each Monday and the first of a month are named underneath. Hover over a column to see that day's requests, failures and cost.

The tables

Below the chart, the same figures are divided by model, by kind of work, by project and, in the cloud workbench when more than one person uses it, by person, busiest first. A thin bar under each count shows its share of the requests. Failures are in red; a zero and an unknown cost are grey.

Tip: to keep spending in check, set Your monthly AI budget in Settings → Writing (a project can also have its own Monthly AI limit in its settings). Usage then says how much of this month's budget is spent, and warns when it is nearly gone or used up. Models on your computer cost nothing and are never stopped by a budget.

Something went wrong. Reload the page to continue. Reload 🗙