0.9.1-rc.1 preview targeted for this weekend

[DeusData]

We are targeting the first 0.9.1 release candidate for this weekend.

0.9.1-rc.1 will focus on two of codebase-memory-mcp's central promises: reducing token consumption and providing stable, efficient code intelligence across demanding agent workflows.

This release candidate targets several of the largest remaining gaps:

Lower-token tool output

A recent output regression caused some tools to return far more internal graph data than agents actually need. The release candidate introduces compact TOON output across the main query surface, removes unnecessary internal artifacts from default responses, adds strict output budgets, and keeps verbose JSON available when explicitly requested.

The objective is straightforward: agents should receive the evidence they need without spending context tokens on repeated keys, internal similarity data, or oversized source payloads.

Stable multi-session operation

We are also working on a new local CBM daemon for environments running multiple coding-agent sessions and subagents at the same time.

Instead of allowing every session to independently start indexing, watching, and memory-intensive work, the daemon coordinates compatible sessions, coalesces duplicate operations, applies memory and admission limits, and cancels session-owned work when that session disconnects.

The goal is stable CPU and memory behavior even when several agents or subagents are exploring the same repository concurrently. The daemon remains entirely local. It does not introduce cloud processing, telemetry, or an external service.

Experimental agent tiers

For clients that support custom agents or subagents, we are introducing three experimental evidence tiers:

• Scout for narrow, provisional discovery using only a few focused calls
• Verify for normal task-directed investigation
• Auditor for bounded, paginated, and more exhaustive verification

These profiles are intended to let smaller or lower-cost agents handle focused discovery without paying the token cost of a full audit, while still escalating to stronger verification when correctness requires it.

The integration work now covers more than 40 automatic or conditional coding-agent and client surfaces, although the exact behavior depends on what each client supports.

Why this is a preview

This release candidate deliberately includes significant changes to output contracts, process coordination, and agent behavior. We therefore plan to publish it as a preview release rather than immediately declaring it stable.

We want power users to test it with real multi-session and subagent workloads before the final 0.9.1 release. In particular, we want feedback on:

• token consumption in real coding sessions
• behavior with multiple simultaneous agents and subagents
• daemon lifecycle, CPU use, and memory use
• whether Scout, Verify, and Auditor are useful boundaries
• which tasks can safely use smaller or lower-cost agent tiers
• any remaining oversized or low-value tool responses

Ideas, measurements, design proposals, and focused contributions are very welcome. If you have experience operating several coding agents against one repository, or have concepts for reducing context usage further without weakening correctness, we would especially like to hear from you.

The message for 0.9.1 is clear: lower token consumption, stronger performance, and stable operation across real multi-agent workflows.

[DeusData]

0.9.1-rc.1 progress update

A quick update on the release candidate: the token-consumption work has already landed independently in main.

The current implementation is the shared prefix-grouped tree data model introduced in #1154. It replaced both the earlier TOON output and the legacy object-per-node emitters. Structural results store the shared qualified-name prefix and file path once per group; rows beneath carry only the short symbol name and ordered data cells. The default text response renders that model as a compact tree, while format:"json" serializes the same columns, rows, and groups as structured JSON instead of returning a separate verbose shape.

This removes repeated keys, file paths, and qualified-name prefixes without losing exact join keys for follow-up calls. The same merge added byte ceilings, semantic floors, and context-explosion guards so output growth becomes a test failure rather than a future regression. Measured against the v0.9.0 release binary, a 192-hit search_graph response dropped from about 246 KB to 2.9 KB, the default architecture response from about 51 KB to 3 KB, and a seven-file detect_changes result from about 77 KB to 13 KB while becoming a real transitive blast-radius analysis.

Power users who are comfortable building a development snapshot can already test this tree-based output from main and share measurements, comprehension issues, or regressions with us.

The new coordination daemon in #1139 is still work in progress and is taking longer than we initially expected. It is also the part we consider most important to get right before publishing the release candidate.

