OpenWolf

OpenWolf keeps a coding project’s working memory in a folder called .wolf beside the code and connects it to the agents a developer already runs. It installs lifecycle hooks for Claude Code and Codex CLI and a native plugin for OpenCode, so a session opens with a short project index and whatever saved task evidence is still relevant, an indexed file comes with a description and line ranges before it is read, and an edit refreshes the entry it touched. The folder holds the task checkpoint, the file index, project notes, candidate conventions, a bug log, handover packets between agents, archives of older notes with restore pointers, and a token ledger. The documentation states that memory, indexing and usage processing run locally without extra model calls, and that the only network traffic is an optional worker that checks npm for a compatible runtime. Usage figures are the counters the agents themselves wrote, grouped by agent and model, with missing counters left unavailable.

Who built itThe account that owns the repository holds 78 of its 123 commits, and 72 of those come from one address under two spellings of a name — Farhan Palathinkal Afsal on 55 commits and Farhan on 17. Eleven more commits arrive from cytostack@192.168.1.11, an address with no linked GitHub account at all, and a second account, doctorfarhan, holds 21. Fourteen people appear in the contributor list; apart from those two accounts and meketreve on 2 commits, the other eleven names account for one commit each.

1. 01

   Twelve releases, none of them in the first four months

   The repository was created on 2026-03-15, and its 123 commits are piled into the back half: 21 in March, 4 in April, 5 in May, 2 in June, 40 in July, 39 in August and 12 in September, the last at 2026-09-15T16:00:52Z, a documentation commit that marks version 2.5.2 as published. The twelve releases tell the same story from the other end: the oldest is v2.0.0 on 2026-07-14T22:54:31Z, twenty-five minutes before v2.0.1, and no 1.x release exists on the repository at all, even though three separate reports are filed against version 1.0.4 by users who then upgraded to 2.5.2. Eight of the twelve landed in August 2026 — two on 2026-08-19 forty-four minutes apart, four on 2026-08-20 inside three hours, two more on 2026-08-29 — and the order of that last pair is worth keeping: v2.5.1 was published at 20:45:43Z, v2.5.0 seven minutes later at 20:52:06Z. Each release has a matching tag, and none is marked as a prerelease or a draft. Around the version line sit 2,369 stars, 215 forks, 11 watchers and 60 open issues; fourteen people appear in the contributor list, and 112 of the 123 commits have a linked GitHub account. Forty-five commits carry a co-author trailer, and 37 of those name Claude Fable 5, with Opus 5, Opus 4.7 and Opus 4.8 accounting for five more.

2. 02

   The memory is a folder of plain files, with a lock around every writer

   What gets installed is a directory, not a service. docs/how-it-works.md lists what lives inside .wolf/ — the project index and its readable anatomy.md, memory.md, STATUS.md, cerebrum.md, buglog.json, handoff/ for checkpoints and packets, archive/ for older notes with restore pointers, token-ledger.json and hooks/ — and splits it in two: “Project notes can be shared through version control after review. Local usage, runtime and session data follow the generated ignore rules.” The line that shapes the feature set is drawn in the same document: “A checkpoint records task state separately from the full conversation”, so the file is not a transcript, and the agent is told it “still needs to save useful semantic summaries”, because “OpenWolf cannot infer every decision from a file edit”. Loading is meant to be incremental — “OpenWolf can return changed context without repeatedly loading every old note” — and what comes back is untrusted by default: “Saved evidence is marked as untrusted context. Durable instructions are loaded automatically only when the independent protected-memory verifier approves them”, which is what src/hooks/trusted-memory.ts (3,516 bytes) and the plugin copy of it are for. Concurrent writers get locks and event records, and the document is careful about what that buys: “These controls reduce lost updates; they do not replace a backup.”

3. 03

   The token ledger reads the agents’ own counters, and says so

   Measurement here is a reader rather than a meter. docs/how-it-works.md says the tool “reads available provider counters from Claude transcripts, Codex rollouts and OpenCode plugin records”, that it “reconciles repeated records and reports coverage by agent”, and that “Missing counters remain unavailable” — nothing is extrapolated to fill a gap. The rules are in the same place: “Input totals include cached input. Output includes reasoning where reported. Pricing separates the relevant input categories and uses each recorded provider and model.” The status of the resulting figure is spelled out rather than left to the reader: “The result is an API list-price estimate with stated assumptions, not a subscription invoice or a measurement of remaining quota.” Two other kinds of number are kept apart from it on purpose — the README describes token-ledger.json as “Operational records and separate content-size estimates”, and the Bash output governor’s arithmetic is called local, because “Local output-size calculations remain estimates, separate from provider token counters”. The code matches that split: src/tracker/ is nine files and 48 KB, with usage.ts 14,966 bytes, pricing.ts 11,420 (the same file is copied into the dashboard at the same size), cache-attribution.ts 6,200, transcript-usage.ts 6,077 and a token-estimator.ts of 776 bytes.

