Dirge: A Rust Coding Agent That Remembers Across Sessions

The problem dirge is built around: agents that forget

Most coding agents start each session with nothing. The README puts it directly: agents are like mayflies, awoken for a moment to work and to forget, with every new session effacing the old one. That framing drives the whole design. Dirge keeps a persistent per-project memory plus a global cross-project tier for durable user preferences, and a post-session orchestrator that extracts learnings and curates memory and skills after the session ends. The stated goal is carrying past mistakes and preferences across the gulf between sessions. The audience is engineers who run the same agent against the same repository repeatedly, where re-explaining the build layout, the test command, or a known pitfall every time is the actual cost. It is not aimed at one-shot code generation.

A bounded context window with memory living outside it

Dirge budgets working context to 250k tokens by default through the context_target config key. The compaction decision treats the effective window as min(model_window, context_target), so a 128k model stays at 128k while a model advertising a 1M window is held to 250k instead of folding on a fraction of its full capacity. The README justifies the number: context quality degrades gradually past 100k rather than falling off a cliff, and models diverge a lot in that range, citing RULER and Chroma's context-rot work. The trade-off is explicit. A bounded live window normally means forgetting older work, and dirge avoids that by writing a resumable checkpoint when history folds and forming project memory as facts and pitfalls persisted in the session DB rather than the transcript. Memory is two-tiered: salient entries stay inline, the rest demote. The design decision here is that retrieval quality depends on what the orchestrator chose to keep, not on a similarity score. If the extraction is bad, the bounded window becomes a real amnesia problem, and the README does not describe how extraction quality is measured.

No vector index, and the argument for that choice

Dirge ships no embeddings. Code search is plain grep delivered inline, and cross-session memory search uses SQLite FTS5. The README cites a study (Sen et al., 2026, arXiv 2605.15184) reporting that inline grep beat vector retrieval for every harness and model pair tested on long-term conversational memory QA, and that moving the same model between agent stacks shifted accuracy by roughly 16 points. The README's own caveat is that the study covers conversational memory, not code semantics, and for structural code questions dirge uses tree-sitter semantic tools and LSP diagnostics instead. That caveat matters. The empirical support is for the memory-search path, not for code search, where the choice of grep is defended more by simplicity and by the claim that inline lexical search is the most forgiving combination for weaker models. If your codebase has heavy generated code or non-obvious naming, grep returns noise, and dirge has no fallback ranking to filter it.

One policy decision point and the /why trace

All authorization flows through a single Policy Decision Point with four modes, op-based rules, session allowlists, and a /why command that reports which policy decided and why. This is the part of the design most likely to matter in a team setting, because it makes permission behaviour inspectable rather than emergent from tool code. The README points to docs/permissions.md for the details, and I have not read that file, so the exact rule syntax and the four mode names are not something I can state. What is clear from the README is the architectural commitment: one PDP, not per-tool checks. The cost of that commitment is that any tool whose access pattern does not map cleanly onto op-based rules needs either a broader rule than you would like or a change to the engine. That is a real constraint for plugin authors, since Janet plugins hook the full lifecycle and would need their operations expressed in the same policy vocabulary.

Getting it running: the commands the README names

The README gives a small set of concrete entry points. Run dirge mcp to expose dirge as an MCP server, which lets a planner agent such as Claude Code hand implementation tasks to dirge on a persistent per-project session and then review the summary and changed files it returns. Autonomous runs can be held to a natural-language stop condition with the --goal flag. Inside a session, /agent switches between named agent profiles, each a model plus prompt plus tool-policy bundle, and /issues views the built-in kanban that the harness surfaces at the start of every turn so the agent works its backlog without polling an external tracker. /why traces a permission decision. On the config side, context_target controls the context budget, and a per-provider multimodal override exists for local vision models. Images are pasted with Ctrl+V and stored out-of-line, re-read at the provider boundary, so transcripts stay small. The README does not show an install command, a cargo invocation, or a config file path, so the first thing to check in the repository is how the binary is distributed and where the config file is expected to live.

Where dirge is the wrong tool

Two cases stand out. First, semantic code search. If your workflow depends on finding code by meaning rather than by literal token, dirge's grep-only code path will underperform, and the README's own caveat concedes the cited study does not cover code semantics. Tree-sitter and LSP answer structural questions, not fuzzy ones. Second, the plugin surface. The Janet plugin system hooks the full lifecycle, but Janet is a small language with a narrow ecosystem compared to Python or TypeScript, and the README does not claim a library of existing plugins. If you need to reuse a large body of third-party extensions, dirge is starting from near zero. There is also a scale question the README does not address: the per-project memory and session DB grow over time, and nothing in the supplied material describes pruning, size limits, or what happens when the memory tier fills with stale facts.

How this differs from Claude Code or opencode

Dirge names pi, opencode, and maki as inspirations. The clearest contrast is with the JS-based agents the README benchmarks against on memory: roughly 8 MB RAM idle, 15 MB working, and a 36 MB binary on a Linux release build with opt-level=3 and LTO, versus around 300 MB for JS-based agents. Those are the project's own approximate figures, not independently verified here. The more substantive difference is architectural. Dirge routes roles separately, so the main loop, review, escalation, summarization, and subagent roles can point at different models, mixing Cerebras, DeepSeek, GLM, Anthropic, OpenAI, Ollama, and any OpenAI-compatible endpoint in one session. It also exposes itself as an MCP server so a planner agent can delegate implementation to it, which inverts the usual relationship where the coding agent is the top-level process. If you already have a planner you trust, dirge can sit underneath it rather than replace it.

Maintenance, licensing, and what to check first

The repository is not archived and releases are frequent, with v0.25.5, v0.25.4, and v0.25.3 landing within roughly two weeks of each other in the supplied data. That cadence means upgrade cost is a real line item: config keys and plugin lifecycle hooks can move between minor versions at this rate, so pinning a version and reading the release notes before bumping is the practical approach. The licence is GPL-3.0. That is a copyleft licence, and it is worth understanding how it interacts with your distribution model before you build dirge into anything you ship; I am not giving legal advice, and the specifics depend on whether you distribute the binary, modify it, or only run it internally. The default branch is main and there is no homepage, so documentation lives in the docs/ directory referenced throughout the README. The first files to read are docs/config.md for context_target and the config file location, docs/permissions.md for the four modes and rule syntax, and docs/plugins.md for the Janet lifecycle hooks. Those three determine whether dirge fits your setup; the memory and issue-board features are the parts you can evaluate later, once the session DB has real content in it.

Editorial conclusion

Dirge is aimed at engineers running long, multi-session coding tasks, particularly with cheaper or weaker models that need a harness to keep them on the rails, and at teams that want permission decisions traceable through one policy engine rather than scattered across tool implementations. It is the wrong tool if you need semantic code search over embeddings, if you want a mature plugin ecosystem with third-party packages, or if GPL-3.0 does not fit your distribution model. Before adopting, verify three things: whether the Janet plugin lifecycle hooks cover the extension points you actually need, whether the default context_target of 250000 suits your model's effective window, and whether the two-tier memory produces useful entries on your codebase rather than noise. Run dirge mcp against a throwaway project first and inspect what the post-session orchestrator writes into the session DB.

Official sources

1. dirge-code/dirge on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases