Cloud planning, local typing: 11 minutes for $2.98, but first clear the 24GB VRAM hurdle
Atomic Agent's Fusion splits work between a cloud orchestrator and local workers. In one vendor demo, a fairy-tale pop-up book took 11 minutes and $2.98; using Fable alone took 21 minutes and $15.77. Don't rush to call local free: a 27B seat needs about 24GB of VRAM, and the number of fallbacks wasn't disclosed.
The tweet gives only a short set of numbers: the cloud does the thinking, and a local Qwen 3.8 27B does the writing. For a fairy-tale pop-up book project, Fusion completed in 11 minutes at a cost of $2.98. The same task using only Fable took 21 minutes and $15.77. Faster and cheaper—this combination is worth a look. But it comes from a single run by one vendor; it doesn't give the number of fallbacks/redos, and a single result can't be treated as a stable conclusion.
Atomic Agent's Fusion documentation describes the mechanism in detail. Fusion is a third run mode besides Local and Cloud. The orchestrator reads the project, breaks down tasks, writes briefs, and verifies; workers execute the split-off parts, and can do so in parallel. During a Fusion turn, the orchestrator cannot write files or run commands; it can only read, delegate, reply, and finish. The workers are what write files. Each worker receives a brief and the original request; the original request is capped at 16,000 characters. Workers run in a fresh temporary session, cannot see chat history, cannot ask you questions, and cannot delegate further.
The default direction is cloud planning and local work. It suits tasks that can be split into many small self-contained parts, with most execution staying on your own machine. The reverse direction is local planning and cloud work, toggled with /runmode swap; it suits tasks with a short plan and large output, such as large code files. The docs say that in their own code-heavy tasks, this direction reaches cloud-only levels, while the local model running alone falls short by a fair margin. The tradeoff is that cloud workers see the request and the files they read, so data goes to the cloud provider.
The easiest thing to overlook in a cost comparison is hardware. The docs state that a 27B-class local model needs roughly 24GB of GPU VRAM as a starting point. With less VRAM, a local seat can be slow enough to drag a single run out for hours. In the replies, someone did the math using secondhand-market median ask prices: about $1,200 for a 7900 XTX, about $1,650 for a 3090, and about $3,198 for a 4090. Note that these are median listing prices, not transaction prices. So-called local free still has to clear this hardware threshold first.
Fusion isn't fully automatic magic either. The orchestrator's verification includes verify.syntax and verify.run, which can check syntax, run commands, start services, and open pages to collect errors. The docs explicitly say these checks catch crashes, not whether behavior is correct. It doesn't know whether game physics feels right or whether chart numbers are correct. A "verified" result can still be wrong; you have to inspect the output yourself. There are also slot limits: each local worker needs a request slot on the local model server, and all slots share one GPU and one context pool. Cloud workers have a cloudWorkers cap. A single fusion.delegate can handle at most 16 tasks, and each brief is capped at 32,000 characters.
The data boundary also needs to be clear. In the default direction, the cloud orchestrator sees the conversation and the files it reviews; in the cloud-worker direction, your request—up to 16,000 characters—plus the files each worker opens go to the cloud provider. "Nothing ever leaves your machine" does not hold. The two seats must also be different providers; selecting the same provider twice will be rejected. Routers such as openrouter/auto may pick a small, cheap model and ignore Fusion instructions, so it's best to pin a specific model on the cloud side.
Two criticisms in the comments are worth keeping. Someone asked which parts of the 27B work got kicked back to the boss for rework; the tweet author replied that the write-up only gives the total for one run, not the fallback count. Someone else said outright that it can't be tested or reproduced. Another person pointed out that the animation on the right flickers and looks rough; the author clarified that this was a single Fusion vendor run, not a claim that Fable alone looks like that. Taken together, Fusion's direction is interesting, but the evidence is limited. If you want to try it, first run a job that can be split into small tasks and verified, set the worker count, budget cap, and local-server slots, and then see whether the money saved is enough to cover 24GB of VRAM.
Original post: https://x.com/QwenAIFans/status/2119919755343909249
发布时间: 2026-11-10 11:32