agentty: a C++26 coding agent that ships as one static binary
AI pair programming in your terminal — one static binary, sub-ms startup, any model
At a glance
- What is it?
- agentty is an MIT-licensed terminal coding agent written in C++26 and distributed as a single 16.7 MB binary. Its pitch is startup speed and a local retrieval engine, not a new model or a new interface.
- Who is it for?
- Adopt agentty if you want a terminal coding agent that installs as one binary with no Node or Python runtime, and if you are willing to accept that the semantic half of retrieval depends on a local Ollama server you run yourself. Do not adopt it if you need a project with a long release history and a broad third-party plugin ecosystem, or if you cannot run bwrap on Linux or sandbox-exec on macOS, since the sandbox is described as the default for every shell call.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem agentty targets: runtime weight and context dumping
Two complaints about terminal coding agents appear in the README's own framing. The first is distribution weight. Most of these tools ship as a Node or Python application, which means a runtime, a package manager, and a dependency tree before the first prompt. The README states that agentty is one native binary of 16.7 MB with zero runtime dependencies and no npm install step. The second complaint is context cost. The README argues that sending large parts of a repository on every turn wastes tokens, and that retrieval of a small set of relevant passages keeps more of the context window free for the task. The audience is developers who already work in a terminal, want to point the agent at a model of their choosing, and are willing to run a local embedding server to get the semantic half of search. It is not aimed at people who want a graphical editor with an inline agent, although the README notes it runs inside Zed over ACP.
What one static binary actually buys you
The README claims a cold start under 1 ms and a keystroke-to-pixel latency of about 1 ms, and describes the build as C++26. Those are the project's figures, not measurements I reproduced. The practical consequence of a static binary is simpler than the latency claim: there is no interpreter to install and no virtual environment to recreate on a remote box. That matters for the air-gapped mode the README describes, where a machine with no internet runs the agent and a laptop relays bytes over SSH with TLS pinned end to end. A single binary is also the reason the install line is one curl piped to sh. The trade-off is that you are trusting a prebuilt artifact from a GitHub release rather than building from source, and the README does not describe a reproducible-build or signature-verification step.
The retrieval funnel behind search_docs and search_code
agentty exposes retrieval through two tools. search_docs queries a knowledge base made of a docs folder, installed skills, and learned remember memory, with connected MCP resources as an opt-in addition. search_code performs semantic search over source by meaning, positioned in the README as the complement to grep for questions where you do not know the identifier. The pipeline is hybrid: BM25 plus dense embeddings, fused with reciprocal rank fusion, then reranked, diversified, and expanded over what the README calls a GraphRAG document graph. The default path, according to the README, makes no LLM calls. Every returned passage is source-tagged as docs, skill, memory, or an MCP URI, and carries a file and line range so the model can cite or open it. This is the part of the project with the most moving pieces, and the README is honest that the semantic half needs a localhost Ollama server while BM25 works with zero setup.
Getting it running: the commands and environment variables
Installation is a single command from the README: curl -fsSL https://raw.githubusercontent.com/1ay1/agentty/master/install.sh | sh, followed by cd into your project and running agentty. First launch opens an auth flow where you paste an API key such as an Anthropic sk-ant- key, or select a local Ollama model that needs no key, or sign in with Claude Pro or Max OAuth. Provider selection is a flag that persists, for example agentty --provider openai -m gpt-4o, agentty --provider groq -m llama-3.3-70b, agentty --provider ollama -m qwen2.5-coder, or agentty -m claude-opus-4-5. In-app switching is bound to Ctrl-P. The README lists DEEPSEEK_API_KEY, XAI_API_KEY, and GEMINI_API_KEY as the environment variables for those providers. To turn on semantic retrieval you run ollama pull nomic-embed-text and ollama serve, and optionally export AGENTTY_DOCS_DIR to point at a docs folder. The README states that agentty detects the running server and upgrades from BM25-only to hybrid retrieval without a restart.
Sandboxing, workspace boundaries, and where they stop
Every shell call is described as running inside bwrap on Linux or sandbox-exec on macOS, and the file tools are said to refuse paths outside your workspace. That is a meaningful default because an agent with a bash tool is otherwise an arbitrary command runner with your user's permissions. The limitation is platform coverage. bwrap is a Linux mechanism and sandbox-exec is a macOS mechanism, so the README's safety story does not extend to Windows in the material provided. There is also a boundary question the README does not answer: what counts as your workspace when you launch agentty from a directory that contains symlinks or mounted volumes. If you work across multiple repositories in one session, the refusal behaviour for paths outside the launch directory is the first thing to check, because it determines whether the agent can touch a sibling checkout at all.
Smart Mode and the cost of model routing
Smart Mode uses one flagship model to plan while cheaper models do the legwork, with effort scaled to each turn's complexity and a cascade that retries harder only when a cheap attempt falls short. The README says the router learns your repository across sessions and that turning Smart Mode off is a strict no-op. The design question is where the routing state lives and whether it is per-project. The README does not say. If the learned router is stored outside the repository, a shared or ephemeral machine loses that state between sessions, and the cost advantage narrows to the cascade retry alone. If it is stored inside the repository, it becomes a file you must decide whether to commit. Neither answer is given, so treat Smart Mode as a feature to evaluate against your own provider pricing rather than as a guaranteed saving.
How agentty differs from Aider
Aider is the obvious comparison because both are terminal tools that edit files in a repository and both are open source. The README's own comparison page is linked, but the difference in approach is visible in the feature list. agentty ships a local retrieval engine with BM25, embeddings, and a document graph, and exposes it as search_docs and search_code tools the model can call. Aider's model is built around the edit format and the set of files you add to the chat, with the user choosing what enters context. That is a real architectural fork: agentty tries to decide what is relevant, Aider asks you to decide. The second difference is distribution. agentty is a static C++26 binary with no runtime, while Aider is a Python application installed through pip or pipx. If your environment already has Python and you prefer explicit file selection, the retrieval engine is not a reason to switch.
Release cadence, licence, and what to verify before adopting
The repository shows three releases in September 2026: v0.6.0 on the 2nd, v0.7.0 on the 4th, and v0.8.0 later the same day. That is a fast cadence at a 0.x version number, which usually means configuration keys and flags can move between releases. Pin a version rather than tracking master if you script around the CLI. The licence is MIT, which permits commercial use and modification, but I am not giving legal advice and you should read the LICENSE file for the exact terms. What to verify first is narrow: confirm the install script's binary runs on your distribution, confirm that ollama pull nomic-embed-text plus ollama serve actually upgrades retrieval as described, and confirm the workspace boundary behaviour for the paths you actually work in. Those three checks cover the binary, the retrieval engine, and the sandbox, which are the three claims the project is built on.
Editorial conclusion
Adopt agentty if you want a terminal coding agent that installs as one binary with no Node or Python runtime, and if you are willing to accept that the semantic half of retrieval depends on a local Ollama server you run yourself. Do not adopt it if you need a project with a long release history and a broad third-party plugin ecosystem, or if you cannot run bwrap on Linux or sandbox-exec on macOS, since the sandbox is described as the default for every shell call. Before committing, verify three things on your own machine: that the install script's binary runs on your distribution, that ollama pull nomic-embed-text followed by ollama serve actually upgrades search from BM25-only to hybrid as the README claims, and that the paths you work in fall inside the workspace boundary the file tools enforce.
Community notes