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.