4. 04

   What the ledgers actually recorded, and on what basis

   Every usage number here comes from a user’s own ledger, with its basis. Issue #118 measured a single reinjection of three rule reminders at 4,392 and 3,030 tokens across two sessions in token-ledger.json, against a configured session-digest budget of 1,500 — several times the budget it sat beside, quoted from its own ledger. Issue #126 puts the evidence block injected on every prompt at “~400–700 tokens each” and multiplies that into “~30k tokens” for a 60-prompt session; the first is his measurement, the second his arithmetic, and neither comes from the project. Issue #131 counted 1,221 session entries for 110 distinct session ids, up to 65 copies of one session, in one project used for about five months, and traced it to a Stop hook that fires every turn but records each one as the session’s end. Issue #114 reports anatomy hits and misses of 5/32 (14%) on one project, where 43 of 113 misses were reads that could never have been indexed. No saving percentage appears anywhere in the material: the README excerpt stops short of any results, and the A/B harness that would produce them sits in the tree unnumbered, scripts/benchmark/run-ab.mjs (5,926 bytes) driving six task files. Pull request #115 reports 60 concurrent post-read hooks keeping 6 of 60 reads before its locking work and 60 after, measured “on real multi-process runs”.

5. 05

   One hook runtime, plus a second copy of it for the host without hooks

   The integration list in the README is itself the design: “Hooks: Claude Code, Codex CLI · Plugin: OpenCode · Compatible hooks: Grok Build · Context only: Cursor, Gemini CLI, Antigravity” — two hosts that call external hooks, one that loads a plugin, one reached through Claude-compatible discovery, three with only a rules file. src/agents/ is ten small adapters for that spread, codex.ts at 6,838 bytes down to grok.ts at 490. OpenCode cannot call the hooks, so it gets the runtime as a plugin, and the runtime is checked in twice: src/templates/opencode-plugin/ holds 25 files, its shared.ts is 48,050 bytes — the same size as src/hooks/shared.ts — kept aligned by scripts/sync-plugin-runtime.mjs (622 bytes). Pull request #113 split OpenCode’s state file per valid session id and collected session files older than seven days; the maintainer adopted the collection directly: “Splitting state per session without it would have grown the directory without bound.” The issues record what it costs: #129 reports that OpenCode V2 replaced its plugin API while the installed plugin still exports the V1 shape, and #130 that on Windows the SessionStart hook can exceed the five-second timeout configured for Claude Code and Codex alike. #122 and #127 extend the same runtime rather than adding another, the second by reusing .wolf/hooks/ and reporting 327 tests passing.

6. 06

   Sixteen reports, one pull request, and the disagreement left on the record

   The busiest stretch of the project is one contributor’s bug reports. Pull request #115, “2.5.1: multi-writer safety, project boundaries, and honest results”, closes the sixteen defects filed as #78 through #93 — “Fifteen were found and reported by @davdittrich, one by @krsfer, each with a reproduction” — and the same reporter had opened a fix for every one of them (#94, #98 through #103, #105 through #113), all still open. The maintainer says which came first: “Those PRs came first and should be weighed against this branch before merging either.” Two were adopted wholesale and named — the descriptor leak on read failure from #103 and the session-file collection from #113 — and #103 got a sentence changelogs rarely carry: “The version that shipped had the same leak until I read yours.” The verification claim is 271 tests passing, each new test first run against the unfixed code and observed to fail there. Where the two disagreed it is written down: #106 restricted daemon control to the PM2 process name, and the reply explains that 2.5.1 uses a .wolf/daemon.pid ownership record so a daemon started by openwolf dashboard can be stopped too. Later rounds: #118’s rule cap “was adapted in the 2.5.2 branch and is covered by tests”, #104’s work on sessions sharing one .wolf went in except for extra_roots, and #121’s corrected dashboard warning “has not been applied yet.”