atomic-agent

10 coding agents, one Qwen 3.8 27B, same llama-server: tokens and cache reuse differ more than pass rates Part 2 of my agent test (part 1 was a 4B model) Hardware I used: MacBook Pro M5 Max, 64 GB. Qwen 3.8 27B Q4 on llama.cpp, thinking off. Setup - same model and server for everyone - 5 small coding tasks, each with a little trap - each agent locked in a sandbox: it can only touch its own folder and only talk to the model - auto-approve on, telemetry off, 5 min limit Results |#|Agent|Passed|Median time|Median tokens|Cache reuse|Tried to go online| |:-|:-|:-|:-|:-|:-|:-| |1|Pi|5/5|38 s|9.2k|72%|no| |2|DeepSeek Harness|5/5|60 s|35.3k|83%|no| |3|Codex CLI|5/5|94 s|36.3k|79%|every run| |4|OpenClaw|5/5|106 s|39.0k|72%|unclear| |5|Cline|5/5|152 s|29.6k|79%|every run| |6|OpenCode|4/5|50 s|32.4k|75%|every run| |7|Hermes|4/5|80 s|64.9k|93%|no| |8|Atomic Agent|5/5|56 s|30.4k|86%|no| |9|goose|4/5|98 s|20.3k|76%|every run| |10|Qwen Code|4/5|183 s|107.9k|74%|unclear| Tokens and cache Pi is crazy lean: about 9k tokens per task, the lowest on every single task. Qwen Code was the hungriest at about 108k per task. Atomic Agent is the odd one out in how it works. It was the only one talking to llama.cpp's native endpoint with a grammar that forces the tool calls into shape. The other nine all went through the OpenAI-style API. It's also built to keep its prompt the same from step to step, which is why it reused 86% of the cache (2rd of 10). It stayed offline the whole time and passed 5/5. DeepSeek Harness was the surprise. It’s still an alpha, but it went 5/5, never tried to go online, and had the best cache reuse after Atomic Agent (83%). The trap and the network The log task got three agents. They grepped "ERROR" and got 244 instead of 64, because some normal lines just mention errors. OpenCode, goose and Atomic Agent fell for it. Codex, Cline, goose and OpenCode tried to reach the internet in every run, even with telemetry off. The sandbox blocked it, so I don't know what they were calling. OpenClaw and Qwen Code are "unclear" because they run as plain node and I couldn't tell them apart. llama.cpp notes - Codex needs llama-server's /v1/responses now - Hermes needs at least 64K context - Cline and Qwen Code have usage stats on by default, DeepSeek Harness uploads session logs (per their docs). I turned it all off Which column matters most to you when you pick an agent for a local model like Qwen 3.8 27B: passing, speed, tokens, or staying offline?

How well do coding agents drive Qwen 3.8 27B locally? I lined up 10 of them on one hardware My hardware: MacBook Pro M5 Max, 64 GB. Qwen 3.8 27B Q4 on llama.cpp, thinking off. I put Qwen 3.8 27B behind one llama.cpp server and gave 10 coding agents the same 5 tasks. |#|Agent|Passed|Median time|Median tokens|Cache reuse|Tried to go online| |:-|:-|:-|:-|:-|:-|:-| |1|Pi|5/5|38 s|9.2k|72%|no| |2|DeepSeek Harness|5/5|60 s|35.3k|83%|no| |3|Codex CLI|5/5|94 s|36.3k|79%|every run| |4|OpenClaw|5/5|106 s|39.0k|72%|unclear| |5|Cline|5/5|152 s|29.6k|79%|every run| |6|OpenCode|4/5|50 s|32.4k|75%|every run| |7|Hermes|4/5|80 s|64.9k|93%|no| |8|Atomic Agent|5/5|56 s|30.4k|86%|no| |9|goose|4/5|98 s|20.3k|76%|every run| |10|Qwen Code|4/5|183 s|107.9k|74%|unclear| Pi is crazy lean: about 9k tokens per task, the lowest on every single task. Qwen Code was the hungriest at about 108k per task. The setup - same model and server for everyone - 5 small coding tasks, each with a little trap - each agent locked in a sandbox: it can only touch its own folder and only talk to the model - auto-approve on, telemetry off, 5 min limit What I noticed The log task got three agents. They grepped "ERROR" and got 244 instead of 64, because some normal lines just mention errors. OpenCode, goose and Atomic Agent fell for it. Codex, Cline, goose and OpenCode tried to reach the internet in every run, even with telemetry off. The sandbox blocked it, so I don't know what they were calling. OpenClaw and Qwen Code are "unclear" because they run as plain node and I couldn't tell them apart. Atomic Agent is the odd one out in how it works. It was the only one talking to llama.cpp's native endpoint with a grammar that forces the tool calls into shape. The other nine all went through the OpenAI-style API. It's also built to keep its prompt the same from step to step, which is why it reused 86% of the cache (3rd of 10). It stayed offline the whole time and passed 5/5. Setup notes - Cline and Qwen Code have usage stats on by default, DeepSeek Harness uploads session logs (per their docs). I turned it all off - Codex needs llama-server's /v1/responses now - Hermes needs at least 64K context Would you pick an agent for fewer tokens or for passing every task?

