Uteke: A Local-First Memory Engine That Actually Runs Anywhere

You just spent two hours explaining your codebase to ChatGPT. Architecture decisions. Why the auth layer looks the way it does. The trade-offs you made six months ago. Next session? Blank slate. You're re-explaining the same context to a model that forgot everything.

This is the memory problem. Every developer working with AI hits it. Your AI assistant doesn't remember yesterday's decisions, last week's debugging session, or the architectural rationale buried in Slack threads. Every conversation starts from zero.

What Memory Should Look Like

Persistent memory changes the equation. Your AI remembers that you chose Postgres over MongoDB and why. It recalls the API contract you settled on three sprints ago. It knows your team's coding conventions because someone stored them once, not because you pasted them into a prompt again.

That's not a feature. It's infrastructure. The question is whether it needs to live in someone else's cloud to work.

Enter Uteke

Uteke is a memory engine built in Rust. It runs as a single binary on your machine. No Python runtime. No Docker container required (though Docker is optional if you want it). No API keys to provision. No cloud account to create.

You install it. You store memories. Your AI retrieves them in ~45ms. That's the whole loop.

The project launched May 29, 2026, 58 days ago at time of writing. It's at v0.10.1 with 40+ releases, 148 GitHub stars, and 16 forks. Apache 2.0 licensed. Thirteen open issues, which means active development, not abandonment.

How It Works

Uteke uses hybrid search. That word gets thrown around loosely, so here's what it actually means here.

When you store a memory, Uteke does two things in parallel. First, it generates an embedding vector using a local model: no API call to OpenAI, no network round-trip. Second, it indexes the text in SQLite FTS5 for full-text keyword matching.

At query time, both indexes fire simultaneously. The vector search catches semantic matches (you asked about "authentication" and finds a memory about "login flow"). The FTS5 search catches exact keyword hits. Then Reciprocal Rank Fusion (RRF) merges both result sets into a single ranked list.

The embedding model downloads on first run, about 188MB, one-time. After that, everything stays local. Your data lives at ~/.codecora/uteke/ and never leaves your machine.

Quick Start

Three install options. Pick one.

# fastest
curl -sSL codecora.dev/install | sh

# homebrew
brew install codecoradev/tap/uteke

# from source
cargo install uteke-cli

First run drops the embedding model (~188MB) and initializes your local store. Then:

# store something
uteke remember "Chose Postgres over MongoDB for transactional consistency"

# recall it later
uteke recall "database decision"

# search across all memories
uteke search "auth architecture"

There's also an onboarding wizard. Run uteke onboard and Uteke detects what you have installed, configures agent integration, and gets you to a working state without manual config file editing.

Local-First, Not Local-Only

Uteke exposes an MCP server over JSON-RPC and HTTP. That means Claude, Cursor, or any MCP-compatible agent can query your memory store directly. The AI assistant you're already using gets persistent memory without you changing your workflow.

The difference from cloud-based alternatives comes down to this: your data never leaves your machine. Mem0 runs in the cloud. Letta requires an LLM API. Zep needs Neo4j running somewhere. Mnemosyne is Python-based with ~1.5K stars. Engram does FTS5-only search in Go.

Uteke's edge: single binary, no runtime dependencies, zero API keys, plus rooms, time-travel queries, and hybrid search in one tool.

Rooms and Time-Travel

Two things deserve specific mention because they're genuinely uncommon.

Rooms are built-in multi-agent collaboration. Multiple agents (your coding assistant, your research agent, your teammate's agent) share a memory room. One agent stores a decision; another retrieves it. No message bus to configure, no external coordination service.

Time-travel gives you native point-in-time queries. You can ask what the memory store looked like last Tuesday before that refactoring session. Or what decisions were on the table before the team pivoted. This isn't version history on files: it's queryable temporal state on your entire memory graph.

Why Local-First Matters

Privacy is the obvious answer. Your architectural decisions, your debugging notes, your team's internal context, that's sensitive material. Shipping it to a third-party API for embedding generation creates a data surface you may not want.

Speed is the second answer. A 45ms recall beats a 200ms network round-trip to a cloud API every time. For agentic workflows that query memory multiple times per turn, that gap compounds.

Cost is the third. Zero API calls means zero per-query charges. Run a thousand recalls or a million, the bill doesn't change.

What's Next

Uteke is 58 days old and shipping fast. If you're still pasting context into prompts every session, the 45ms recall will change how you think about agent memory.

curl -sSL codecora.dev/install | sh

See what your AI assistant looks like when it actually remembers you.