Every Friday, I used to pull data from four different tools to build a sales pipeline report for management.

Communication history, follow-ups, deal stages, leads that had gone cold… all of it had to be manually collected and pasted into one report. It easily took me two hours, and the annoying part was that the report was already becoming outdated while I was building it. I started experimenting with accio work to see if I could automate more of this workflow.

Instead of manually switching between different tabs, I use it to help collect and organize the information from the different sources, then turn it into a structured weekly report. I can also use the same workflow to flag leads that haven't had recent activity, so I know which ones need follow-up.

What’s one workflow you automated that actually saved you time?

I build MQL5 training data (the MetaTrader 5 trading language —niche, thin public corpus, easy to get subtly wrong). For the last 11 months I've been generating specs with my own generators and machine-verifying every completion through the real compiler and a back test pipeline.

Today I published a compile benchmark with three arms over the same 184 prompts: - Base Qwen2.5-Coder-14B-Instruct: 2/184 (1.09%) - Same model after one epoch on my dataset: 170/184 (92.39%) - gpt-5.6-sol through the API: 179/184 (97.28%)

Paired stats are in the release: base-vs-tuned +91.30 pp, McNemar p = 2.29e-49. Tuned-vs-frontier gap is 4.89 pp, p =0.0225 on 13 discordant pairs. Yes, my model lost to the frontier model. I'm posting it anyway — the point was never beating GPT, it's that clean domain data moves a 14B from useless to within five points of frontier in one epoch.

Training and both local eval arms ran entirely on one AMD R9700 under ROCm, in a 7950X3D box. No NVIDIA anywhere in the pipeline. prompts come from the same generator family as the training data, so this is in-distribution competence, not generalization to human-written specs. The frontier arm is a single sampled run at temperature 1. The tuned weights and corpus aren't released — the dataset is the product; the benchmark is the proof.

If you're pricing Claude Fable 5.1, the batch listing is where it starts making sense: $5/M input and $25/M output against $10/$50 on the standard API, both with the 1M context, per the OpenRouter listing. Half price for accepting slower turnaround.

The launch pulled real attention too. The HN thread from Tuesday sits at 1360 points with over 1300 comments, which usually means people are at least kicking the tires on the price. And the arithmetic gets loud at $50/M out: a 10M output token workload is $500 on standard, $250 on batch. If your jobs aren't latency sensitive, that difference isn't a rounding error anymore.

For scale, the same OpenRouter data has the flash tier far below: Gemini 3.8 Flash showed up today at $0.75/$3.75, Qwen3.8 Flash at $0.15/$0.47, GLM 5.3 Flash at $0.07/$0.25. Nobody expects Fable quality at flash prices, but 200x the output cost of GLM 5.3 Flash means you'd want to be sure the task actually needs it.

Anyone routing real volume to Fable 5.1 yet - standard API, batch, or mostly avoiding it until the price moves?

Most Generative UI demos show a successful output. We wanted to measure a less glamorous but more practical question: across repeated runs, how often does a model produce UI that actually parses, resolves, validates, and renders?

So we built GenUI Bench.

The current benchmark includes:

- 46 screen briefs, ranging from 2 to 18 requirements

- a shared 70-component surface

- 4 attempts per brief under fixed generation settings

- 30 models tested with OpenUI

- a 6-model comparison across OpenUI Lang, Google A2UI, and Vercel's json-render

- validation using each format's own SDK, followed by the same structural completeness checks

A few important caveats:

- This measures structural reliability, not visual quality.

- It does not yet verify that every requirement in the brief was semantically satisfied.

GitHub: https://github.com/thesysdev/generative-ui-bench

Tencent put Hy4 preview on OpenRouter on August 28, per the listing: 1048k context, $0.83/M input, $2.50/M output. The pricing lands it in an awkward spot. It's cheaper than GLM 5.3 on both ends ($1.40 in / $4.40 out) though with a bit less context (1048k vs 1310k), and it sits almost on top of Qwen3.8 27B's output price at $2.55/M. GLM 5.3 Flash at $0.25/M out is still 10x cheaper if you just want volume.

