qqqa: qq is read-only, qa writes once per invocation, and one provider profile is a stub

One binary is read-only, the other gets one confirmed action

The pair is split by permission rather than by task. The question binary takes one prompt and returns an answer, and it has no tools at all: no file access, no command execution, nothing to confirm because nothing is possible. The agent binary is the one with capabilities, and they are deliberately rationed. It can read a file, write a file or execute a command, but only once per invocation, and execution requires confirmation. That last constraint is the design: a single step, reviewed, rather than a session that accumulates authority. Transient context is the other half of the design, and it is opt-in rather than ambient. The question binary will use the last few terminal commands as hints and will consume piped input if there is any, so it composes with pipes and files instead of expecting an interactive chat.

Stateless is the default and a config flag away from not

There is no session process, no hidden conversation memory and nothing carried between runs, and the argument for it is written as three properties rather than a slogan. It is focused, in the Unix sense of doing one thing. It is shell friendly, because it composes with pipes and files rather than needing a terminal UI. And it is safe by default, which follows from the permission split described above. The trade is continuity, and continuity is available for anyone who wants it through a setting in the config file that includes prior turns, or by opting in during the interactive first-run flow. That is the honest shape of the feature: the project argues for statelessness on principle but does not treat it as a rule, and the setting name is the first word of the recommendation to read the config before deciding.

Three providers are command line tools, and one of them cannot stream

Most profiles are HTTP endpoints behind an OpenAI-compatible client, and one is a local runtime. Three are not. Two shell out to coding-agent binaries so an existing subscription can be reused instead of a second API bill: one wraps the Codex executable and the other wraps the Claude executable, with the latter requiring a one-time login command before use. Their limitations are documented rather than glossed over. The Codex-backed profile cannot stream, so even without asking for streaming off, the tool buffers the whole response and prints it once at the end. The agent binary still expects structured tool calls from that provider, in the same shape it uses everywhere else. The Claude-backed profile does stream, but pinning a specific desktop model requires a nested override in the config that applies only to that provider, because the per-run model flag still wins. If the binary is missing or fails, the tool surfaces its output so you can fix the environment.

The direct Anthropic profile is a stub while the CLI one works

The provider list contains an odd asymmetry that is worth naming before you pick one. There is a direct Anthropic profile in the shipped configuration and it is not wired up, and the first-run flow offers it with a placeholder model name and a note that it is waiting on the vendor's messages interface to settle. Meanwhile the Claude Code CLI profile, which reaches the same vendor through a local binary and an existing subscription, is fully supported and even has its own model-override mechanism. So the practical reading is that if you have a Claude subscription, use the CLI profile; if you want the direct API, the config entry exists but does nothing yet. The same pattern appears elsewhere in the list: one profile is marked as needing a local port adjustment, and another is described in terms of being faster but smarter rather than faster.

On Linux the short command name may already be taken

Installation is three platforms and one collision. The package manager route covers macOS and Linux with a single formula. Linux users without a package manager download a prebuilt archive, extract it, and put both binaries somewhere on the path, with a system directory given as the example. The warning is specific to Arch-family systems, where a short command name in the system binary directory may already belong to another package, and the suggested workarounds are to install into a directory you own and rename if needed, or to build from the repository with the Rust package manager. Windows is the same idea with two executables and a path variable, with a note to choose the archive matching your processor architecture. In all three cases the artefact is a pair of binaries rather than a library, so there is nothing to link against and no runtime to install beyond the binary itself.

The config path prefers the XDG location only when no legacy file exists

Configuration has a precedence rule that is easy to miss and produces confusing behaviour if you get it wrong. The tool reads a dot-directory inside your home, and if the XDG base directory variable is set and no file exists at the legacy location, it stores the config in the XDG path instead. So the location depends on what already exists on disk, not on a preference. The file is created on first run with restrictive permissions, which matters because it holds provider keys. The interactive initialiser sets the provider and the key, and it is deliberately non-destructive: if a config file is already there, the command leaves it alone and explains how to re-run the flow after moving or deleting it. That is a small design decision that prevents the worst possible first-run experience, which is a wizard that silently overwrites working keys. The first run is one command on either binary:

qq --init

The provider choices the flow offers are listed with their model names and a one-line trade-off each, which is a better first-run experience than an empty provider field.

The manifest is a patch ahead of the newest release

Versioning tells you the project is mid-flight. The newest tagged release is the launch version from late 2025, while the manifest already carries the next patch, and the default branch has received commits as recently as late June 2026 with no release since. The release titles are a compact history: the version before launch added Windows support, made streaming the default, and added the two command-line providers; the one before that added clipboard copying, timeouts and self-signed certificate handling. The development dependencies explain how that is tested. There is a mock HTTP server for the API profiles, a certificate generator for the self-signed case, an assertion helper for running the binaries, a serial test runner because the tests share state, a temporary-directory helper, and a library for allocating a pseudo-terminal. That last one is the answer to how a tool that speaks HTTP manages to drive a command line program that insists on being attached to a terminal. Two smaller details round out the picture. The formatter renders XML-like tags to terminal colours rather than emitting markdown, which is the right call for a pipe and the wrong one for a log file, and there is a persisted switch to turn decorative output off for people who need their logs to stay clean.

Editorial conclusion

qqqa suits someone who wants a model in a pipeline rather than a chat window, and who is already paying for a coding-agent subscription they would rather reuse than duplicate. Before you rely on it, pick a profile deliberately, because the two CLI-backed profiles behave differently from the HTTP ones: one cannot stream and buffers the whole answer, and both need the underlying binary installed and authenticated first. Decide about history too, since the tool is stateless by design and turning it on is a config setting. And if you install on Linux, check what already owns the short command name before you copy a binary into a system directory.

Frequently asked questions

Official sources

1. iagooar/qqqa on GitHub
2. Issues
3. License: MIT
4. README
5. Releases