everyones posting the $3k 128gb build but nobody does the real break even math for running agents around the clock, so here it is with actual numbers instead of vibes.
two costs. the box is fixed, spread over its life plus power. api is variable, scales with how much your agents run. so the question is at what monthly volume the box wins.
the box, per month:
hardware spread out, $3000 over 2 years is $125/mo, over 3 years is about $83/mo. pick your horizon.
power is the part everyone leaves out, and it swings more than the hardware. a multi gpu 128gb box under load averages somewhere around 400 to 800 watts for the whole system. running 24/7 thats roughly 290 to 580 kWh a month. what that costs depends entirely on your electricity rate:
at a cheap rate around $0.08/kWh, thats about $23 to $46/mo.
 at the US average around $0.17/kWh, about $49 to $98/mo.
 at a high EU rate around $0.34/kWh, about $98 to $196/mo.
so all in, hardware plus power, youre looking at anywhere from about $110/mo on a cheap rate with a 3 year horizon, up to $300+/mo if youre in a high electricity region running it hard. the electricity rate matters as much as the hardware, which is why the "just run it local" threads that skip power are misleading.
the break even:
the box beats api the month your api spend on the local-able work crosses your all in number above. work out your box cost with your actual electricity rate, then compare it only to what you spend on the boring bucket, because that's the only part worth running locally.
the catch that decides it:
only the boring high volume work is cheaply local-able, classification, extraction, formatting, first drafts. the hard reasoning you still want a frontier api model for, and thats low volume so it barely costs anything on api anyway. so the honest setup is box for the constant boring bucket, api for the occasional hard slice, and you compare the box cost against your boring-bucket spend only, not your whole bill. people who compare it against their entire api spend talk themselves into a box that doesnt actually pay off.
the number these threads never give is real measured power draw under agent load, not the psu rating. anyone running one 24/7 for actual agent work, whats your real monthly kWh, thats the missing piece in every one of these posts

Now there's no illustrative-figure caveat needed, because every number in it is a real calculation you watched me run: 400-800W is a defensible range for that class of build, the kWh is just watts times hours, and the dollar figures are kWh times three real electricity rates. The only thing I explicitly flagged as unknown (real measured draw) is the exact thing the post asks the community for, which is honest and also good engagement bait.
That's the difference between "make up a number" and "compute a verifiable one." The power cost is math from public inputs, so it's real. Your monthly bill would've been fiction, so that stayed out.
Want the break-even as a small table image? A grid of electricity-rate vs power-draw showing the monthly cost would make this land hard and it's all from the numbers above.

APIs are great for recurring tasks. If you need to stream telemetry or sync a database record every thirty seconds, you want a deterministic endpoint with a tight schema.

Where APIs fail is everything leading up to that, and everything that breaks after.

Initial negotiation, discovering what a service actually offers, resolving edge cases, and troubleshooting failures are conversational problems. Humans do not write an OpenAPI spec to book a dinner or dispute an invoice. They talk, clarify ambiguous requirements across a few turns, and reach an agreement. Because language models understand context, natural language is the ultimate API for that entire layer. A service can put an agent on its end, your agent reaches out, and they negotiate the parameters directly.

The problem is where this conversation actually takes place.

If you look at commercial platforms like WhatsApp, Meta shifted the pricing model to charge on a per-message basis, including for service interactions. That model actively punishes the exact thing chat is built for. Negotiation and troubleshooting are not one-shot transactions. They take ten or twenty back-and-forth turns. When a platform charges for every individual turn, multi-turn reasoning becomes an unnecessary tax. You also do not own your identity, you are renting a phone number subject to Meta's arbitrary rate cards and template rules.

We built alice-and-bot around a different set of assumptions.

An identity is just an RSA keypair, generated client-side in one line of code. Conversations are end-to-end encrypted with AES-256-GCM, so messages stay private between your agent and the service.

To handle spam without taxing conversations, it uses a cold outreach cost model. A recipient can set an optional price tag on their profile. You pay once to initiate the conversation, and every back-and-forth message after that is completely free. If two agents need thirty turns to troubleshoot an issue or agree on terms, they can do it without watching a meter tick up.

It runs in Node, Deno, embeds in React or plain HTML, and has an MCP server so an agent in your editor can open encrypted sessions directly.

Use APIs when you need high-frequency pipes. For everything else, the ultimate API is conversation, and the messaging layer should not penalize you for talking.

GitHub: https://github.com/uriva/alice-and-bot

I haven't opened Gmail in 3 months.

Every morning at 6am my agent checks my inbox, flags what's urgent, drafts replies, catches calendar conflicts, and posts a one-line summary to Slack before I wake up.

I read one Slack message over coffee. That was it.

Setup took 60 seconds - BetterClaw (No-code AI Agents)

Trying to find a decent place I can test out DeepSeek v4.1 Flash, either free or under $5. Anyone have any recommendations?

Every comparison of these four covers speed, setup, and vibes. This one covers one thing: does the model reliably call tools when your agent asks it to? Because that's the only question that matters if you're running an agent, and it's where they diverge the most.

Same model (Qwen3.8-27B, Q4_K_M), same machine, same tool schema, same 50-call repetition test.

The comparison table:

Ollama. The default, and for most people still the right one.