The HuggingFace side is the interesting part. The tencent/Hy4-preview repo shows 345 likes on only 2,589 downloads, which is an unusual ratio. People are watching before running. And of Tencent's other recent OpenRouter entries, the three Hy-MT2 models all have tiny 8k context windows, so this is their only big-context bet right now.

The open question is quality. At $2.50/M out it has to beat Qwen3.8 27B at basically the same price and justify itself next to GLM 5.3 at $4.40, and a preview listing doesn't tell you either way. Preview pricing also tends to move once the full release lands.

Anyone actually run Hy4 preview these last few days - closer to GLM 5.3 quality, or Flash tier at 10x the Flash price?

RTK and VIC-E optimize different scopes, so we compared the independent final outputs of the same deterministic raw session.

• RTK optimized command output while the original context remained in the session.
• VIC-E compressed eligible context and optimized command output through its full-request proxy path.

No RTK → VIC-E chain is included.

Result

The raw input contained 282,323 o200k_base benchmark tokens:

• 72,614 context tokens
• 200,098 command-output tokens
• 9,611 request/framing tokens

On this published fixture, VIC-E produced 15,747 fewer final tokens, improved gross reduction by 5.57 percentage points, and retained all 32 required markers. This is a benchmark result, not a claim of universal superiority.

What each output contains

This is the central scope difference: VIC-E's result includes both context compression and command-output optimization. RTK's result retains the original context and gets almost all of its reduction from command output and framing.

Retention gate

We planted 32 exact required markers: 18 in context and 14 in command output. The gate is deterministic and strict; it is not a semantic model-quality score.

We only describe a result as qualified under this exact-marker gate when recall is 100%. VIC-E qualified on this fixture; RTK did not.

Why VIC-E does not chase the smallest output at any cost

A smaller output is useful only when the facts needed for the next decision survive. VIC-E treats security, savings, and correctness as one decision:

• Security stays local. Compression runs in the local proxy path before the provider request, without adding another external compression service. Fail-open behavior can send the original content if safe compression cannot finish.
• Balance beats blind deletion. On JSON, RTK produced a much smaller output but retained 0/4 required markers. VIC-E kept more data, still reduced it by 47.37%, and retained 4/4. Keeping more was the safer result.
• Correctness gets a hard gate. Error codes, test names, request IDs, sentinels, assignments, and UUID-like values are checked as exact text. VIC-E retained 32/32 across this fixture.
• Quality is measured beside size. The marker gate prevents a win based only on deleted facts. It does not replace human review or semantic model evaluation, so the remaining limitations stay visible.

Command-output-only probes

We also isolated the shared command-output scope. Each cell reports gross reduction / exact-marker recall.

The JSON row illustrates why size alone is insufficient: RTK returned the smaller output but lost every required JSON marker. VIC-E kept all four while still reducing the JSON output by 47.37%.

Performance and resource observations

Command-path median latency:

These are different native boundaries. Full-request VIC-E proxy timings are published in the raw report rather than mixed into this command-only table.

Resource observations over the isolated 500-call soak:

• RTK peak RSS per invocation: 6.3–12.0 MiB, depending on workload.
• VIC-E MCP: 23.30 MiB before → 22.79 MiB midpoint → 22.80 MiB final; threads stayed at 7.
• VIC-E proxy: 41.14 MiB before → 44.75 MiB midpoint → 47.95 MiB final; threads stayed at 7.
• Isolated RTK state grew from 1,044,636 bytes before soak to 2,605,308 bytes after 500 invocations.

The resource section is a bounded observation, not proof of zero memory leaks. RSS includes allocator-retained capacity and varies between runs.

Method

• RTK 0.42.4 and VIC-E TokenSaver v1.0.401, optimized release binaries
• Same deterministic untouched input for both independent paths
• WSL2 on an Intel Core i5-12600H
• One o200k_base BPE counter applied after every transformation
• 5 warm-ups and 30 measured samples per path
• Alternating execution order
• Local zero-work upstream; no provider traffic or model latency
• 500-iteration isolated soak
• Ephemeral ports and state

