Uteke v0.10: 150 Stars, 40+ Releases, What is Next

Fifty-eight days ago, Uteke did not exist. The first commit landed on May 29, 2026. Today the project sits at v0.10.1 with 150 stars on GitHub, 16 forks, and over 40 releases shipped. This is a short reflection on what happened, what we learned, and where the project goes next.

The numbers

Here is where Uteke stands today:

• v0.10.1 is the current stable release
• 150 GitHub stars, 16 forks
• 40+ releases in 58 days
• Apache-2.0 licensed, written in Rust
• ~45ms average recall latency
• 188MB embedding model size
• ~4.5MB storage footprint at 10,000 memories
• Local-first, self-hosted by design

The storage number is the one that surprises people. A semantic memory engine that holds ten thousand memories in under five megabytes is not something we expected to ship this early. The embedding model is small enough to run on a laptop without thinking about it.

What happened in 58 days

Uteke started as an internal tool. We needed a way to give Hermes agents persistent memory without depending on external APIs or cloud vector databases. The first version was rough: a single binary, a SQLite backend, a basic embedding pipeline, and a REST API that exposed remember and recall endpoints.

Within the first week, we had room-based organization working. Rooms let you partition memories by project, agent, or context. An agent working on a codebase can keep its memories in one room while a research agent uses another, and they never cross-contaminate.

By the second week, the embedding pipeline was stable enough to benchmark. We landed on a 188MB model that delivers ~45ms recall on modest hardware. That became the default.

The release cadence was aggressive. Forty-plus releases in under two months means we shipped something new roughly every day and a half. Some of those were patch releases fixing edge cases in the recall pipeline. Others introduced real features: namespace support, tag-based filtering, consolidation tooling, an HTTP API compatible with agent frameworks, and a Homebrew tap for one-line installs.

You can install it right now:

brew install codecoradev/tap/uteke

Or pull the container and run it locally at http://uteke:8767.

What worked

Rust was the right call. The performance characteristics we needed, low memory, fast recall, predictable latency, all came naturally. The 188MB model footprint and 45ms recall speed would have been harder to hit in a higher-level language without more engineering effort.

SQLite as the default backend turned out well. No external database to install, no service to manage. You run the binary and it works. This made local-first genuinely local, not "local but you also need Postgres."

Room-based organization surprised us. It is the feature people gravitate to first. Memory partitioning sounds like an enterprise feature, but in practice it is how everyone naturally thinks about context. You do not want your coding agent's memories mixed with your research agent's memories. Rooms solve that cleanly.

Shipping fast meant we got feedback fast. Bugs in the recall pipeline, edge cases in tag filtering, and API ergonomics issues all surfaced within days, not months. The GitHub issue tracker became the primary driver of the roadmap.

What did not

The API went through three breaking changes. We did not version it early enough, and early adopters had to update their client code more than once. In hindsight, we should have slapped a v0 label on everything from day one and been more explicit about instability.

Documentation lagged behind releases. With a release every day and a half, the docs could not keep up. We shipped features that people discovered by reading the changelog rather than the docs. That is fine for early adopters but it limits broader adoption. The docs are caught up now, but it was a real gap for the first month.

No clustering or distributed mode. Uteke is single-node only. For local-first use, that is fine. But we have heard from several users who want to run Uteke as a shared memory service across multiple machines. That is not something v0.10 supports, and it is not a quick fix.

Consolidation is still manual. Uteke can detect semantically similar memories and suggest merges, but it does not do this automatically. In practice, the memory store grows and requires periodic cleanup. Automation here is harder than it looks because wrong merges destroy information, and we would rather be conservative than aggressive.

Community response

150 stars in 58 days is not viral, but it is honest growth. The people starring and forking the repo are the right people: developers building agent systems, researchers experimenting with persistent memory, and teams who want self-hosted alternatives to cloud vector databases.

The issue tracker has been the strongest signal. Real bug reports, real feature requests, real use cases. People are running Uteke in production for agent memory, RAG pipelines, and personal knowledge management. The feedback has been specific and technical, which is exactly what an early-stage project needs.

The 16 forks tell their own story. People are not just starring and moving on. They are reading the code, modifying it, and in some cases contributing back. That is the kind of engagement that matters more than star count.

What is next for v0.11 and beyond

The roadmap for the next cycle is shaped by what users have asked for:

• Automated consolidation. Conservative, opt-in, and reversible. We want Uteke to keep memory stores tidy without risking data loss.
• Backup and export. First-class export to standard formats so you are never locked in. Your memories are your data.
• Performance at scale. 10,000 memories at 4.5MB is good. 100,000 memories at a reasonable footprint is the next target.
• Multi-backend support. SQLite stays the default, but we want to support Postgres and pure file-based backends for users with different constraints.
• API stability. v0.11 will freeze the core API surface. No more breaking changes without a major version bump.
• Better observability. Recall latency breakdowns, memory store health metrics, and a simple dashboard for monitoring a running instance.

Uteke is still early. It is a v0.10 project that has been live for less than two months. The core is solid, the performance is real, and the community is engaged. But there is a lot left to build.

If you have been waiting for a local-first, self-hosted semantic memory engine that does not require a cloud account or a managed service, Uteke is ready for you to try. Install it, run it, break it, and tell us what you find.

brew install codecoradev/tap/uteke

The repo is on GitHub under codecoradev/uteke. Issues and pull requests welcome.