It's release time again.

Three weeks ago, the May round-up caught the whole stack up in one post. Since then the two most user-facing tools each shipped a new minor — Octocode 0.16.0 and Octobrain 0.8.0, both cut June 7 — on top of Octolib's climb from 0.21.5 to 0.23.0.

There's one thread running through all of it, and it's worth saying up front: this round is about not having to configure anything. Octolib 0.23.0 grew a shared way to look at a Git checkout and derive a stable project ID. Octocode 0.16.0 now delegates its project identification straight to that; Octobrain 0.8.0 picked up automatic project discovery in the same move. The result is that the two tools you actually point at a codebase just work the moment you start them, in any repo, with no project ID to set by hand.

Let's start where it matters most.

Octocode 0.16.0 — one server, every repo, now with Swift

github.com/muvon/octocode · 0.15.0 → 0.16.0 · June 7

0.15.0 was the local-first release — no API key required, hybrid search and reranking on by default. That was about making a single index good out of the box. 0.16.0 is about what happens when you have more than one codebase to search.

Multi-repository server mode — replacing mcp-proxy. The big one. It's a breaking change, but it's worth the upgrade. Until now, serving several repositories through one assistant meant running an mcp-proxy in front of a fleet of single-repo Octocode instances — more moving parts, more to keep alive, more to explain. 0.16.0 deletes that layer. One Octocode MCP server now speaks multi-repository natively. You connect once, and your agent can search across the codebases you've indexed instead of being boxed into a single project per connection.

Heads up: removing mcp-proxy is the only item in 0.16.0's breaking-changes list. If your setup launches Octocode through the proxy today, that's the part you'll need to change on upgrade.

Zero-config project identification. Octocode no longer carries its own logic for figuring out which project a directory belongs to — it delegates that to Octolib, which derives a stable identity from the Git remote (more on why that matters below). The payoff: it's the same identity Octobrain and the rest of the stack now derive, so memory and code search agree on what "this project" means without you wiring anything up.

Swift, end to end. 0.16.0 adds Swift to both the indexer and the structural grep. If you're working in an iOS or macOS codebase — and we have several of those now, between Vext, Timex, and TypeTab — Swift symbols are first-class for semantic search and pattern matching, not just plain text.

Custom config path via an env var. You can now point Octocode at a config file with an environment variable instead of relying on a fixed location. Small change, big quality-of-life win for CI jobs and machines juggling several projects with different settings.

Security hardening under the hood. Two changes you won't see but should know about: Git URL credentials are now stripped during normalization, so a remote with an embedded token never ends up written into a stored project URL; and the storage layer centralizes its table names and hardens its SQL queries.

cargo install octocode --version 0.16.0
# or grab a binary at https://github.com/muvon/octocode/releases

Octobrain 0.8.0 — memory that configures itself

github.com/muvon/octobrain · 0.7.0 → 0.8.0 · June 7

0.7.0 was the loud one — sleep consolidation, half-life decay, goal-anchored memory, HyDE recall on by default. That release was about what your AI's memory does on its own. 0.8.0 is about removing the last thing you still had to do by hand: tell it which project it's in.

Automatic project discovery and ID derivation. The headline in 0.8.0, and the other half of the thread. Octobrain now discovers the project and derives its ID automatically — and under the hood it swapped its own git utilities for Octolib's (the release bumps to Octolib 0.23.0), so the identity it derives is the same one Octocode derives. Start Octobrain inside a repo and its memory binds to that project on its own: no project parameter to pass, no ID to copy between tools, and no risk of your code search and your memory pointing at different projects. Memory that was already self-maintaining is now self-configuring too.

Custom config path via an env var. Same ergonomics win as Octocode, by design — both tools picked up the same capability this round so they behave identically across CI and multi-project machines.

A leaner MCP surface. 0.7.0 narrowed the toolset from 8 tools to 5. 0.8.0 tunes what's left: tool listing and the memory provider are optimized, and project and role locking are now decoupled — so two roles working the same project, or one role across projects, stop contending on a single lock.

The 0.8.0 notes list no breaking changes, so it's a clean upgrade from 0.7.0 — and in practice you get to stop passing the project ID, because Octobrain now works it out for itself.

cargo install octobrain --version 0.8.0
# or grab a binary at https://github.com/muvon/octobrain/releases

Octolib 0.21.5 → 0.23.0 — the plumbing that made the above possible

github.com/muvon/octolib · 0.21.5 → 0.23.0

A few important remarks, because this is the layer doing the quiet work. Octolib is the engine behind every LLM call we make, and lately it's also become the place where shared, non-LLM utilities live so the tools above don't each reinvent them.

  • Git repo detection and project ID derivation (0.23.0). The piece Octocode 0.16.0 delegates to, and that Octobrain 0.8.0 moved onto in the same release. Put the logic for "is this a Git repo, what's its canonical remote, what's a stable ID for it" in one place, and every tool that depends on Octolib gets the same answer. That's the entire reason zero-config project identity is consistent across the stack instead of three tools each being slightly wrong in their own way.
  • Response schema enforcement (0.23.0). Octolib can now check that a model's output matches an expected response schema — useful anywhere you're parsing structured output back out of an LLM.
  • Claude Opus 4.8 support (0.21.7). The newest Opus is wired in, alongside OctoHub structured output and finish-reason support so callers can tell why a generation stopped, not just that it did.
  • Minimax M3 and M3-highspeed (0.21.8). Two more models in the roster.
  • Parallel tool handling and connection timeouts (0.22.0). Better handling of parallel tool calls and a connection timeout on the HTTP client, with request handling unified behind a single send_and_read path — fewer ways for a slow or wedged endpoint to stall an agent.
  • Token-accounting fixes (0.21.6). Cached tokens are no longer double-counted, and compression summaries no longer block conversation history. If your cost numbers looked slightly high on long cached sessions, this is why — and it's fixed.

If you build anything that calls LLMs from Rust, this is still the layer to standardize on: every provider Octolib already speaks, behind one trait, with the same retry logic and the same cost accounting.

And Octofs? Holding at 0.4.3 — on purpose

github.com/muvon/octofs · 0.4.3 · unchanged

Octofs shipped 0.4.3 in the May round-up — regex search, parallel file walking, and a delete command — and hasn't needed a release since. That's not neglect; it's the point. The filesystem layer is the one piece of the stack you want boring and predictable, and right now it is. When the runtime above it changes how it touches files, Octofs will move again. Until then, 0.4.3 is doing its job.

Octomind 0.30.0 — shipped separately

The runtime that ties this stack together, Octomind, also shipped 0.30.0 on June 3 — portable workflow files, project-local guardrails, and session observability. It got its own write-up, so we'll just point you there: the Octomind 0.30.0 release notes on octomind.run.

How they fit together

The stack hasn't changed since last month. What changed is how little you have to think about it. Octolib 0.23.0 now derives project identity from Git once, and both Octocode 0.16.0 and Octobrain 0.8.0 read it. No proxy to run in front of Octocode anymore. No project ID to copy between configs. No risk that your code search and your memory disagree on which project they're talking about.

A year ago, wiring this together meant a proxy, a copied ID, and a hope the two agreed. That gap is closed now. Single binaries, Apache-2.0, all of them.

We've already started the next one. If something here unblocks a thing you've been wanting to build, open an issue — features requested in June tend to ship in July.

— Don