Gnosh: A Coding Agent That Plans and Remembers in Go Code Instead of Markdown

Gnosh is a new open-source terminal coding agent with an unusual idea: instead of keeping its plans and memory in markdown files or a vector database, the agent writes small Go programs and runs them. The project describes itself as "a coding agent that thinks, plans, and remembers in Gno," and it hit the Hacker News feed on October 30, 2026 as "Gnosh.ai, super intelligent AI that thinks, plans, recalls in Go". Its maker, posting as jaekwon, explained the motivation in the thread: harness engineering, they wrote, "is duplicating all the work already put into decades of programming language research," so they forked a Go harness and added a Go interpreter.

This post explains what Gnosh does, how its memory model compares with the approaches we have covered, how to install it, and what remains unproven.

TL;DR: Gnosh in one table

What problem is it trying to solve?

Coding agents forget. Most harnesses patch that with text files the agent reads at the start of a session, such as the pattern we describe in our explainers on CLAUDE.md as persistent memory and MEMORY.md for agent persistence. Others bolt on databases, like the SQLite and Chroma approach in claude-mem. Both lean on the model to rewrite free text correctly, which is where drift, duplicates and stale facts come from.

Gnosh's answer is to make memory a program. The agent changes state only through the realm's own methods, every change is journaled before it is kept, and a call that fails keeps nothing. A new session is seeded with the project's rules, what is due, what waits on you, open goals with their next step, and the newest facts. That is a transactional store with a typed interface instead of a notes file.

How does the mem realm work?

The site shows the calls exactly as the agent writes them:

You can also inspect it yourself with the slash commands /mem for the outline, /mem find to search, /mem log to list every change and /mem undo to take one back. That human-visible audit trail is a real advantage over opaque embeddings.

A goal that outlives the session

The site's example asks the agent to add a Median function to a stats package with tests, "done when go test passes". The agent plans three steps and makes the test run a step of its own. Per the site, a goal cannot be marked done while a step is open, so passing tests is something the agent has to reach rather than claim. When it closes the goal, a separate judge checks the claim against the conversation and reopens it if it does not hold. The next session, told only "Let's carry on with Median", reads mem, sees one of three steps done, and finishes the rest.

Facts that stay current

If you tell the agent the staging database is db-stg-7 and a week later that it moved to db-stg-9, the second call replaces the first under the same name, and the log shows what it was. A later session answers "which staging database?" with db-stg-9 without calling mem at all, because the newest facts are loaded into the first message. This addresses a known failure of append-only notes: contradictory old entries that the model has to reconcile.

Reminders and questions

The agent can leave a reminder for next time, such as rotating a staging API key before Friday, and the site is careful to note it is "a reminder for the next session, not an alarm". It can also turn that into a question for the user that blocks the goal until answered.

What does "thinks in Gno" mean?

The second use of the VM is calculation. Rather than adding numbers in its head, the agent writes a short program in a scratch machine. The site's example is an exponential backoff question: a client waits 200 ms, doubles each time, caps at 30 s, and you want the time of the 10th retry. The right answer is 111 seconds. According to the site, with Qwen thinking on, the agent used a machine and got 111 s in 5 runs of 5. With thinking turned off, it was right in 4 of 7 runs, and twice summed the waits mentally to 110.8 s.

Those figures are the author's own runs with a single open-weight model, not an independent benchmark, and the sample sizes are tiny. They illustrate the idea more than they prove it. The site says the runs and their pass rates are collected in a test set it calls GNOMEM. Machines are named, with memory caps, gas limits and optional persistence, in a worker process of their own.

What else changes in the fork?

Gnosh is not only a memory experiment. The site lists several hardening changes relative to Crush:

• Nothing phones home. No usage metrics, no provider catalog fetch, no update check, unless you turn them on.
• Tool text can't pose as the conversation. A model's control tokens found in a web page or command output are defused before the model reads them, a defense against one class of prompt injection.
• Mistakes fail closed. A misspelt guard stops Gnosh instead of being silently ignored.
• Claude Code compatibility. It speaks Claude Code's flags and hooks.
• gno.land awareness. Every signature waits for you to type the key's password, which the model never sees.

For readers worried about agents acting on untrusted content, our look at Bernstein's policy-as-code governance layer covers a different, complementary approach. If you want help watching what your agents do, AgentBeam is the agent security platform from the explainx.ai team.

How do I try it?

The site gives these steps. You need Go 1.27 or newer:

git clone https://github.com/gnosh-ai/gnosh
cd gnosh && go build -o gnosh .
mkdir -p ~/.local/bin
install -m 755 gnosh ~/.local/bin/gnosh

Then run gnosh in a project and press ctrl+l to choose a hosted model. For a model on your own machine, add a provider in ~/.config/gnosh/gnoshrc:

provider add local --type llamacpp --base-url "http://127.0.0.1:8080"
option request-timeout 900

The timeout matters because, as the site notes, a local model can take minutes to read a long prompt. The demo recording uses Qwen3.8 27B on a home AI box, with the waiting cut short. If you are new to running models locally, our Unsloth guide to a 2-bit MiniMax M3.1 Flash run shows what local serving costs in RAM.

What are developers saying?

The Hacker News thread was small when we checked, five points and five comments, and the one substantive reply we could read was from the author. jaekwon wrote the comment linked here, describing the fork-a-Go-harness rationale. There is not yet enough independent hands-on feedback to say how the approach holds up on real repositories, which is itself a finding: treat the claims below as the author's.

What is unproven?

• Self-reported reliability. The pass rates come from the author's runs. We have not reproduced them.
• Model dependence. Writing correct Gno code each time depends on the model. A smaller model may fumble the syntax, and the examples all use a strong open-weight model.
• Ecosystem fit. Gno is a Go dialect built for the gno.land smart-contract platform. Whether a general coding agent benefits from that VM, versus a plain sandbox or a SQLite file, is an open design question.
• Build friction. It must be built from source with a very recent Go toolchain, and there is no packaged release mentioned on the site.
• Hosted-model privacy. No telemetry from Gnosh does not stop your chosen provider from seeing your code.
• Fork maintenance. Staying in sync with upstream Crush is the usual burden for a one-person fork.

How does it compare with other agent memory?

Markdown memory files are simple, portable and readable, but they depend on the model editing prose. Database memory scales but hides state. Gnosh sits in between: programmatic, inspectable through /mem commands, and reversible with /mem undo. If you already use persistent memory, compare with MemPalace local AI memory and the Karpathy LLM wiki pattern, and with Anthropic's own unified memory in Claude chat and Cowork.

What people are asking

Do I need to know Go? Not to use it, since the agent writes the Gno code. Reading the /mem log is easier if you do.

Does it replace Claude Code? No. It is closer to an alternative harness that happens to read Claude Code's flags and hooks. It is far younger, so expect rough edges.

Is the memory shared across machines? The site says mem is kept on your disk for the project. We saw nothing about syncing.

Bottom line

Gnosh is an interesting experiment in treating agent memory as code with transactions, a journal and undo. It is worth a look if you build harnesses or you are tired of memory files that drift. It is early, self-reported and one developer deep, so try it on a scratch repo first and wait for independent tests before trusting it with anything important.

Related reading

• CLAUDE.md as persistent memory for Claude Code
• MEMORY.md and AI agent persistence
• claude-mem: persistent memory with hooks, SQLite and Chroma
• Bernstein open-source governance layer
• MemPalace local AI memory
• Karpathy LLM wiki pattern for agent memory

Details are accurate as of October 30, 2026, based on the Gnosh website and Hacker News thread. The project is new and may change quickly.