hax: a terminal-native coding agent written in C

What hax is for, and who it leaves out

hax is a coding agent that runs in your terminal, ships as one native C binary, and starts without a runtime to boot. The README frames the target audience narrowly: developers who live in the terminal, run local models, audit what their tools do, package software for distros, or run agents where resources are scarce. That list is a filter, not a marketing line. The same section says that if you want MCP marketplaces, a plugin runtime, IDE panels, or per-command permission prompts, other agents build exactly that, and that hax deliberately does not. The philosophy document is cited as explaining each omission and the pattern that covers the need. That is a real design position: the project is betting that a user who wants to read the traffic between agent and model is better served by a small C program than by an extensible platform. The trade is that anything the platform ecosystem would give you has to come from your shell instead.

One binary, subprocess composition instead of plugins

The mechanism visible in the repository is a C program built with meson and ninja, linking against libcurl for network calls and jansson for JSON. There is no interpreter, no package manager, and no plugin loader in the top-level layout. The README describes composition via subprocesses instead of plugins, which is the architectural hinge: where another agent would expose a tool API, hax expects you to have a working shell. That choice shows up in the build too. The Makefile comment says hax resolves subagent hax invocations through PATH, so a development build is most useful when the binary is symlinked there. A single binary with a small dependency set means the memory it does not use is memory left for the model itself, which matters when llama.cpp is competing for the same RAM. The provider layer is broad on paper: OpenAI and compatible endpoints, Anthropic and compatible endpoints, Codex through a ChatGPT subscription, OpenRouter, OpenCode Zen and Go, llama.cpp, and custom endpoints. Configuration is plain text, sessions are plain text, and the README calls the whole thing a well-behaved Unix tool with XDG paths and clean stdout in one-shot mode.

Installing hax and running a first prompt

On macOS or Linux with Homebrew, installation is one command. The README gives this exact formula, which pulls from the project's tap rather than the default one.

brew install oleksandrchekhovskyi/hax/hax

On Arch Linux the package name is hax in the AUR. On any Linux distribution you can instead download the prebuilt static binary for x86_64 or aarch64 from the latest release and unpack the hax binary into a directory on your PATH. Building from source is the route for the BSDs and for anyone who prefers a binary linked against system shared libraries. The README gives this sequence, and notes that scripts/install_deps.sh covers Debian, Ubuntu, Fedora, Arch, openSUSE, Alpine, macOS, FreeBSD, and OpenBSD.

git clone https://github.com/OleksandrChekhovskyi/hax.git
cd hax
scripts/install_deps.sh
make
make install

After a plain build the binary sits at ./build/hax, and the README says the examples elsewhere assume hax is on PATH. For hacking on hax, make symlink links the freshly built binary into ~/.local/bin so it stays on PATH across rebuilds. The first run is meant to be interactive: start hax, then use /provider to see available providers and choose a model. Interactive provider, model, and effort selections are remembered. If you are running a local model, the documented order is to start llama-server with your GGUF file and then launch hax with --provider llama.cpp, at which point hax auto-discovers the model and runtime capabilities without a custom provider config block. Ollama is the other local path: run ollama serve. For a one-shot run, the README's example is hax -p "list TODOs", which prints the final answer; the README also notes that -p mode keeps stdout clean and writes resume hints to stderr, so it can be piped. Prompts can also be read from stdin with printf "explain x" | hax -p. Sessions resume with hax -c for the latest session in the current directory, hax --resume to pick one, or hax --resume=ID -p "next" for a specific session in one-shot mode.

Where hax is the wrong tool

The deliberate omissions cut both ways. If your workflow depends on MCP servers, a plugin runtime, or an IDE panel, hax does not have them, and the README says so plainly rather than promising a roadmap. Per-command permission prompts are also absent by design, which is a meaningful gap for anyone who wants a confirmation gate before an agent touches a file. The composition story is subprocesses, so a tool you want the agent to use has to be a command on the system, not a registered extension. Platform support has hard edges. The README states hax runs on Linux, macOS, FreeBSD, and OpenBSD, that Windows use goes through WSL, and that the BSDs build from source only, so there is no package to install there. The dependency script covers a specific list of distributions; on anything else you install a C compiler, libcurl, jansson, meson, ninja, and pkg-config by hand. fzf is installed by that script because hax uses it for @file completion when available, which means file completion is degraded rather than broken if fzf is missing. Local model work also assumes you already have a llama.cpp or Ollama server running; hax discovers the model, it does not start one for you.

hax compared with a plugin-first agent

The obvious comparison is with agents that are built as extensible platforms, where tools arrive through a plugin or MCP interface and permissions are negotiated per command. The difference is not cosmetic. A platform agent can grow capabilities without a rebuild and can ask before each action; hax keeps a fixed feature surface and expects the shell to supply the rest. For a distro packager, that is the whole point: one C binary with libcurl and jansson is auditable and packageable, while a runtime with a plugin marketplace is a moving target. For a developer debugging a bad model response, the relevant difference is the transcript. hax offers a transcript view on Ctrl+T showing exactly what was sent and what came back, plus an optional detailed wire protocol trace, and a mock provider and demo scripts documented under docs/debugging.md. An agent that hides the request behind an abstraction layer makes that inspection harder. The cost is real: no marketplace means no drop-in integrations, and no permission prompts means you are trusting the agent's scope decisions. If those two features are the reason you picked an agent in the first place, hax is the wrong side of the trade.

Maintenance, licence, and upgrade cost

The repository is not archived, and the last push was on 2026-09-14, six days before this writing. Releases are frequent and small: v0.3.0 on 2026-08-12, v0.4.0 on 2026-08-22, v0.5.0 on 2026-09-04. That cadence suggests the project is still moving, and the CHANGELOG.md at the repository root is where the project tracks what changed between those tags. Upgrade cost depends on how you installed it. Homebrew and the AUR handle version bumps through the package manager. A static binary from the latest release is replaced by hand. A source build is a git pull followed by make, or make symlink if you want the dev binary to stay current on PATH across rebuilds. Configuration is plain text and interactive selections are stored separately from the config file, so a version bump does not force you to rewrite a config. The licence is MIT, which is permissive and places few obligations on redistribution; the LICENSE file at the root is the authoritative text, and packaging decisions that depend on licence terms are for you or your legal counsel to make, not this article.

Editorial conclusion

Adopt hax if you work in the terminal, run llama.cpp or Ollama locally, or need to audit agent traffic; the Ctrl+T transcript view and optional wire trace exist for exactly that. Do not adopt it if you need MCP marketplaces, IDE panels, or per-command permission prompts, because the philosophy document states those omissions are deliberate. Before committing, verify the provider you intend to use is listed in docs/providers.md, confirm a llama.cpp or Ollama server is reachable for local work, and check that your platform is Linux, macOS, FreeBSD, or OpenBSD, since Windows requires WSL and the BSDs build from source only.

Frequently asked questions

Official sources

1. License: MIT
2. OleksandrChekhovskyi/hax on GitHub
3. Project website
4. README
5. Releases