This is a substantially larger package than a normal feature. The daemon has to coordinate multiple MCP sessions and subagents without duplicating indexing work or burning memory and CPU, while also handling startup and shutdown, cancellation, crash recovery, local IPC identity, installation and update activation, filesystem permissions, and path behavior consistently across macOS, Linux, and Windows.

We are working on it very actively, and the core design and much of the implementation are in place, but we do not want to rush a coordination layer that appears stable on one platform and introduces lifecycle or safety problems on another. The daemon remains entirely local and does not add cloud processing, telemetry, or an external coordination service.

So the current status is:

• the prefix-grouped tree output and token-consumption improvements are landed in main and can be tested now
• the daemon remains the release-critical work item
• the preview release will follow once the cross-platform daemon lifecycle and safety checks are genuinely ready

The platform-agnostic daemon is a large and critical change. We would rather take the additional time now than ship a coordination layer that is difficult to trust in long-running, multi-session workflows. Thanks for your patience while we finish it properly.

[hetasshi]

Come on, guys, I’m waiting!! I’m waiting for your update!

[DeusData]

0.9.1-rc.1 status — we are past the date we gave, and I owe you an explanation

We said "this weekend" on 16 July. It is now the 26th. That date is missed, and I would rather explain exactly why than quietly re-target it again.

I also want to apologise for something with wider reach than the release slipping: this has been blocking almost everything else. Pull requests are sitting unreviewed, issues are waiting on first responses, and contributors have been waiting on me while two release-critical items consumed effectively all available capacity. That is a real cost to people who took the time to contribute, and it is on us, not on them.

Two things caused it. Both had to be done right rather than quickly.

1. The daemon was a much larger architectural shift than a feature