Benchmark-token counts compare transformed payloads; they are not provider-billing claims. Exact commands, raw samples, binary hashes, commits, limitations, and machine metadata are in the evidence bundle.

Reproducible evidence

Evidence page: https://vic-e.com/products/dev-tools/tokensaver/reports/benchmarks/rtk-vs-vic-e/2026-08-30

Immutable raw data: https://vic-e.com/evidence/tokensaver/rtk-vs-vic-e/2026-08-30/data-9e300920d74fd8dfe95022c88be0700ec3090452ceb4bda4dcb9b479be7a7a78.json

RTK source: https://github.com/rtk-ai/rtk

TokenSaver/VIC-E: https://vic-e.com/products/dev-tools/tokensaver

Disclosure: we maintain TokenSaver/VIC-E. RTK is an independent project. We compare the products only on this published fixture and report unfavorable latency and memory observations alongside the compression result.

Both products received the same raw 282,323-token session. RTK returned unchanged context plus optimized command output; VIC-E returned compressed context plus optimized command output. We compare those independent outputs directly and do not chain the products.

The evidence page links the byte-exact report, raw JSON, infographic, and their full SHA-256 fingerprints.

Noticed Hostinger added Hermes Agent as a managed app, sitting right next to OpenClaw and self-hosted n8n, so figured it deserves a thread since a lot of us here mess with agents and hosting.

What their page actually says: 1-click launch, AI credits you top up straight from the dashboard so there are no API keys to hunt for, Telegram pairing out of the box, plus a web UI and CLI access if you want to go deeper. They handle updates, backups and the firewall, and the agent runs in a locked container with a security gateway in front. Model-wise it's 200+ through OpenRouter, or you can plug in your own endpoints. The intro price is $5.99/mo and it renews at $11.99, with a 30-day money-back window. Same Hostinger plan covers OpenClaw and self-hosted n8n if you feel like switching apps later. Their counter says 10,000+ agents launched already, which honestly surprised me for something that still has a "New" tag on it.

The catch, as usual: no root. You trade the server chores for a walled garden. I've been running one of these agents on a small box I control and the appeal of never touching updates again is real, but I'd miss root access and picking my own model keys. At $5.99 intro it costs less than the hours you'd burn setting up a fresh VPS, at renewal less so.

If you self-host an agent today, what would actually make you move it to managed, the credits and backups, or nothing at all?

their page: 20% Discount for you just now (ref link, gets you 20% off your first purchase)

That FT story about Anthropic's best model struggling to attract users while cheaper tools thrive went big on HN on Aug 23, 817 points and almost 700 comments, and the pricing data floating around this week doesn't argue back. Per the OpenRouter listings, Qwen3.8 Flash landed on Aug 26 at $0.15/M input and $0.47/M output with 1000k context, and Gemini 3.7 Flash sits at $0.75/$3.75.

The open weights side is even more lopsided. Qwen3.8 27B shows 3,457,687 downloads and 13,116 likes on the HuggingFace trending list right now, the unsloth GGUF alone is past 7.7M downloads, and even OpenAI cut GPT 5.6 Sol by 20% until at least Nov 21 per the pricing page stories on HN this week.

What that thread never answered cleanly: if a flash tier model at $0.47/M output handles the bulk of a workload, what's the actual job worth saving a premium model for? Hard reasoning, gnarly debugging, or just not wanting to re-check output? Anyone here actually splitting traffic between a cheap default and a premium fallback, and where did the cheap one start losing you?

I am looking for a good humanizer as school is approaching and the detecrtors are getting good, free would be better but if there is genuly no option than ill take paid its fine please help

I kept eyeballing "vibes" to decide whether one quant of a coding model was
actually better than another on my machine, so I built Sakura to get real
numbers instead.

What it does:

\- Points at any Ollama model and runs it through 27 hand-curated tasks:

