Memdoor hit 308 points on Hacker News on October 31, 2026 with a provocative headline: five coordinated Qwen3.8-27B models beating Fable 5 on the first ten problems of LiveCodeBench Hard. But the interesting thing about the project isn't that benchmark — it's what it proposes: a coding and automation agent in a single Go binary, built to run without a window (in CI, on cron, over SSH) as much as in the terminal.
What it is
Memdoor is a static binary (macOS, Linux, Windows; Apache 2.0, ~136 stars) with no Docker and no Python. It starts a local gateway that keeps each run as a conversation: you begin it in the terminal, with memdoor run from a script, from a cron job, or from your editor over ACP, and you resume it from any of those with memdoor resume. BYOK: connect your OpenRouter, Anthropic, OpenAI, or Gemini key, or a local model (Ollama, llama.cpp, vLLM) with no key.
Two pieces set it apart from yet another wrapper around an LLM:
- A decision model in front of the chat model. A fast classifier answers questions like "is this search hit relevant to the task?" in under half a second, and the harness acts on it: file and log reads return only what counts, and a turn that stops making progress ends instead of looping to a cap. Across the 44 paired runs they publish, a question about the codebase went from 54,661 to 14,367 input tokens (−74%) while the result held.
- Workflows as files in your repo. You state the steps and the agent writes them as one YAML per step, which an engine runs as a graph: independent steps run in parallel, a step is done when its check passes (not because the model says so), a gate waits for your approval with the diff in front of you, and a failure resumes from the step that failed.
How it's used
Installation is the usual curl … | bash, which is worth reading before you run it; the installer verifies the SHA-256 of what it downloads. A windowless turn, with the exit code as the receipt of its checks:
memdoor run "fix the failing test" # 0 verified, 2 a failing check, 3 a question nobody answered
git diff | memdoor run "review this diff; one line per finding"In GitHub Actions it's a single step on your key, with nine built-in workflows (pr-review, security-review, write-tests, fix-tests, explain-failure…):
on: pull_request
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: guregodevo/memdoor-action@v1
with:
workflow: pr-review
openrouter-api-key: ${{ secrets.OPEN_ROUTER_API_KEY }}The README itself warns to always use pull_request and never pull_request_target, so a fork's code never runs beside your key.
What convinces me and what doesn't
I'm convinced by the headless-first stance: almost every tool of this kind starts as an interactive window and bolts a CI API on later; here the model is the gateway and the terminal is just one more door, which fits how an SRE wants to trigger repeatable work. The decision model in front of the LLM, with measured and reproducible savings, is the project's most serious part.
What I'd qualify: 136 stars and the push of one Hacker News thread aren't settled traction, and the benchmark headline — five open agents against Fable 5 over ten problems — is exactly the kind of eye-catching comparison to treat as the author's own experiment, not an established fact. Publishing all 50 runs is honest, but ten problems are ten problems.
Memdoor vs. the CI agents you already use
| Memdoor | Claude Code / Codex official Action | A managed agent (API) | |
|---|---|---|---|
| Deployment | One Go binary, no Docker or Python | Vendor Action on its runtime | Vendor's cloud service |
| Where it runs | Your machine, your CI, or a box over SSH | Your runner | Vendor infrastructure |
| Model | BYOK or local, several providers | The vendor's | The vendor's |
| Workflows | YAML in your repo, with checks and gates | Prompt + Action config | Defined by its API |
| Maturity | Very new (Oct 2026) | Established | Established |
If you already live in one vendor and its Action works for you, Memdoor doesn't add much. Where it fits is when you want an agent that runs the same on your laptop, on a box over SSH, and in CI, with your key or a local model, and the workflows versioned in the repo rather than tied to a service. For that, its newness is more a reason to try it in a scratch repo than to put it into production this week.