Chat tasks can work on separate repository copies
Give CodeAF several pieces of work and its chat interface can turn them into tasks, each with its own repository copy and branch. You keep the conversation while the task tree shows what's happening. That's the appeal for someone juggling several codebases: fewer terminals to babysit, with questions and unfinished work gathered in one place. The CodeAF README describes automatic landing of checked work onto your working branch, while protecting main, dev, and release branches.
The source checkout is substantial for a product presented as a single Go binary: our clone held 8,000 files, about 1,812,392 lines of source, and occupied 113 MB. Source size doesn't tell us the release binary's memory use. It does tell a contributor how much material they're taking on. The README labels CodeAF an early preview, which fits a tool whose task management and permissions need careful inspection before you let it manage ongoing work.
What happened when we ran it
Our run installed CodeAF commit 8761488 in 39 seconds, adding 228 packages, and built it successfully in 134 seconds. We ran it on October 9, 2026 in a fresh Debian container using golang:1.24-bookworm, with 3 CPUs and 8 GB of RAM. The container was unprivileged and held no secrets. These are useful results for a source contributor: dependency installation and compilation completed on the environment we supplied.
The tests timed out after 900 seconds. The supplied go test summary recorded 168 passes and 4 failures out of 172. The log tail showed successful packages under the senior-dev session, storage, and tool areas, alongside packages without test files. It didn't identify the failed cases or explain the timeout. We can't assign a cause from that tail. A successful build therefore comes with an unfinished, non-green suite in our sandbox.
Useful agent work needs a model connection
The first launch connects OpenRouter through a browser or accepts a key. Other hosted providers have their own authentication, while Ollama needs a running local service without a provider key. CodeAF also supports an OpenAI-compatible endpoint. The usage guide describes model configuration and spending controls. Choose the allowed models deliberately: the worker and checker can use different models, and automatic selection adds decisions beyond the model you chose for the conversation.
Our 3-CPU, 8 GB run had no secrets, so its successful build says nothing about whether a connected model completes your coding task correctly. The lab results also supply no model-serving measurement. If you choose Ollama, budget for that service separately. With a hosted provider, understand where project context goes and how spending is limited. The release installer and a compilable source tree only get the agent ready to receive those connections.
Headless commands edit the directory you hand them
The headless contract says do, exec, and run work in place. Chat tasks have their own task branches, but you shouldn't transfer that expectation to a cron command pointed at your everyday checkout. The contract also says that do answers questions by selecting an answer and recording the assumption. That's convenient for a fully specified job and a reason to avoid unattended execution when a requirement remains unresolved.
The 134-second build we measured can't validate those workflow choices for you. I'd give a headless job its own disposable checkout and spell out the allowed result in the brief, then inspect the returned record and diff before accepting changes. That recommendation follows the documented execution model. It also avoids treating every command that emits a successful-looking result as evidence that the right checks ran or the right question was answered.
Usage counts and model ratings leave the machine by default
The telemetry disclosure says usage counts are on by default and the application prints no notice. Its separate Model Pool sends ratings and model identifiers, which the documentation says exclude prompts, code, and paths. CODEAF_TELEMETRY=off or DO_NOT_TRACK=1 stops sending from both streams. The pool can still read its index under that telemetry setting, so choose its own off setting too if you want it disabled altogether.
Maintenance is active, and the preview warning still matters
Our scan found 6 CI workflow files, a tests directory, and no Dockerfile. GitHub's last push was October 10, 2026, with 380 stars and 272 open issues and PRs. Release v0.7.1 shipped on October 6 and changed usage accounting and telemetry receipts. Issue 1301, updated October 9, describes inconsistent approval wording across the interface and transcript. That is a specific usability problem when you need to understand what permission you're granting. Current activity supports a maintenance judgment, while the open report supports caution about the interface.
Choose Aider or OpenCode if task orchestration isn't the job
Aider is a better starting comparison when you want a direct conversation about edits in one repository. Its codebase map and Git integration keep that workflow recognizable. OpenCode has a read-only planning agent that denies edits by default and asks before shell commands. Either deserves a trial if your immediate problem is inspecting a repository or making a focused change, with little need for CodeAF's persistent task tree.
I'd try CodeAF on a noncritical project where parallel tasks actually remove coordination work, with provider settings and telemetry chosen before the first session. I wouldn't make it the unattended owner of a release branch on the strength of our build alone. Our tests reached the 900-second cap with recorded failures. Before letting a scheduled command edit a checkout, read its in-place execution contract and decide exactly who reviews the resulting diff.