The coordination daemon (#1139) merged on 23 July at +90,029 / −3,477 across 192 files. That is not a feature landing; it is a change to how the whole system runs.

It had to coordinate multiple MCP sessions and subagents without duplicating indexing work, while handling startup and shutdown, cancellation, crash recovery, local IPC identity, install/update activation, filesystem permissions and path behaviour — consistently across macOS, Linux and Windows. A coordination layer that looks stable on one platform and quietly breaks lifecycle or safety guarantees on another is worse than no coordination layer, so it absorbed far more verification effort than the implementation itself.

#1252 is the follow-up hardening pass on that work: +6,060 / −302 across 53 files, covering safe agent-config repair, deterministic parallel test scheduling, full release-fixture smoke coverage, and Windows-specific safety work. No new daemon features — just making the release paths trustworthy.

2. We found the root cause of #581, and it was severe

While hardening the release we finally reproduced and root-caused the Windows memory leak in #581 — the one where the process climbed past 50 GB of commit charge over hours and took the whole machine down with it. That report has been open since 23 June, and every earlier attempt only moved the symptom.

Yesterday it resolved into two independent Windows-only defects, both now fixed on the #1252 branch:

Thread-heaps were never released. A static MinGW link has no DllMain and registers no TLS callback, so nothing ran at thread exit and every thread abandoned its mimalloc thread-heap for the life of the process. After 300 MCP requests the allocator reported 607 thread-heaps — peak equal to total equal to current, none ever released — holding 170.5 MiB against a live set of roughly 300 KiB, growing linearly and without bound. POSIX was unaffected because a pthread TSD destructor already did this, which is precisely why every POSIX soak stayed flat under an identical workload. Worse, those heaps were invisible to mi_heap_visit, which only walks the main and calling heaps — so the growth appeared to belong to no allocator at all, and survived every allocator setting we tried against it.

One OS thread per daemon connection. Each connection minted a fresh thread-heap, and mimalloc took new slices at its arena commit frontier for each one without ever walking back to the purged slices behind it. Windows commit charge and RSS therefore ratcheted upward for the entire life of the daemon. POSIX hid this too, because madvise drops purged pages from RSS regardless of where the frontier sits. The worker slots were already pooled and bounded; only the threads were not. They are now pooled and parked on a condition variable, keeping the set of thread-heaps constant.

Finding this needed new instrumentation, because the growth did not route through the allocator at all and so was invisible to allocator-level tools. We added phase marks that attribute OS committed-byte deltas to a labelled code path. Pointed at #581 they localised it in two steps: dispatch_tool held +102 MB across 27 requests while scope begin/end and idle stayed flat — which independently killed the theory that the growth was time-based — and splitting the handler put +88.4 MB in store resolution against +14.1 MB for the query body, with the matching release returning only −35.9 MB. A net ratchet of roughly 2 MB per request that never comes back. That single number explains the original 50 GB report, why it scaled with corpus size, why every tool appeared to leak identically, and why only Windows ever showed it.

Why this stopped everything else, and not just the release

A leak that ends in the operating system killing a user's machine is the most severe class of bug this project can ship. It has been affecting Windows users since at least v0.8.1. Once it became reproducible we were not going to cut a release candidate around it, and we were not going to paper over it with a workaround when the actual cause was finally in reach.

But severity alone is not the whole reason work halted. The real reason is how much of the system these two changes touch at once, and how deep they sit.

Between them they cross the memory allocator and its thread-heap lifecycle, process and thread lifecycle in the daemon, the store-resolution path that every single tool call runs through, IPC identity and filesystem permissions, and the install/update/release surface on three operating systems. Those are not independent areas that can be reviewed in parallel — they are layers stacked on each other, and the leak fix in particular lives underneath everything: it changes when memory is released across the entire process.

That has an unavoidable consequence for other work. Merging unrelated changes into a tree whose allocator behaviour, thread lifecycle and store-resolution path are all actively moving means neither change can be trusted afterwards. If a PR merged today and a Windows soak drifted next week, we would have no way to tell whether the cause was the contribution or one of the layers underneath it. Reviewing against a moving foundation produces reviews that have to be redone.

So the honest position is not "we were busy." It is that the change surface is currently wide enough and low-level enough that holding other merges is the responsible choice rather than a scheduling failure. Both pieces had to be done properly rather than quickly, and together they consumed effectively all of the capacity available right now.

I would rather say that plainly than let contributors keep guessing why their PR has been silent.

Where things stand

• Token-consumption work: landed in main (Tree-format tool output: prefix-grouped rows, exactly-once pagination, real change impact, cycle detection #1154, prefix-grouped tree output) and testable now
• Daemon: merged (feat: coordinate concurrent CBM sessions #1139)
• Release hardening + the two Memory leak: process grows to 50+ GB virtual memory over hours/days, crashes Windows #581 fixes: in review on fix: harden daemon release paths and verification #1252
• 0.9.1-rc.1: follows once fix: harden daemon release paths and verification #1252 is green and the Windows soak confirms a flat baseline over hours rather than minutes

I am deliberately not naming a new date. The last one did not survive contact with #581, and another missed date is worth less to you than an honest status.

To contributors specifically

If your PR or issue has been sitting: thank you for your patience, and sorry for the silence. I have just been through the backlog and left a real, code-grounded response on every open item that had never had one — several turned out to be already fixed on main, and a few turned out to have a different root cause than reported. Reviews resume in earnest once the release path is clear.

And to @baoyu0, who reported #581 back in June and patiently ran retests for us: thank you. You were right that the short-run RSS test proved nothing, and you were right to push for a real soak. The cause turned out to be in a place none of our allocator tooling could see.

[richardchen874-sys]

Compact TOON output plus strict output budgets is a very practical token-control move for codebase-memory tools.

I would separate raw usage collection from cost presentation: first normalize tokens and provider metadata per request, then let dashboards group by user, workflow, or model tier.

I am working through similar issues while testing an OpenAI-compatible layer for official Chinese models, mainly around routing, cost visibility, and response-shape compatibility. For codebase-memory-mcp, do you need billing-grade accuracy here, or is operational usage visibility enough for the first version?