Atlas Scout Preview 24 · Official release · August 1, 2026
The same index. Ready in less than half the time.
Preview 24 rebuilds the path between extracted code and Atlas Scout’s local SQLite map. On locked Linux and Firefox campaigns, complete fresh-index readiness fell by 57.72% and 54.44%—with the same logical records, the same full-text-search results, and the same transaction and durability boundaries.
Linux and Firefox · fresh database · complete readiness
Two large repositories. More than half the wait removed.
The product boundary is the moment Atlas Scout has finished indexing, resolved the structural map, passed its integrity checks, and can answer the asserted MCP readiness query. Preview 24 improved that complete boundary—not one isolated phase presented as though it were the whole experience.
Swipe the chart and exact-value table sideways to inspect every value.
Complete readiness and serialized writer time
- p50 of 3 runs per arm
- fresh isolated database
- locked corpus and host policy
- same complete-readiness boundary
- lower is better
| Measured phase | Scalar p50 | Preview 24 p50 | Change |
|---|---|---|---|
| Linux · complete readiness | 282.777s | 119.559s | −57.72% |
| Firefox · complete readiness | 380.907s | 173.524s | −54.44% |
| Linux · SQLite writer | 250.027s | 82.188s | −67.13% |
| Firefox · SQLite writer | 289.097s | 113.153s | −60.86% |
Measured bottleneck · focused changes · no schema shortcut
The writer stopped paying one statement at a time.
Profiling showed that source extraction was no longer the dominant cost. The serialized SQLite writer was spending most of its time preparing and executing millions of symbol, identifier-term, and relationship statements. Preview 24 moves deterministic validation and preparation ahead of that single-file writer, binds relationship sources to already known symbol rows, and inserts the highest-volume records in bounded batches.
Where the serialized time went
- p50 of 3 runs per arm
- fresh isolated database
- locked corpus and host policy
- same complete-readiness boundary
- lower is better
| Measured phase | Scalar p50 | Preview 24 p50 | Change |
|---|---|---|---|
| Linux · symbols + terms | 221.406s | 58.159s | −73.73% |
| Firefox · symbols + terms | 232.600s | 67.736s | −70.88% |
| Linux · relationships | 18.565s | 11.577s | −37.64% |
| Firefox · relationships | 30.275s | 20.355s | −32.77% |
Prepare before serialization
Keep safe CPU work off the narrow path.
Validation, count projection, identifier-term preparation, and fallible conversions happen before writer entry, where they can overlap other indexing work.
Use known ownership
Stop looking up what Scout already knows.
Relationship sources bind directly to symbol rows captured during the same atomic write. Missing or conflicting ownership fails before the transaction begins.
Batch the dominant rows
Fewer crossings into SQLite.
Symbols, identifier terms, and relationships use fixed-shape multi-row statements while preserving order, replacement behavior, row identities, and rollback.
Keep the safe foundation
No durability theatre.
Scout retains one SQLite writer, WAL readers, normal synchronization, the existing transaction boundary, FTS5, and atomic publication. No data is sampled or omitted.
The fastest candidate did not automatically win
A 1,000-row batch was faster. It still failed the gate.
The first large symbol batch preserved correctness and delivered the speedup, but the locked Linux device campaign measured 2.14% more NVMe bytes written—over the predefined 1% budget. That candidate was not promoted and the budget was not relaxed after seeing the result.
Revise
1,000 rows
Large speed gain, exact results, but +2.14% direct-device write bytes on Linux. The implementation stayed unpromoted.
Promote
256 rows
Retained the large readiness gain while Linux NVMe bytes moved only +0.15% and Firefox NVMe bytes fell 2.50%. This is the production default.
Lower-volume tables were also left alone after attribution showed they consumed less than 0.3 seconds in a 391-second diagnostic run. Higher-risk transaction regrouping and FTS redesign were not started: the measured target had already been reached without changing those boundaries.
Same facts · same search · same recovery model
“Faster” was not accepted until “identical” was mechanically proved.
The reference and optimized writers were fed the same prepared records, then compared through deterministic logical digests that resolve internal row IDs back to stable symbol identities. Ordinary tables and FTS5 search contents were checked independently.
- Every final selected-source run passed
quick_check; the first pair on each corpus also passed fullintegrity_checkand exact digest equality. - Normalized MCP response streams were byte-identical after removing only one explicitly nondeterministic scan-timing field.
- Fault injection, rollback, cancellation, concurrent-reader, duplicate, FTS update, no-change, and one-file incremental behavior remained covered.
- A changed one-file Ollama update moved from 817.5ms to 821.0ms (+0.43%), inside the predefined 2% budget; it replaced the same file and two symbols.
The release is faster because it uses available compute differently
The costs remain beside the wins.
CPU utilization
More CPU while the job is active.
Median process CPU rose from 206.35% to 348.56% on Linux and from 188.67% to 316.06% on Firefox. The job occupies more available cores for much less wall time.
Peak memory
Small increases, within budget.
Peak RSS rose 1.51% on Linux and 0.51% on Firefox. Both remain below the predefined 5% ceiling; no memory improvement is claimed for this release.
Tiny updates
Batching has a small fixed cost.
The two-symbol statement itself became slower in the incremental fixture, even though whole-update time changed only +0.43% and database-write time improved by 1ms.
Firefox device counter
One I/O metric moved the wrong way.
Accumulated NVMe write time rose 13.95% even as bytes, operations, flushes, and end-to-end duration fell. It was not a release gate, but it is not hidden.
These are medians from one documented host, two frozen repositories, and three runs per arm. They demonstrate the scoped writer improvement under those conditions, not a universal percentage for every repository or machine.
Signed release · four native targets · independently verified
The measured work and the public release are bound to exact identities.
- Signed tag
v1.0.0-preview.24- Release commit
ff23b3e52fd19b2c23ff8c94c9986dfc1e6f0d07- Release manifest SHA-256
493fd64433f03513a552802f87ec03d8eb45be50b4fe512e3995dbbaa88056ee- Selected writer binary SHA-256
fd01a3c93e432f9f2da8d1426dbb178f08c4e838cae68f8bdedb3d853fae1b83- Frozen Linux commit
248951ddc14de84de3910f9b13f51491a8cd91df- Frozen Firefox commit
f4e6e71e9c4deb3818880f2c8a22de09a92955ce
All four native packages passed tests, release builds, offline smoke tests, SBOM generation, Sigstore provenance, OpenPGP certification, private staging, production promotion, and public verification. All 24 public versioned objects were independently downloaded and matched for size and SHA-256. The stable channel remains untouched.
Preview 24 is the current public preview
Upgrade the complete managed installation.
The native updater verifies the signed release contract, stages the complete runtime and integration payload, and atomically moves the managed installation to Preview 24.
atlas-scout upgrade --check
atlas-scout upgrade