Local Qwen 3.8 27B as the worker, Opus as the planner: same 38 tests passed, half the API bill A few days ago I asked in a different subreddit whether people use multi-agent orchestration or stick with a single agent (original thread). It got 83K views and 60+ comments, way more than I expected, and the answers were all over the place. The main things people said: - Single agent for writing code, multi-agent for research and big search-style jobs. - Multi-agents eat tokens, and agents step on each other's work. - It doesn't fall apart as long as there's one lead in charge. - Measure the finished, working result, not the moment the agents say "done". Everyone was arguing from experience and nobody had numbers on the same task. So I took four setups straight from the comments and gave them the exact same job. The four setups 1. Claude Code, single agent. Anthropic’s coding agent running Opus 5.5 on its own, start to finish, no subagents. 2. Codex CLI, single agent. Also one agent working alone, but from OpenAI. It ran GPT 5.5 on its own, with the same instructions. 3. A Paseo agent team, set up exactly like u/c-digs described. He shared his whole setup in the thread: an expensive lead model that hands work to cheaper worker agents, with a structured handoff prompt. I used his published team prompt and agent profiles as is. Big thanks to him for making this testable. 4. Atomic Agent in Fusion mode. Fusion mode in Atomic Agent is where a cloud model plans while smaller local models do the work. Here the planner was Claude Opus 5.5 in the cloud and the workers were Qwen 3.8 27B running locally on the same Mac, so the building itself didn't cost any API money. The task One small Python app, an expense tracker in 5 parts: storage, an importer for a deliberately messy bank CSV (mixed date formats, euros and pounds, refunds, duplicate rows, a few broken rows), a JSON API, a CLI and an HTML monthly report. All five parts share one config file, so there's room for agents to collide. Every setup got the same one-line prompt and the same spec. Grading was 38 hidden tests the agents never saw, copied in only after each run finished. Setup for all runs: M5 Max with 64 GB, October 26, one run per setup. Cloud models through OpenRouter. Versions: Claude Code 2.1.310, Codex 0.147.0, Paseo 0.13.2, Atomic Agent 0.6.11. Results |Setup|Models|Time|Hidden tests|API cost| |:-|:-|:-|:-|:-| |Codex|GPT 5.5|5m 38s|38/38|$1.32| |Claude Code|Opus 5.5|6m 57s|38/38|$1.27| |Paseo team (c-digs setup)|Opus 5.5 lead|5m 25s|38/38|$1.13| |Atomic Agent, Fusion mode|Opus 5.5 plans, local Qwen 3.8 27B Q4 builds|3m 11s|38/38 |$0.40| |What the comments said|What happened| |:-|:-| |"Single agent for writing code"|Right for this job. Both single agents were fast and perfect| |"Multi-agent eats tokens"|Not here. The orchestrated setup with local workers had the smallest bill| |"Agents step on each other"|Zero merge conflicts in all four, and nobody touched the input file| |"Fine as long as there's one lead" (c-digs)|Right. The Paseo lead got 38/38| What I learned The most interesting result was Paseo. c-digs's lead looked at the job, decided it was small, and built everything itself without spawning a single worker. That's exactly what he said his setup does ("simple tasks: it does it directly"). A good orchestrator knowing when not to split is a feature. So my take: orchestration is worth it, just not for the reason most people argue about. It won't make a small job faster. It lets an expensive model do only the thinking while cheap or local models do the bulk, and it keeps someone watching the work when a piece fails. The bigger the job, the more that matters, and this one was about as small as a real task gets. Round 2 should be a job big enough that splitting it is the obvious move. If you have a task in mind that is fair to test, drop it below. What’s the biggest job you’ve handed to a multi-agent setup, and did the planner live up to its expectations?

@PaulGugAI There is an interesting project focusing on local AI models. Still experimental but check this if you are trying to benefit from very small models: AtomicBot-ai/atomic-agent

@atomicagent_io still works with the wifi off. the model runs locally, so no connection needed AtomicBot-ai/atomic-agent

想让本地小模型也能干多步活，Atomic Agent（MIT）走的是 llama.cpp 优先：开浏览器、读写文件、跑你批准过的命令，跨会话记得上下文。 有个 Fusion 模式挺有意思，一个模型做规划，一组 worker 执行，本地和云端模型可以混着用。 留意它会原地自更新，TUI 里提示重启。 AtomicBot-ai/atomic-agent