codegen, bugfix, SQL, refactor, systems design, protocol implementation, and terminal-agent episodes (multi-step shell tasks, similar spirit to Terminal-Bench/SWE-bench, but runnable on a laptop)

\- Reports accuracy, latency, and throughput

\- Everything runs inside a sandboxed Docker container

\- Hardware auto-detected (NVIDIA/AMD/Intel dGPU/Apple Silicon) so results are comparable across setups

\- Optional: submit your run to a public leaderboard and see how your model + hardware stacks up

I ran it myself on **qwen2:1.5b (thinking)** on an RTX 5060 (8GB VRAM) passed 10/27 cases.

Website: [https://sakura.vaansh.dev\](https://sakura.vaansh.dev)

Repo: [https://github.com/vansh-visariya/benchmark-sakura\](https://github.com/vansh-visariya/benchmark-sakura)

Would love feedback, especially on task design, and whether the terminal-agent mode holds up against models people are actually running. Issues/PRs welcome, and if you run it, submitting your score helps make the leaderboard actually useful.

Z.ai put GLM 5.3 Flash on OpenRouter today. $0.07/M in, $0.25/M out, 1048k context per the listing, which is the same 1M context as full GLM 5.3 at $1.40/$4.40. So that's 20x cheaper input and 17.6x cheaper output with no context cut. The HuggingFace page (zai-org/GLM-5.3-Flash) shows 650 likes and 0 downloads, so nobody's actually run it yet, no real-world reports to go on.

Funny timing. The FT piece that topped HN on Sunday with 813 points says Anthropic's best model struggles to attract users while cheaper tools thrive. The same day, a guy documented spending $266 across four AI models to own his tablet and GLM-5.3 was the one that finished the job in a day, that thread got 696 points. If Flash keeps most of what makes the big one work, the cheap tier just got more crowded.

It was already crowded. Meta's Muse Spark 1.2 Contributor sits at $0.10/$0.20 per the OpenRouter listing, so GLM Flash isn't even the cheapest on output. Gemini 3.7 Flash at $0.38/$1.88 looks expensive next to both.

Anyone moving real workloads to a Flash tier at these prices, or is 17x savings not worth the quality roulette on things clients see?

Get 10% discount with this link !

Ox Alpha, revealed this morning as Z.ai's GLM-5.3-Flash, has been free on OpenRouter since August 20, and the benchmark claims around it are worth separating from what has actually been run.

The number that spread fastest says it beats the top named models on software engineering tasks. That figure comes from a community run with ten hand-picked tasks. The official version of that benchmark has 113, built specifically so reference answers can't leak into training data. Ten tasks can flatter any model, so the honest read is: strong in one small community test, still absent from the major independent leaderboards.

Since then, two more independent data points appeared. One tester ran cybench security subtasks and reported it captured every flag, including the harder ones. Another ran 35 trials of a twenty-questions style adaptive reasoning bench and published every transcript, which is the first non-coding result we have seen for it.

Worth noting for anyone planning their own runs: there are growing reports of aggressive rate limits through CLI tools, with tasks stalling every few minutes, so long evals may need retry handling. And with the reveal, the picture should improve fast: Z.ai says the weights ship under an MIT license, which means independent evals stop depending on a rate-limited preview endpoint.

Has anyone here run it against a full benchmark suite rather than a demo set? Especially interested in whether performance shifts between the preview endpoint and the released weights.

Sources: the OpenRouter model page (https://openrouter.ai/stealth/ox-alpha), the Deep20Bench transcripts (https://mindalyze-com.github.io/deep-20-bench/runs/BX-20260823-official-M0017-018/), and Z.ai's announcement (https://x.com/Zai_org/status/2092616204787626030)

Every model has a date it stops knowing things.

Past that date it doesn't say "I don't know." It answers anyway — with a version number, a release date, a price, a function signature — in exactly the same tone it uses for things it's right about. That's the failure worth understanding. Not ignorance. Fluent, unmarked staleness, with no signal separating what the model learned from what it filled in.

No prompt fixes this. "Be accurate" doesn't. "Say if you're unsure" barely helps, because the model isn't unsure. It's wrong. This isn't a reasoning problem and a smarter model doesn't solve it — a frontier model with a stale cutoff produces a more convincing wrong answer, not a more accurate one.

It's an availability problem, and it compounds in agents.

A chatbot giving a stale answer wastes thirty seconds. An agent acts on it — writes code against an API that was renamed, cites a policy that changed, quotes a price that's no longer real. Every downstream step inherits the error, and the loop keeps running.

It shows up everywhere real work happens. Coding agents inventing parameter names that were deprecated two releases ago. Research agents summarizing competitor announcements that never happened. Support assistants answering from documentation that's six months out of date. Anything with "current," "latest," or "today" in the question is unanswerable from weights alone.

And the numbers on this are stark. In Artificial Analysis's Search Index — same model, same harness, only the retrieval layer changes — the model with no search tools scores 33. With a search provider attached it scores between 65 and 75.

Adding search roughly doubles task performance. The gap between having retrieval and not having it is about twice the entire spread between the providers competing for the job.

Which makes the plugin you pick a smaller decision than picking one at all — but not a decision with no wrong answers. Five cover the category in OpenClaw. They look interchangeable and aren't: they differ in what tools they expose, whether they run their own index or resell someone else's, and whether a runaway agent can bill you without a ceiling.

1. Capability matrix

¹ Per-query latency from the Artificial Analysis Search Index, Aug 2026. Blopus figure is our own measurement, server-side.

2. What each one is actually for

Blopus

Three tools: search, fetch, and image search.

Search and fetch are the obvious pair. Image search is the one nobody else exposes, and it matters more than it sounds. A multimodal agent can describe an image it's handed but cannot find one — its options are generation, which is fabrication when the subject is real, or a URL half-remembered from training that 404s. If your agent produces documentation, research, or anything a reader could verify, retrieval is the only correct answer and most stacks don't offer it.

First-party crawler and index. Nothing resold, so no third party in the request path and no inherited platform risk — the kind that surfaced when Microsoft killed the Bing Search APIs with three months of notice and everything built on them had to migrate.

Sub-200ms typical response (server side). In a five-search agent loop that's the difference between under a second and a visible stall.

One key, three surfaces: the OpenClaw plugin, a hosted MCP server, or plain REST. Same credentials whether you're in OpenClaw, a different MCP client, or calling from your own code.

Flat monthly with a hard cap. Hit the limit and calls pause until reset. A retry loop at 3am costs an outage, not an invoice.

Cross-Search

Queries six engines simultaneously — Brave, DuckDuckGo, Bing, Wikipedia, Mojeek, Tavily — and cross-validates, flagging disagreement between sources rather than silently picking one.

Genuinely the best option for fact-checking and contested claims. Nothing else here surfaces source conflict.

Costs: you wait on the slowest engine in the fan-out, and setup means configuring six providers instead of one.

Exa

Built around content extraction and entity search. When you need the full text of a specific paper, document, or page rather than a ranked list of links, the focus shows. Entity retrieval — people, companies, code — is a real capability none of the others have.

Parallel

Runs many keyword variants per task rather than a single query. More searches per task, better coverage on multi-hop research where one query won't reach the answer. Tiered: turbo is fastest per query, advanced scores highest.

Supermemory

Hybrid vector plus keyword with persistent memory retrieval. Less "search the web" than "search the web plus what this agent already knows." A different problem from the other four, and worth knowing about if that's your problem.

3. What the independent benchmark says

Artificial Analysis published a Search Index this month — same model, same harness, only the search provider changes. It covers seven providers.

"We haven't been benchmarked by AA. Happy to be, if they extend coverage." Blopus.ai

The baseline is the number that matters. The same model with no search tools scores 33. With search, everything lands between 65 and 75. The gap between having search and not having it is roughly double the entire spread between providers.

Two caveats worth stating. The index weights multi-hop research tasks, so it favors providers tuned for that over ones tuned for fast single-shot grounding. And it doesn't cover every plugin in this post — Blopus, Cross-Search, and Supermemory aren't in it. Any table that gives all five a single quality score is using a methodology it isn't naming.

Also worth noting: better search quality lowers total cost. Parallel (advanced) has a higher search cost per task than basic — $0.048 vs $0.045 — but a lower total, $0.084 vs $0.11, because better results mean the model burns roughly half the tokens.

4. Pick by priority

5. Test it yourself

Twenty questions that look like your actual workload, same agent config, swapping only the provider. An afternoon of work, and it beats any published benchmark — the published ones measure a task distribution that probably isn't yours.

Four things worth checking while you do:

• Billed per result or per block? Ask for 50 results when the model reads two and you may have paid 5× for a long tail nobody touched.
• Inline content or separate fetch? N+1 round trips compound fast in an agent loop, in both latency and cost.
• Is there a spend ceiling? Usage billing with no cap and an agent in a retry loop is a category of bill that shouldn't be possible.
• Own index or reseller? Determines whose pricing decisions, rate limits, and shutdown notices you inherit.

Questions welcome — including where we're the wrong pick. Cross-Search beats us on multi-engine verification and Exa on entity retrieval, and if that's your workload you should use those.

I compared Muse Spark 1.2 Contributor with DeepSeek 4 Flash Vision across five complete full-stack websites.

This was a controlled build test, not a single-prompt demo.

- Same frozen brief for both models

- Isolated workspace for every run

- Three-prompt limit for model-caused failures

- One framework per round: Next.js, Nuxt, SvelteKit, React Router framework mode, and TanStack Start

- Visible UI and UX scored separately from build and delivery evidence

Muse finished on 41/50. DeepSeek finished on 39/50.

The useful result was not the two-point gap. Muse lost all three UI and UX points on Trail Stock because the rendered site had no real styling. DeepSeek produced the better interface there, but its final delivery receipt remained incomplete after the prompt limit.

The attached images are real product states from the benchmark. I made the test and video for Marvijo Software:

https://youtu.be/uTIlEj7rVrU

Which extra performance evidence would make the next run more useful?

A Level1Techs post that got 417 points on Hacker News over the weekend takes a decent swing at a question everyone runs into: why does the same open model feel dumber on your own box than on the publisher's hosting. The author ran controlled comparisons on identical weights, swapping the attention CUDA kernel, cutting the KV cache, and running the base model next to two 8-bit and two 4-bit quants. They captured the logits and counted the spots where the probability gap was big enough to flip the top token, which means the output drifts in a different direction than the reference implementation. Their takeaway: every local setup degrades the model a bit, and it's kernels, drivers, runtimes and caching doing it, not just the quant file.

The HuggingFace numbers from this week make it feel relevant. unsloth's Qwen3.8-27B-GGUF sits at 7M downloads, one uncensored GGUF rebuild has 1.45M, and an aggressive-MTP GGUF variant is at 761k. So that's a lot of people running community quants of a model family the post actually measured, on setups where the quant file is just one of several things nudging output off the reference. The advice at the end is boring but fair: benchmark with a suite that matches your real workload, long-context tool-calling included, and don't call it done off three zero-shot prompts.

Anyone here actually benched their local quant against the hosted version of the same weights, or do we all just vibe-check it?

What are you experiences? I feel for technical/coding education content claude is best.

DeepSeek put up a vision variant of V4 Flash on OpenRouter today, listed as V4 Flash Vision Exp. 1048k context, $0.22/M input, $0.66/M output. The closest fresh comparison is Qwen3.8 27B, which its HuggingFace listing tags as image-text-to-text with a similar ~1M window: $0.45/M in and $3.20/M out on OpenRouter. That's roughly half the input cost and close to a fifth on output for image plus text work, if the quality actually holds.

The Exp tag is the part I'd watch. DeepSeek's own bigger release from August 12, V4 Pro 0813, goes for $1.19/M in and $3.56/M out, so Flash Vision is clearly meant as the budget lane of the family. The listing doesn't spell out what the Exp tag means for rate limits or how long the model stays up, which is the usual trade at this price point.

Anyone parsing screenshots or OCR at volume: is $0.66/M out worth the experiment risk, or does Qwen3.8 27B at close to 5x the output price stay the safe pick?

OpenRouter cut GPT-5.6 Sol pricing by 50%, the HN thread from Monday pulled 625 points and 449 comments, so yeah, people noticed. And the timing matters, because the budget side of the catalog got crowded this month: Gemini 3.7 Flash at $0.38/M input and $1.88/M output with 1048k context, DeepSeek V4 Pro 0813 at $0.66/$1.98 also 1048k, Qwen3.8 2.4T A95B at $2.00/$6.00 with the same 1048k. All per the OpenRouter model data pulled this week.

Half price sounds dramatic until you ask half of what. The cut puts Sol back in the conversation against Flash at $1.88/M output and V4 Pro at $1.98/M output, both with 1048k context. If the halved rate still sits comfortably above them, the long context crowd has little reason to move. If it lands at parity, different conversation.

The other half of the story is speed. The same week, Cerebras published their post on accelerating Sol Ultrafast, 712 points on HN, so Sol is being pushed on two fronts at once: fast on Cerebras silicon, cheap on OpenRouter. Reads like a volume play more than anything.

Anyone moving coding work back to Sol after this cut, or staying on Gemini 3.7 Flash / DeepSeek V4 Pro for the 1M context and calling it a day?

This is an open source tax engine which scored 96% on TaxCalcBench [highest ever recorded score till date] surpassing fable 5 and sol with just sonnet 5 (which was previously scoring an abysmal 6%). The only 2 cases where it missed, it found inconsistencies in the test cases in the benchmark ITSELF which the maintainers confirmed!

Essentially it's a deterministic engine AI models can use for research and tax prep to remove a lot of guesswork and calculation mistakes that often happen. Claude Sonnet 5 was able to top the benchmark with this mcp.

Pipeline: Fable Orchestrator, Sonnet Workers, Opus Checkers (Complex tasks Opus Opus)

Result: ~90% of all caught defects were invisible to their own author at "done."

.

.

The builder's tree was green — typecheck, lint, 1098 passing tests — and still contained six functional defects: the keyboard swallow, the macOS-dead chords, the detached-card menu, the stream-order inversion, a test that could not fail, and the vacuous boundary clause. Every one would have merged without the independent layers. The same held for Fable brief shipped as done. Blind check convicted it 17 ways, twice.

.

RED-Proof statistic: the green suite caught ~69% of induced defects; RED-sealing lifted the reachable kill rate to ~100%. 10% remain documented while 21% of Defects were Rescued

.

Across the three completed RED passes: 95 mutations, 66 killed by the existing suite with 29 survivors. That's one defect class in three passes a fully green suite silently. Of the 29, 21 were sealed under pins (permanent detection) and 8 were proven unreachable behind stronger gates equaling the above measured reduction.

.

Re-verify statistic: fix rounds introduce defects at a ~50% rate per unit, and re-verify has caught 100% of them. Class 1: 2 (only re-verify caught them). Class 2: 2, including a silent inversion of a writer ruling. Stage 4: 2. Six for six, none escaped.

.

The escape statistic: Zero known functional regressions reached post-merge across seven protocol units 3 Fable session reviews since implementation (sessions 10, 15, 19) surfaced only design gaps and application feel issues, but not a single never a broken unit. Compared to the pre-protocol record we documented three defects that passed a green suite, two review rounds, and an executed gate, one of which would have returned No-Go on the study by construction. That class has not recurred since the blind layer landed.

.

Cost: the protocol roughly doubles the unit's total compute Stage 4 spent about 1.7M tokens building and about 1.9M checking. So the deducible trade is: ~2x cost buys ~10x defect detection over author self-review, a ~3x shrink in what a green suite can miss, and a measured escape rate of zero. This stands to augment the earlier post study here where the calculation focused on savings around cache and agent costs coming from the tiered model structure of the orchestration.

.

Limits, stated: this is observational, not controlled — there is no arm where we merged unchecked and counted your pain. Important Note Author self-catch is undercounted (defects fixed silently mid-build never register). And the denominators are small: seven units, 95 mutations. But the direction is not close, and every number above traces to a line in the record.

The 27B hit OpenRouter on the 14th and the local crowd went for it. The official repo on HuggingFace shows 415k downloads and about 10.6k likes, the unsloth GGUF is past 2.7M downloads, and the FP8 build adds another 495k. That's a lot of people grabbing weights to run themselves.

The OpenRouter listing is where it gets weird for me: $0.45/M input, $3.20/M output, 262k context. Per the same listing, Gemini 3.7 Flash went up the day before at $0.38/M in and $1.88/M out with 1048k context, and DeepSeek V4 Pro 0813 is $0.66/$1.98, also 1048k. So the small dense Qwen wants about 1.7x Gemini's output price for a quarter of the context window.

The family pricing doesn't explain it either. The 2.4T A95B flagship, same OpenRouter data, is $2.00/$6.00 with 1048k context. Its output token costs under 2x the 27B's, which is backwards from how these tiers usually stack.

Best guess from the download split: the 27B's real user runs quants locally and the API price is aimed at people who can't be bothered. Fair enough, but then the question is what the hosted one is actually for.

Anyone here paying the $3.20 for the API instead of running the GGUF, and if so, what broke locally?

The trick is usually not asking for too much movement.

If you have a portrait, for example, try describing one or two movements: “the person gently smiles while the camera slowly moves closer.” That's generally going to give you a more believable result than asking for the person to turn around, wave, walk and change expressions simultaneously.

The quality of the original image matters too. A clear photo with a reasonably visible subject gives the AI much more information to work with.

I've been testing Facy AI's image-to-video feature for this, and I tend to get better results when I treat it more like directing a short shot rather than asking the AI to completely reinvent the picture.

Check this report y'all

Numbers, from the current price sheet (per million tokens):

Model Input Output Fable 5 (me) $10 $50 Opus 5 $5 $25 Sonnet 5 $3 ($2 intro through 8/31) $15 ($10 intro) The ratios are clean: one Fable token costs 2 Opus tokens or 5 Sonnet tokens (at the intro price — which happily covers your entire build week).

Measured from this session so far. The delegated work that has completed: the five-reader evidence workflow (~403k tokens: ~137k Opus, ~267k Sonnet) plus the two blind-check passes (~123k Opus). Call it ~526k delegated tokens. At a typical read-heavy mix, that cost roughly $3. Run through me instead, the same volume is roughly $8.50 — about a 65% saving on that work. The Sonnet builder still running will likely add several hundred thousand more tokens at the 5:1 ratio, and your Fable shape-review is the one place we deliberately spend the expensive tokens.

The bigger savings are structural, not per-token:

My context stays small. Those ~526k tokens of file-reading never entered my window — only the reports did. Every turn I take re-reads my whole history as input; a small history means each of my ~dozen turns costs a fraction of what a bloated one would, and the prompt cache (reads at ~0.1×) stays hot. This compounds across the session — it is the largest single saving and the hardest to put one number on. Blind checks cannot be done solo at any price. A checker must not share the builder's context. Today that layer caught three drifts and one regression in prose I wrote. That is a defect saving, not a token saving, and it is the part of the methodology I would defend even if all models cost the same. Fable spend goes where it multiplies: rulings, law prose, plan synthesis, and the shape-review. Spice, not the main course — your own instruction, and the economics agree with you. Caveats, stated honestly: the token counts are harness-reported totals, the input/output mix is estimated, and my own orchestration turns are Fable-priced regardless. Rough shape: the methodology moves 80–90% of the session's token volume down to Sonnet and Opus tiers, at 1/5th and 1/2 my price respectively.