Switching between AI coding agents is chaos. ELVES gives them a shared workspace, shared memory, and a single place to ship from. Works with Claude Code & Codex!
Been hacking on this for a bit and figured I'd share since it scratches a specific itch I kept running into with Claude Code/Codex.
Every session starts cold. Skills and MCP configs are just dotfiles you edit by hand. Running multiple agents means they stomp on each other. And I had zero visibility into which projects were eating my tokens. So we built ELVES to fix that.
Here's what it actually does:
You can browse, edit, and install skills from a UI instead of hand-editing markdown. Same for MCP servers — toggle them on/off instead of messing with JSON. Each task spins up in its own git worktree with an embedded terminal, so you can run multiple agents without conflicts. There's a file explorer with a split view so you can watch the agent work alongside your code. A SQLite-backed memory layer persists context across sessions with relevance decay so old stuff fades out naturally. And it parses the telemetry Claude Code already writes to ~/.claude/ into actual readable dashboards — token usage by model, cache hit rates, session timelines, activity heatmaps, that kind of thing.
Everything is local. No cloud, no accounts. Spawns a real CLI in a PTY, nothing proprietary. Also supports Codex. MIT licensed, free to use.
One heads up — the app isn't notarized by Apple yet, so after installing you'll need to go to System Settings → Privacy & Security → Open Anyway.
Still early and rough around the edges. Give it a try and let me know what you think — feedback, feature requests, and issues are all welcome on GitHub.
Report
the SQLite memory layer with relevance decay is the right architecture. project context that fades naturally is much better than stale context that poisons the agent. the gap i keep seeing is the layer above - who the developer is doesn't persist anywhere either. working on that with northr identity. same problem, different stack.
@ivo_gospodinov Really appreciate you picking up on that, yes the decay mechanism was one of those design decisions we debated a lot. Stale context is genuinely worse than no context in most cases.
The developer identity layer is a fascinating dimension we haven't fully tackled yet. Right now ELVES persists what was worked on, but you're right that who is working and their preferences/patterns is a separate unsolved problem. Would love to see what northr is doing there as the two layers feel complementary. Checking it out!
Replies
ELVES
the SQLite memory layer with relevance decay is the right architecture. project context that fades naturally is much better than stale context that poisons the agent. the gap i keep seeing is the layer above - who the developer is doesn't persist anywhere either. working on that with northr identity. same problem, different stack.
ELVES
@ivo_gospodinov Really appreciate you picking up on that, yes the decay mechanism was one of those design decisions we debated a lot. Stale context is genuinely worse than no context in most cases.
The developer identity layer is a fascinating dimension we haven't fully tackled yet. Right now ELVES persists what was worked on, but you're right that who is working and their preferences/patterns is a separate unsolved problem. Would love to see what northr is doing there as the two layers feel complementary. Checking it out!