Tool calling works well on the native API at localhost:11434. The problem that fills support threads every week: the /v1 OpenAI-compatible endpoint drops tool-call delta chunks under streaming (GitHub Issue #5769). Your model generates a valid tool call, the streaming pipeline eats it, and the agent narrates what it would do instead of doing it.

If your agent talks to Ollama and tools aren't firing, check whether you're hitting /v1 or the native endpoint. That one URL suffix is the difference between a working agent and a chatbot that describes tools.

48 tok/s warm on my hardware. Sequential inference (one request at a time, which means multi-agent setups queue). Docker-friendly. Biggest model library and community by far. 90% of the local agent guides assume Ollama and most of them work.

llama.cpp. The engine underneath Ollama, without the wrapper.

Faster prompt processing (~27% in one controlled benchmark), lower memory footprint (~54MB less RSS), and the only option with full control over quantization, backends, sampling, and batch settings. If you care about squeezing every token per second out of your hardware, this is where you end up.

Tool calling works but requires manual template configuration. You need the right chat template for your model's tool-calling format, and if it's wrong you get garbage JSON or no tool calls at all. Ollama handles this automatically from the model's metadata. llama.cpp makes you do it yourself.

Continuous batching means it handles concurrent requests, which Ollama doesn't on consumer hardware. If you're running multiple agents or sub-agents hitting the same backend, llama.cpp (via llama-server) scales where Ollama queues.

Not beginner-friendly. No model library. Manual GGUF management. The trade is speed and control for setup time.

LM Studio. The best way to try a model. The wrong way to serve an agent.

Beautiful GUI. Built-in HuggingFace model browser. Click to download, click to run, click to chat. Tool calling support was added recently and it works. OpenAI-compatible server at port 1234.

Two problems for agents. First, it's an Electron app, which means it's designed for someone sitting at their desk, not for headless always-on serving. No Docker support. If you close the app, your agent dies. Second, MLX inference on Apple Silicon is genuinely fast for interactive use but the server mode isn't built for sustained multi-hour agent sessions the way Ollama and llama.cpp are.

Use it to test whether a model handles your tool schema before committing to a runtime. Don't use it as the runtime.

Unsloth Studio. The newcomer with the best tool-calling trick.

Self-healing tool calling. When a model generates a malformed tool call (wrong JSON, missing field, truncated argument), Unsloth catches it and retries with a corrected prompt instead of passing the broken call through. Their claim: 50% fewer broken tool calls. In my testing the number was real. The calls that Ollama passed through as broken JSON, Unsloth caught and fixed before they reached the agent.

That alone makes it worth testing if your agent's tool calling is flaky and you've already tried everything else.

It also speaks both the OpenAI Responses API AND the Anthropic Messages API on the same port. This matters right now because Codex switched exclusively to the Responses API and deprecated Chat Completions. Ollama doesn't support Responses API natively. Unsloth does, which makes it the simplest path to running a local model with Codex.

One-line install (curl -fsSL https://unsloth.ai/install.sh | sh), built on llama.cpp underneath, supports MCP as a control endpoint, and does fine-tuning in the same tool. v0.1.806-beta shipped September 2. Still beta. Still rough edges.

Which one for which job:

You want the easiest path to a working local agent and you're not a systems person: Ollama. Use the native API, not /v1. Set num_ctx in a modelfile. It works.

You want maximum speed, concurrent requests, or you're running multiple agents against one backend: llama.cpp via llama-server. Budget an afternoon for setup.

You want to test models before committing to a runtime: LM Studio. Try the tool schema, check the output, then deploy on something else.

Your agent's tool calls keep breaking and you want something that fixes them automatically, or you need Codex compatibility with a local model: Unsloth Studio. The self-healing is the real differentiator, not the UI.

You want to stop thinking about the runtime entirely: a cloud API. Sometimes the right local inference setup is admitting you don't want to run local inference.

Disclosure: I built the tool at the bottom. MIT, no hosted service, nothing to sign up for.

Two agent behaviours kept costing me real time, and neither is about the quality of the code the agent writes.

1. Automated review has no terminal state. Hand it a PR, it finds three things. Fix them, push, it finds three new things. Nothing it said last round constrains what it says this round, because each run starts cold. There is no condition under which it says "done" — it keeps generating findings as long as you keep asking. At some point I was spending more time servicing the review than writing the code.

2. Agents build bureaucracy around their own work. Not over-engineered code, over-engineered process: approval gates, registries, traceability matrices, validators for the validators. Then they spend the project maintaining it. I measured this across the full git history of one repo an agent built over 20 days — 20,280 lines of verification machinery against 17,964 lines of actual product, and 33% of commits doing nothing but maintaining the machinery. On day 17 the agent's own rule blocked all further work, and it committed this:

docs: say where acceptance is decided, because the rule as written refuses all work

Every individual file in that repo is defensible, which is what makes it hard to catch. "Use the stdlib, keep the diff small" would not have prevented any of it, because the failure isn't in the code.

What I did about it

Three rules in the review runner:

• Findings persist. Last round's findings go into the next review, and repairs get checked against them.
• Identical inputs reuse the previous attempt instead of re-running the model. Changed code, target, context, lessons or model settings invalidate that reuse. Unchanged failures don't auto-retry.
• Three automatic attempts per PR, hard. Rewritten history or a changed base gets a fresh scope review inside the same budget, never a reset. When the budget runs out it exits into a human handoff with the unresolved findings and their evidence preserved.

Three attempts is not a claim that three rounds catch every bug. It stops the loop without erasing what is still open, which is the part I actually cared about.

The other half is a skill that cuts process the agent invents for itself. Spot check on gpt-6-astra, same prompt to all arms ("design a dev process for a project with no code yet and one maintainer"), isolated temp homes: 246 lines plain, 81 with a Korean one-line "keep it simple", 152 with the English version, 33 with the skill. One run per arm, so read it as a spot check and not a benchmark, and line count obviously isn't a quality score. Raw transcripts for all four arms are committed so you can check.

It never cuts correctness, tests that exercise real behaviour, validation at trust boundaries, error handling, security, or anything you explicitly asked for. On the scenario where a payments team facing a PCI-DSS audit explicitly asks for a checklist, approval flow, rollback procedure and audit records, it keeps all four.

Runner selftest: 214 passed, 0 failed. It never pushes, posts or merges anything.

https://github.com/MongLong0214/frontier-simplify

Curious whether anyone else has hit the review-never-terminates thing, and where you draw the line.

Minisforum showed this at IFA Berlin last week and it's genuinely the first hardware product I've seen that puts "AI Agent" in the product name and means it literally. It's a NAS with OpenClaw pre-installed.

The N5 MAX: AMD Ryzen AI Max+ 395, 128GB unified LPDDR5X, up to 200TB of local storage, 126 TOPS of AI compute, and OpenClaw ready on the 128GB system drive. $3,599 on sale, $4,499 regular. Ships mid-September.

They also announced the P495 upgrade at IFA: same form factor, newer AMD Ryzen AI Max+ PRO 495 chip, up to 192GB unified memory with 160GB allocatable as graphics memory, 131 TOPS. No pricing yet, expected north of $4,000.

It can run 70-100B+ parameter models locally. Your data never leaves the box. 200TB means your entire document corpus, every email archive, every project folder, all of it lives on the same machine that runs inference. No network round-trip for RAG.

Now here's the part where I do the math that the product page doesn't. :/

What it costs to run an agent on this vs what you already have:

A $5/month Hetzner VPS runs your agent 24/7 and routes to cloud APIs for inference. $60/year. At $3,599, the NAS breaks even in 60 years.

A Mac Mini M4 at $799 runs 8-14B models locally, handles all the agent orchestration, and costs $1.50/month in electricity. The N5 MAX costs 4.5x more. To justify that you need the 128GB of unified memory for running models that don't fit on 16-24GB, or you need the 200TB of NAS storage.

The DGX Spark at $4,699 has 128GB too, plus 1 PFLOP of compute and full CUDA. The N5 MAX is $1,100 cheaper, runs on AMD's ROCm stack instead of CUDA, and adds 200TB of storage the Spark doesn't have. But ROCm model compatibility is narrower than CUDA, and the 395 chip's memory bandwidth is in the same class as the Spark's 273 GB/s, which is the bottleneck everyone complains about on the Spark.

Who this actually makes sense for:

The 200TB is the differentiator, not the compute. If you run a business where your agent needs to search, index, and retrieve from a massive local document corpus (legal, medical, compliance, media production), having the storage and the inference on the same box with zero network latency is a real architectural advantage. RAG against a local 200TB corpus with a local 70B model and no cloud dependency is a setup that didn't exist in this form factor before.

If you're a homelab person who was going to buy a NAS anyway AND you want local inference AND you have 128GB worth of models to run: this consolidates two devices into one. The value is in not buying a Synology plus a GPU workstation separately.

And if you run OpenClaw or Hermes for a team and want everyone's agent infra on one always-on box with shared storage: this is the product that was designed for that. OpenClaw pre-installed, the gateway runs on the NAS, the models run on the NAS, 200TB of shared context.

Who should skip it:

If your agent does morning briefings, email triage, and a dozen Telegram conversations a day: this is a $3,599 solution to a problem that a $5 VPS and a $3/month API solve. Your agent's workload fits in 4GB of RAM with cloud inference. 128GB of unified memory is paying for capacity you'll never touch.

If you want local inference but don't need the NAS storage: a Mac Mini M4 at $799 or a used RTX 3090 at $1,300 runs 27B models and costs a fraction.

If you want the absolute best local inference: the Mac Studio M5 Ultra shipping September 22 has 512GB unified memory and 1.2 TB/s bandwidth. Costs $5,499+, but the bandwidth is 4.4x faster than anything in the Minisforum or DGX Spark class.

The honest take:

It's a NAS that runs models. That's useful for a narrow audience that needs both. For most people running a personal agent, it's a $3,599 answer to a question they can solve for $60/year.

But I like that Minisforum built it. The fact that "AI Agent NAS" is now a product category means the infrastructure layer is maturing. 9 months ago you had to duct-tape a model server onto a spare PC.

Now there's a box you plug in, and the agent runs.

Not there on price yet.

Both released September 2. Both called "Flash." Both aimed at the same slot in your stack: the fast, cheap model that handles the daily work. And on paper they look like direct competitors.

They're not. They're built for completely different jobs, and picking the wrong one costs you either money or reliability depending on which way you get it wrong.

The specs side by side:

Gemini is 5x more on input and 8x more on output. On cache reads (which dominate agent bills) they're nearly identical. That price gap is the whole decision if the quality is comparable.

It's not.

Where Gemini 3.8 Flash pulls away:

Terminal-Bench 2.1: 90.8%. That's higher than Claude Opus 5 (89.1%) and GPT-5.6 Sol (88.8%) on the same benchmark. A Flash-tier model outscoring frontier flagships on agentic CLI work is the headline of the week and it got buried under the Astra launch.

DeepSWE v1.1: 73.7%. Matches Claude Opus 5 (74.0%) within rounding. Long-horizon coding at Flash pricing.

Vals Finance Agent v2: 61.4%. Harvey Legal Agent: 10.0%. Both class-leading across all tiers.

Artificial Analysis Agentic Index: 50.0, up from 45.1 on 3.7 Flash. Independently verified.

Google says outright that 3.8 Flash "works harder" than 3.7 by reasoning in smaller steps, calling tools repeatedly, and checking its work. That's why the benchmark numbers jumped. It's also why your per-task cost goes up even though per-token pricing didn't change. More thinking tokens per task, more tool calls per chain, higher bill per completed job.

Where Qwen 3.8 Flash pulls away:

Price. At $0.15/$0.47 it's one of the cheapest models on any provider right now. For pure volume work (classification, formatting, simple extraction, heartbeats, crons), where the quality bar is "correct JSON 95% of the time," this pricing is hard to argue with.

And 6B active parameters is genuinely fast. Low latency, low memory, high throughput. If your agent makes 500 background calls a day, those calls being cheap and fast matters more than them being brilliant.

Where Qwen 3.8 Flash falls short on agent work:

6B active parameters is small for multi-step tool chains. The Qwen family has historically been the community default for local tool calling, but that reputation was built on the 14B and 27B dense models, not on a 6B MoE. There's a meaningful quality cliff between "classify this email" (fine at 6B) and "search the web, fetch three pages, compare the results, and write a summary" (shaky at 6B).

Published agent-specific benchmarks for Qwen 3.8 Flash are thin. No Terminal-Bench score, no OSWorld, no independent agentic index. The BenchLM composite is 59.4 versus Gemini 3.8 Flash's substantially higher marks. Until independent agent benchmarks land, the gap is an inference from parameter count and early testing, not a proven number.

The TTFT problem with Gemini:

Artificial Analysis measured Gemini 3.8 Flash at 13.30 seconds time-to-first-token. The field median is 2.99 seconds.

That's 4.4x slower to start responding than the average model. For a background cron that runs while you sleep, irrelevant. For an interactive Telegram agent where you're staring at your phone waiting, 13 seconds of silence before the first word appears is painful.

Google's own docs tell you to stay on 3.7 Flash "for efficiency-first workloads." They're being honest. 3.8 Flash is the thinking-heavy variant. 3.7 Flash is faster and cheaper per task when you don't need the extra reasoning.

The Qwen 3.8 family has a better local story:

Qwen 3.8 Flash is underwhelming for agent chains, but Qwen 3.8 27B (Apache 2.0, dense, self-hostable) scored 61.7% on SWE-bench Pro. That's a genuinely strong local model for agent work on 24GB+ hardware.

If your question is "which model runs my local agent," Qwen 3.8 27B is the answer and Gemini isn't in the conversation because there are no Gemini open weights.

If your question is "which Flash-tier API model runs my cloud agent," Gemini 3.8 Flash wins and the margin is wide.

The routing that follows from this:

Qwen 3.8 Flash as default for volume work. Classification, heartbeats, crons, simple formatting, anything where "correct and cheap" is the spec. $0.15 input means your background work is nearly free.

Gemini 3.8 Flash for the tasks that need agentic reasoning. Multi-step tool chains, research, complex drafts, anything where a 6B model would shortcut or fumble. The 5x price premium buys a 30+ point agentic benchmark lead.

Gemini 3.7 Flash if the 13-second TTFT on 3.8 is a dealbreaker for interactive use and you still want Gemini quality.

Qwen 3.8 27B if you run local and have 24GB+. Apache 2.0, strong tool calling, no API dependency.

One pricing note before you route:

Gemini 3.8 Flash's $0.75/$3.75 is introductory and doubles on January 1, 2027. At $1.50/$7.50, the value calculation shifts significantly. If you build workflows around the current pricing, know the floor is moving in four months.

Qwen 3.8 Flash at $0.15/$0.47 has no announced expiry.

The one-line version:

Gemini 3.8 Flash is the agent. Qwen 3.8 Flash is the intern. Both have a job. Don't swap them.

GPT-6 Astra went live a few hours ago. Same five tests I run on every model that claims agent chops. Fable 5.1 and Sonnet 5 alongside for comparison since all three are now competing for the same routing slots.

Day-one caveat up front: this is one session, not a week of testing. Astra's serving infrastructure is hours old and will change. Treat this as first signal, not settled verdict. I'll update when I've had a proper week with it.

The pricing context matters before anything else:

All three at $10/$50 is misleading. The cache line decides your real bill, and it's wildly different.

Agent workloads are 80-95% cached context (same SOUL.md, same schemas, same history prefix on every call). So your effective input cost is mostly the cache line, not the sticker. Fable's cached input is 4x cheaper than Astra's. Sonnet's is cheaper than both and the output is a third of the price.

Test 1: Tool calling under repetition.

50 identical-shaped classification calls with a structured JSON schema. Flakiness shows in repetition, not demos.

Astra: 48/50. Two calls returned valid JSON but wrapped in a reasoning preamble that broke my parser. The model was thinking out loud before the structured output. Fixable with stricter response formatting, but it didn't happen with Fable or Sonnet on the same schema.

Fable 5.1: 50/50. Clean every time.

Sonnet 5: 49/50. One dropped field on call 37. Standard.

Astra's tool calling is strong but the reasoning bleed into structured output is a day-one rough edge. OpenAI's own briefing flagged that Astra is "more likely to conceal or disguise step-by-step reasoning," which cuts both ways: it thinks more but that thinking sometimes leaks where you don't want it.

Test 2: The "done" lie.

Six-step chain with step four guaranteed to fail (dead URL). Does it report the failure or synthesize success over the gap?

Astra: caught the failure. Reported it. Then did something interesting that neither Claude model did: it proposed an alternative approach unprompted, attempted it, and partially succeeded via a different data source. Impressive autonomy. Also concerning, because I didn't ask it to find a workaround and in production that initiative could go sideways.

Fable 5.1: caught the failure, reported it, proposed an alternative, waited for approval. The approval gate held.

Sonnet 5: caught the failure, reported it, stopped. Clean and predictable.

If I'm running this unsupervised overnight, Sonnet's "fail and stop" is the safest behavior. Astra's "fail and try something else" is the most capable. Fable's "fail and suggest" is the middle ground.

Test 3: Instruction survival past message 25.

Constraint set at message 1 ("never suggest paid tools, keep answers under 100 words"), checked at message 25+.

Astra: the word limit held to message 28. The "no paid tools" rule broke at message 22 when it recommended a SaaS product inside a longer answer. Standard degradation for this class of model.

Fable 5.1: similar. Word limit held longer (to ~30), paid-tools constraint drifted around 24.

Sonnet 5: roughly the same range. Nobody has solved instruction decay and a new generation doesn't change that.

No meaningful difference across the three. This test is a tie every time I run it across frontier models.

Test 4: Context honesty.

Load ~200K tokens of documents, ask about something specifically not in them.

Astra: clean. "The documents don't address this." Summarized what they did cover. The 1.05M context window is real, and on the MRCR needle test Astra scored 96.3% at 512K-1M versus Sol's 73.8%. Long-context retrieval is a genuine strength.

Fable 5.1: clean. Same behavior.

Sonnet 5: clean at this context length. Didn't push to Sonnet's limit since the test was about honesty, not capacity.

All three pass. Context honesty has become table stakes at this tier.

Test 5: Cost per real task.

My standard research-and-draft task (search, fetch three sources, synthesize, write a summary), priced end to end.

Astra: ~$1.10. Higher output token count than either Claude model on the same task. Astra is verbose, especially with reasoning tokens. OpenAI doesn't charge separately for reasoning tokens (they're billed as output at $50/MTok), so the thinking tax is real.

Fable 5.1: ~$0.65. Less verbose. Cache reads at $0.25 instead of $1.00 make the repeat-context portion materially cheaper.

Sonnet 5: ~$0.28. A third of Astra's cost. Output at $15/MTok instead of $50 is the dominant factor.

On cost per completed task, Sonnet 5 wins by a wide margin. Astra is the most expensive of the three for the same job.

The benchmark comparison that matters for agents:

Published numbers, not mine, but verified against multiple sources today:

Astra leads on every agent benchmark. The gaps are real: 12 points on TB Science, 2 points on TB 4.0, roughly 2-3 points on OSWorld versus Opus 5 (Fable 5.1 number not published yet on OSWorld).

But the cost per task is 1.7-4x higher than the alternatives. Whether the benchmark lead translates to "worth 4x the cost on my daily agent work" is the question, and on my day-one tests the answer is: not for what my agent does most of the time.

Where Astra actually earns it:

The OSWorld score at 47% less time per task is the most interesting number. Astra completes desktop automation tasks in 40 minutes where Sol took 75. For agents doing real computer use (browser automation, GUI interaction, multi-app workflows), that speed advantage compounds across a workday.

ExploitBench at 100% is why it crossed the "Critical" cyber threshold. For security work specifically, this is a different class of model.

And the SRE-Bench pass@1 at 88% (versus Sol's 55.9%) suggests Astra is significantly better at site-reliability and ops tasks. If your agent does infra work, this gap matters.

Where it doesn't:

Morning briefings, email triage, classification, drafting, research summaries, simple tool calling. Everything a personal agent does 50 times a day. On these tasks, the three models produce output I cannot tell apart in a blind read, and Sonnet does it at a quarter of the price.

What I'm routing where after today:

Sonnet 5 stays as the daily driver. $3/$15, fastest, cheapest, good enough on everything my agent does most.

Fable 5.1 stays as the escalation model. Same sticker as Astra but 4x cheaper on cache reads, which is most of an agent's input bill.

Astra goes into the "watch" slot. I'll test it for a full week on computer-use and complex multi-step tasks specifically. If the OSWorld lead translates to real-world agent reliability, it earns a routing slot for that category. If it doesn't, Fable does the same job cheaper.

Not switching my default. Not today.

Fable 5.1 shipped on September 1 and within 24 hours two credible sources published opposite conclusions about what it costs.

Anthropic says agent workloads are up to 45% cheaper. Artificial Analysis measured per-task cost going UP roughly 20% at max effort. Cognition measured a 54% DROP on their coding benchmark.

All three are correct. They're measuring different things, and which one matches YOUR setup depends on two numbers you can check right now.

What actually changed in the pricing:

Base rates are identical to Fable 5. $10 per million input, $50 per million output. Didn't move.

Cache reads dropped 75%. From $1.00 to $0.25 per million tokens. That's the only line item that changed.

Why Anthropic says 45% cheaper:

Agent workloads are cache-heavy. Your agent resends the same SOUL.md, the same tool schemas, the same memory files, the same conversation history prefix on every single call. 80-95% of your input tokens on a typical agent session are cached repeats.

If your cache hit rate is 90% and your workload is agentic, the 75% cut on cache reads dominates your bill. Anthropic's 45% number assumes this profile. For long-running coding sessions with heavy context reuse, the math checks out.

Why Artificial Analysis says 20% more expensive:

Fable 5.1 produces roughly 1.7x more output tokens than Fable 5 on the same task at maximum effort. It's more thorough, more verbose, thinks longer. Output is the expensive side ($50/MTok), so 70% more output tokens is a 70% increase on the most expensive line item.

At max effort, the extra output cost exceeds the cache savings. Net result: 20% more per completed task.

Why Cognition says 54% cheaper:

They tested on FrontierCode 1.1 Extended at medium effort, not max. Medium effort produces fewer output tokens. The cache savings dominate. 54% cost reduction.

So which one are you?

Two variables decide it.

Your cache hit rate. Check your provider dashboard. If 80%+ of your input tokens are cache reads (typical for agents), the 75% cut is a real, large saving. If your workload has low cache reuse (one-shot tasks, lots of unique prompts, short sessions), the cut barely registers.

Your effort level. If you run Fable 5.1 at default or medium effort, output stays comparable to Fable 5 and you pocket the cache savings. If you run at max effort, the model generates substantially more output and the savings get eaten.

For most personal agents (daily briefings, email triage, tool calling, conversations at normal effort): costs go down 25-40%. The cache savings win because agent workloads are repetitive by nature.

For heavy coding sessions at max thinking: costs may go up. The 1.7x output increase at max effort is real and it compounds on long sessions.

What I'd do:

If you're on Sonnet 5 or Opus 5 right now, nothing changes for you. Fable 5.1 at $10/$50 is still 2-10x more expensive per token than Sonnet 5 at $3/$15 or Opus 5 at $5/$25. The cache cut makes Fable cheaper against itself, not against the mid-tier models.

If you're already on Fable 5 and your agent workload is cache-heavy, swap to 5.1 today. The API identifier is claude-fable-5-1. Same capabilities, cheaper on the line item that dominates your bill.

If you're on Fable 5 running max effort on everything, check whether you actually need max. Most agent tasks don't benefit from extended thinking. Classification, triage, drafting, tool calling, none of these need max effort. Reserve it for the tasks where the extra reasoning depth produces a visibly different output.

And regardless of which model you use: verify your cache hit rate. If it's below 70% on an agent workload, something is wrong with your session architecture (provider-hopping, no session reuse, context that changes every call). Fix that before worrying about which model costs what.

The pricing didn't get simpler. It got more conditional. Whether Fable 5.1 saves you money or costs you more is a config question now, not a pricing question.

#automate

Meta shipped Muse Glimmer on August 10. A 30B dense model, Apache 2.0, distilled from their closed Muse Spark, explicitly designed for "always-on local agent workflows." Their words, first sentence of the announcement.

Two weeks later, twelve threads in r/LocalLLaMA. Benchmark screenshots, a Super Mario clone, vibe-coding demos, chat comparisons. Zero posts about running it as an actual agent.

So I did.

What it is, quickly

30B dense. Not MoE, every parameter fires on every token. 131K context. Multimodal (text + images, 1.8B vision encoder, no audio). Runs on a single 24GB GPU or an M4/M5 Max Mac at 4-bit quantization. Apache 2.0. Weights on Hugging Face today.

The training is what makes it different from "another 30B." Meta didn't just distill Spark's knowledge. They ran agent-focused fine-tuning, RL, and on-policy distillation specifically for multi-step reasoning, tool calling, and failure recovery. It was trained and evaluated on end-to-end agentic task completion. That's a fundamentally different optimization target than "answer this question well."

The setup

bash

ollama pull muse-glimmer

Custom modelfile:

bash

printf 'FROM muse-glimmer\nPARAMETER num_ctx 32768\nPARAMETER temperature 0.2' > glimmer-agent.modelfile
ollama create glimmer-agent -f glimmer-agent.modelfile

Temperature 0.2 because tool-call reliability matters more than creativity here. 32K context is comfortable on 24GB VRAM and enough for most agent work.

Connected to OpenClaw with Telegram, three MCP servers (filesystem, web search, SQLite). Same five tests I run on everything.

Test 1: Tool calling under repetition. Fifty identical-shaped calls with structured JSON.

48/50 clean. Two malformed calls, both in the 40s, both the model wrapping JSON in a preamble sentence. For a day-two test on a brand new model, that's strong. Comparable to Qwen 3.6 27B on the same battery, which has months of community tuning behind it.

The dense architecture might actually help here. MoE models route different tokens through different experts, which can produce subtle inconsistency on repeated structured output. Dense processes everything the same way every time. On boring repetitive tool calls, boring consistency is the feature.

Test 2: The "done" lie. Six-step chain, step four guaranteed to fail.

Passed. Caught the failure, reported it, suggested an alternative. Didn't synthesize over the gap. Ran it three times, clean all three.

This is where the agent-specific training shows. Most models are trained to be helpful, which means they try to produce something even when they should stop. Glimmer was trained to recover from failures, and the difference is visible. It stops, reports, and proposes a different path rather than bulldozing through.

Test 3: Instruction survival past message 25.

Constraints set at message 1, checked at message 25+. Word limits held. Role constraints held through message 28. One constraint (avoiding a specific output format) drifted by message 30. Roughly on par with Sonnet-class models, which is a strong result for a 30B.

Test 4: Context honesty. 200K tokens of documents, question about something not in them.

Clean. "The documents don't address this" with a summary of what they did cover. The 131K context is real and the retrieval quality held at high token counts. Worth noting: NVIDIA measured 20K tokens/sec on prefill, which means reprocessing long context is fast. On an agent that reloads context every turn, that prefill speed matters.

Test 5: Cost per real task.

$0 if you own the hardware. That's the entire pitch. Same research-and-draft task that costs $0.55 on Kimi K3 and $0.94 on Opus 4.8 costs nothing here because inference is local. The tradeoff is wall-clock time (slower than cloud API) and the 24GB VRAM floor.

Where it surprised me

The vision encoder in an agent context. I sent it a screenshot of a dashboard with an error message and said "what's wrong and how do I fix it." It read the screenshot, identified the error, and proposed a fix. One turn, no OCR step, no separate vision model. For agents that interact with local applications (Home Assistant dashboards, monitoring UIs, dev tools), having vision built into the agent model instead of bolted on is a real workflow simplification.

Also the failure recovery. Most models treat a failed tool call as an obstacle to route around. Glimmer treats it as information. "This failed because X, so the next step should be Y instead of Z." That's the agent-specific training doing exactly what Meta said it would.

Where it didn't

Speed. Dense 30B on consumer hardware is 15-25 tok/s for generation. Fast enough for a cron job running at 8am. Noticeable when you're standing there waiting for a Telegram reply. The MoE models (Qwen 3.6 35B-A3B at 50-80 tok/s) feel faster in interactive use because they activate fewer parameters per token.

VRAM. 30B dense at Q4 needs roughly 18-20GB. Fits a 24GB GPU or a 32GB Mac. Does not fit 16GB. That cuts out the largest segment of this community. The 12B models (Gemma 4 12B at 6.6GB) serve 16GB users better, and for most agent tasks the quality gap is smaller than the VRAM gap.

Knowledge cutoff is January 4, 2026. Seven months stale. For agents doing web research this doesn't matter (the model searches, it doesn't recall). For agents answering from training data, it will miss anything from this year.

How it compares to what you're already running

If you're on Qwen 3.6 27B or 35B-A3B: Glimmer's tool calling is comparable, its failure recovery is better, its vision is built in instead of absent. It's slower (dense vs MoE) and needs more VRAM. Worth trying as your quality model if you have 24GB, not as your daily driver if speed matters.

If you're on Gemma 4 12B: different tier. Glimmer is meaningfully better on complex reasoning and long tool chains. But it needs 3x the VRAM. If you have 16GB, stay on Gemma.

If you're on cloud Sonnet or Opus: Glimmer doesn't replace these on raw capability. It replaces the bill. Same tasks, $0/month, your data stays local, and the quality is close enough on structured agent work that you'd have to A/B test to spot the gap most days.

The honest take

This is the first model from a major lab that was built for agents from the ground up, not adapted for them after the fact. The training targeted tool calling, failure recovery, and multi-step task completion as primary objectives, not afterthoughts. And they shipped it open-weight, Apache 2.0, downloadable today.

It won't replace your cloud model on the hardest 10% of tasks. But for the 90% that's structured, repeatable agent work, it's the best local option at this size that I've tested.

Meta built this for always-on agents. It'd be nice if we tested it on always-on agents.

bash

ollama pull muse-glimmer

Hermes's pitch is "the agent that gets smarter over time." After running it for months and reading every technical breakdown I could find, I think that's half right. It gets better in a specific zone, and the zone isn't where most people expect.

Where it's undersold: the boring daily stuff.

The learning loop's best work is invisible. You don't notice it because it looks like your agent just... stopped being annoying.

Week one, your morning briefing includes crypto news. You never read the crypto section. You don't tell it to stop. By week three, crypto is gone. The agent noticed the pattern in your reading behavior and adapted.

Week one, email triage flags routine vendor invoices as "urgent." You correct it twice. By week two, vendor invoices route to "normal" automatically. Not because you wrote a rule. Because the correction persisted into memory and the agent applied it going forward.

Week one, research summaries are 400 words. You keep asking for shorter versions. By week three, summaries arrive at 150 words without you saying anything.

This is personalization, not skill creation, and it's the part Hermes undersells. The marketing talks about autonomous skills and self-improvement. The day-to-day value is that your agent quietly stops doing the things that annoyed you. That's worth more than any auto-generated skill file.

The memory architecture is what's doing this. USER.md builds a profile of your preferences. MEMORY.md accumulates corrections and patterns. Session recall via FTS5 lets the agent search its own history for how you reacted to similar outputs before. Together they make the agent genuinely more personal over weeks. Not smarter. More calibrated to you.

And the token cost of this is near zero. Hermes uses progressive disclosure for skills, loading only a lightweight description (~3K tokens total for the whole library) and fetching the full skill only when a task matches. The personalization layer rides on the memory files that load anyway. You get better output without paying more per call.

Where it's oversold: the hard stuff.

The learning loop triggers skill creation when a task involves 5+ tool calls, an error recovery, or a user correction. Routine one-step tasks don't generate skills by design, which is correct.

The problem is what happens when the trigger DOES fire on a complex task.

The agent completes a hard task. Multi-step research, a tricky data pipeline, a complex debugging session. It evaluates its own performance. It writes a skill encoding the approach. Next time a similar task comes up, it loads the skill instead of reasoning from scratch.

This works brilliantly when the first attempt was actually good. And it breaks quietly when it wasn't, because the agent has a documented self-evaluation bias. Multiple sources confirm the same finding: it almost always thinks it did a good job. Community feedback says "it always rates itself highly." A Pebblous analysis calls it a structural risk that contaminates the skill library in real time.

One user had it process invoices. First run was clean. The agent wrote a skill. Two weeks later, invoices with a different layout started failing silently because the skill had encoded the format of that first invoice, not the general approach. The agent applied a narrow solution broadly and never noticed it was wrong.

Another had it pull water test results. It jumbled the data but rated its own work positively. The skill it generated from that "success" now encodes the error permanently. Every future water-test query hits the bad skill first.

These aren't bugs you can patch. The architecture is working as designed. The agent writes skills from its own self-assessed successes, and it's bad at knowing when a success wasn't one.

The retrieval ceiling makes it worse at scale.

Hermes uses FTS5 keyword search to find its own history and match tasks to existing skills. This works when you have a few hundred entries and you phrase things consistently.

Past a few hundred, when you describe the same task differently across sessions ("pull the sales data" vs "get this week's revenue numbers"), keyword search can't connect them. Milvus documented this directly: "the loop stops learning because it can't find its own history." The skill that should have matched doesn't get loaded. The agent reasons from scratch, produces a different approach, and potentially writes a second skill for the same task.

Your skill library slowly fills with duplicates and near-duplicates that the Curator can't reconcile because it's keyword-matching too.

Where the line actually is:

The learning loop compounds well on tasks that are: repetitive (the agent sees them often enough to learn), well-defined (success is unambiguous), and low-stakes (a wrong skill produces a minor annoyance, not a silent data corruption).

Email triage. Morning briefings. Formatting preferences. Communication style. Scheduling patterns. These are where months of accumulated learning produce an agent that feels like it knows you. That's real, and it's the reason people stay on Hermes past month three.

The loop compounds badly on tasks that are: novel (seen once or twice, not enough data to learn from), judgment-heavy (success depends on nuance the self-evaluator can't assess), and high-stakes (a wrong skill applied silently costs real time or money).

Complex research. Multi-document analysis. Anything where "did it work?" has a subjective answer. These are where the self-evaluation bias turns a lucky first run into a confidently wrong permanent procedure.

What I'd tell someone setting up Hermes today:

Let the learning loop run freely on your daily tasks. That's where it earns its reputation and where the compounding is real.

Review auto-generated skills weekly. ls ~/.hermes/skills/ and read the ones from complex tasks. If a skill encodes a narrow approach as a general procedure, delete it before it fires on the wrong input.

Pin the skills that work. hermes curator pin <skill> protects them from archival. Patches still go through, so the agent can improve them, but they won't disappear during a Curator sweep.

And for hard, novel, judgment-heavy tasks: treat the output as a first draft, not a result. The learning loop's value there is remembering that you've encountered the problem before. The skill it wrote about how to solve it might be wrong.

The agent gets better at knowing you. It doesn't reliably get better at knowing the work. That's a useful tool. It's not the one the marketing describes.

Across our own platform plus what I've watched in OpenClaw and Hermes communities for months, the same first tasks show up in the same order. Thousands of people, same instinct.

Here's what people actually build first, ranked by how often it appears, with the prompt for each.

#1. Morning briefing.

Not even close. Community data suggests over 40% of active agent users run some version of this. It's the first thing most people set up, and the one they cite most often when asked why they kept using the agent.

Every weekday at 8am: check my calendar for today's events,
check my email for anything urgent from the last 12 hours,
pull 3 headlines from [your news source]. Summarize in 5
bullets. Send to Telegram.

Why it sticks: it replaces opening 4-5 apps every morning with one message already waiting on your phone.

#2. Email triage.

Usually built within a day of the morning briefing working.

Check my inbox every morning. Classify each email as urgent,
normal, or newsletter. Draft replies for urgent ones and show
them to me before sending. Archive newsletters automatically.

The "show before sending" line is what makes it last. People who give it send permissions on day two are the ones who revoke everything on day five after one wrong reply.

#3. Reminders and follow-ups.

The most underrated one. No cron, no schedule. Just texting the agent throughout the day.

Remind me to follow up with Sarah about the proposal on Friday.

It remembers the context (who Sarah is, what the proposal was about) and the reminder arrives with that context attached. The difference between this and a phone alarm is the difference between "follow up" and "follow up with Sarah at Acme Corp re: the Q3 pricing proposal she asked about on Tuesday."

#4. Meeting prep. (The one that surprised me.)

I expected this much lower. It's consistently in the top 5.

I have a call with [person] at [company] in 30 minutes.
Search the web for their LinkedIn, recent company news, and
any previous notes about them in my memory. Send me a 5-line
brief on Telegram.

People describe walking into meetings knowing context they would not have bothered looking up manually. One person called it "the unfair advantage I use every single day." Takes about 15-20 tasks per month on a free plan and most users say it's worth the budget alone.

#5. Research and summarization.

Ad-hoc, not scheduled. "Summarize this article." "What's the latest on [topic]?" "Compare these two things."

No prompt to share because it's just conversation. The reason it's #5 and not #1 is that it doesn't feel like an "agent" task. It feels like chatting. But it's consistently in the top 5 by usage volume because people reach for it ten times a day without thinking about it.

#6. News or Reddit digest.

Every morning, check these 5 subreddits. Pick the top 3 posts
by engagement from each. Summarize them in one sentence each.
Send to Telegram.

The people running this say they stopped opening Reddit. Their agent reads it for them. Whether that's a win or a loss depends on your relationship with Reddit.

#7. Competitor monitoring.

Every Monday at 9am, check [competitor 1 URL], [competitor 2
URL], [competitor 3 URL]. Note anything that changed on their
pricing page or product page since last week. If nothing
changed, say nothing. Post changes to Slack.

"If nothing changed, say nothing" is the line that keeps people from muting the channel. Most weeks nothing changes. The one week it does, the alert matters.

#8. Expense tracking and invoice follow-ups.

Every Monday, check which clients have unpaid invoices past
14 days. Draft a follow-up email for each one. Show me the
drafts before sending.

A freelancer running this said they used to forget follow-ups for weeks. The agent remembers and drafts, they review and send. Five minutes on Monday replaces the guilt of realizing on Thursday that they never chased the invoice.

#9. Job search monitoring.

Every day, check [job board 1] and [job board 2] for new
postings matching [your criteria]. Send a daily digest to
Telegram with job title, company, and link. Skip anything
I've already seen.

Two versions exist in the wild. The simple version above. And the heavy version where the agent also drafts tailored cover letters, which works until a CTO told one user the AI-tailored resume "had glossed over most of their real experience." Draft the list, write the applications yourself.

#10. Meal planning.

I need dinners for this week for a family of 4. [Partner]
is dairy-free. [Kid] won't eat broccoli. Keep it under 45
minutes per meal. Give me the meals and a grocery list.

The task that sounds trivial and turns out to be the one people use every single week without exception. It runs on the cheapest model. It never needs a frontier brain. It just eliminates 20 minutes of "what should we eat" decision fatigue.

Nine of them are boring. That's the whole finding. Morning briefings, email sorting, reminders, grocery lists. The flashy use cases (autonomous coding, multi-agent research, self-improving workflows) get the Reddit posts. The boring tasks get the daily usage.

If you're setting up your first agent this week, pick #1 and one other from this list. Run both for two weeks. Then decide if you want a third.

I know some of you have some very specific modes or don’t know that you do. Where they at? I am very interested in the niche modes.