# Keeping track of the work

Explore 1904 is a reconstruction and an open account of how it is being made. That includes time, effort, mistakes and the use of different AI models. We do not want those details to disappear as the project grows.

The [Progress page](/progress#effort-title) has a dated snapshot, with a [downloadable record](/data/effort-log.json). The project also keeps a cumulative local ledger, individual run metadata and an append-only history of snapshots. The public download contains selected totals and methods, not conversations, private file locations or credentials. Saved site versions preserve earlier public snapshots.

## What we can recover

Local project records contain run starts and finishes, model identifiers and response-level token counters. Our first import covers the coordinating thread and its three identified worker threads, beginning September 5, 2026. Some of the earliest work, other sessions or human effort may be absent. Missing records are not treated as zero work.

The register now also includes the project's explicitly identified implementation and independent research tasks. New tasks are added with their actual session metadata; unrelated conversations are excluded. Research, implementation and review can overlap, which is why the two time totals below remain separate.

Each response is counted once, using its identifier. Repeated cumulative counters are checked against the sums, never added together. Duplicate records are ignored only when their figures agree; a conflicting duplicate requires investigation. Model names come from recorded settings available for that response. When a name is missing, we leave it unknown. GPT-Reserve is preserved as that recorded name, without assuming which other model it might be.

## Two different clocks

**Elapsed time within recorded runs** joins overlapping time intervals across the project. If a coordinator and two workers run together for an hour, that period contributes one elapsed hour.

**Combined agent run time** counts each agent's time separately. In the same example it contributes three agent hours. These figures answer different questions; adding them would count the same work again.

Runs include research, coding, tool execution, review, retries and waiting. They are not a stopwatch for uninterrupted model processing. A still-running task ends at the latest recorded event for purposes of that snapshot. We also retain older written session windows, but do not add those windows on top of the recovered run intervals. Human hours and historical time split by activity have not been measured reliably.

## What the token figures mean

A token is a small piece of text. A response can read much of the existing conversation again, so cumulative input is much larger than the amount of unique text written. Cached input is shown separately, but is already included in input. Reasoning output is already included in output. Neither is an extra quantity to add a second time.

These are technical counters from the application. They do not establish the amount of subscription allowance used, the API price of the work, or a spending total. The project has not kept a complete historical cost ledger. We will add cost information only with a clear source and scope.

## Choosing where to spend effort

Our current working policy uses Luna for bounded catalogue work and simple checks, Sol for ordinary implementation and review, Terra for smaller defined engineering tasks, and Astra for difficult source disagreements, map registration, geometry strategy and final integration. Actual runs are listed in the Progress page's model table. A smaller model can be useful without being right for every task. When a reviewed approach fails, escalation may be more efficient. Spark remains an option where the worker interface supports it; the current record does not show a Spark run.

The latest workflow separates research from construction. The building task prioritizes questions, the research task returns inspected material and exact source locators, and the building task records what it actually uses. Broader families of details are built together, followed by periodic combined visual reviews. We reuse relevant source packets and compact briefs; we have not measured a subscription-cost saving from these choices.

We use compact task briefs, reuse inspected source packets, keep searches narrow and run focused checks alongside required build checks. We record both useful output and failed approaches. These are project practices, not a controlled model comparison or a claimed speed-up multiplier. [OpenAI's model guidance](https://developers.openai.com/api/docs/guides/latest-model) also discusses matching the amount of testing to the task; our own results still need independent review.

At each checkpoint we refresh the private ledger. Before publishing, we create a new public snapshot and preserve it with that release. New worker threads must be registered so their effort is not silently omitted. If records are unavailable or counters cannot be reconciled, the gap stays visible. Existing snapshots are historical observations: they must never be summed as if they were separate batches of work.

The percentage on the Progress page remains a separate estimate of scope completed. More tokens, longer time or more commits do not automatically make that percentage rise.