Atomic Agent: A local-first AI agent that runs on your machine, with local or cloud models (3.2k stars) What it does All text below is quoted directly from the project README. >A local-first AI agent that runs on your machine, with local or cloud models. >Drives your browser, edits files, runs approved commands, and remembers context across sessions. Open source, running on our TurboQuant llama.cpp for +30-50% throughput on small local models. >It works across your machine: browse the web, read and edit files, run approved shell commands, inspect documents, remember context across sessions, schedule follow-ups, and call external tools over MCP. Coming from another agent? The first run offers to bring your data over: - Claude Code: skills, memory, MCP servers, sessions, and (opt-in) provider keys - Codex: skills, memory, sessions, and (opt-in) provider keys - Oh-My-Pi: skills, MCP servers, and sessions - Pi: skills and sessions - Hermes: sessions, cron jobs, and (opt-in) provider keys - OpenClaw: sessions and cron jobs >Developer preview. APIs, commands, config, and behavior are still moving, so pin a release if you need a stable integration point. Repository AtomicBot-ai/atomic-agent Repository stats |Metric|Value| |:-|:-| |Stars|3,234| |Forks|265| |Last release|v0.6.7 (2026-10-07)| |Languages|TypeScript 98.4%, JavaScript 1.3%| |Contributors|16| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|claude (167 commits), cursoragent (1)| |AI co-authored commits|Claude: 167, Cursor: 3| Main contributor |Field|Value| |:-|:-| |Name|Valera Brizhatiuk| |GitHub|@plombeer31| |Commits to this repo|632 (top contributor)| |Public repos|2| |On GitHub since|2016-05-23|

Official site + downloads: atomicagent.io Open source on GitHub: AtomicBot-ai/atomic-agent (Mac needs Apple Silicon and macOS 14+)

128K context on Qwen 3.5 4B in 800 MB instead of 4 GB: what we changed in our llama.cpp build. I work on Atomic Agent, an open-source agent built for local models first, so weigh this accordingly. We just shipped the first desktop build. This post is about what's under it, because most agents are designed around a frontier cloud model and then "support" local ones, and we tried to go the other way. Here's what changed once we treated a 4B to 9B model as the main target. The KV cache is compressed. We ship our own llama.cpp build with TurboQuant, set to turbo3 by default. In our tests on a MacBook Pro M5, a 128K chat on Qwen 3.5 4B fits in 800 MB instead of 4 GB. It's lossy, so expect a small quality hit in exchange for the memory. The prompt prefix never changes mid-session. System prompt, tool catalog and skill list stay byte-identical between steps. Memory writes and anything that changes per step go at the tail. That lets llama.cpp reuse the KV cache for everything it already processed. On the same M5, a reply on Qwen 27B that used to take 4 min 20 s to start now starts in about 1 s. That's cache reuse, not faster inference, but on a long session it's most of the wait. State lives outside the model. Session state, memory and old tool results sit on disk, and the prompt is a bounded slice of them. On local models, long tool output gets trimmed before it reaches the context. For shell commands we keep the tail, because that's where the pass or fail is. When the conversation fills 90% of the window, the agent summarizes the older part and keeps going, instead of cutting it off. Tool calls are grammar-constrained. Every step is one inference, and llama.cpp's grammar forces the output into a JSON array of tool calls. A small model can still pick the wrong tool, but it can't produce broken JSON or invent its own call syntax. Each model family has its own profile, because Qwen and Gemma frame their thinking differently, and the grammar has to match. Reasoning is capped at about 1500 tokens per step by default, so a small model can't think in circles for ten minutes. The browser reads the accessibility tree, not screenshots. A compressed ARIA snapshot is a fraction of the tokens of an image, and a 4B model can actually act on it. There's a loop guard. Three identical calls in a row get a warning. Five with no new result and the call is blocked. Three blocks and the run stops and tells you why. Small models love to re-read the same file forever. Models are sized to your machine. Every model in the catalog has a minimum and recommended RAM. The 4B and Gemma 4 E4B start at 6 GB, Qwen 3.6 35B-A3B at 24 GB. On Macs the automatic context size leaves the system at least 4 GiB or 25% of RAM and caps the KV cache at 1/16 of RAM. All numbers above are from our own runs on one machine. Not a controlled benchmark, and I'd like to see them checked on other hardware. The desktop app wraps all of this. It downloads a model that fits, runs the agent on your machine and asks before anything writes a file or runs a command. There's also a Fusion mode, where a cloud model plans and local models do the work, so only the planner spends API tokens. Builds for Mac (Apple Silicon), Windows x64 and ARM, and Linux. On Windows ARM local models run on the CPU for now. Linux builds aren't signed yet. One more thing this sub will ask about. Anonymous usage analytics is on by default. It never sends message content, file paths or API keys. Settings › Privacy turns it off. MIT licensed: AtomicBot-ai/atomic-agent What context length do you actually run day to day on a 16 GB machine? That's the case we tuned for, and I'm not sure it matches how people here use their models.

the mac setup, the one that killed my claude max → mlx-serve: ddalcu/mlx-serve → atomic agent: AtomicBot-ai/atomic-agent the whole trick is ANTHROPIC_BASE_URL=localhost and claude code doesn't even notice it left anthropic's servers