The AI Teardown· August 11, 2026

Token Price Is the Wrong Number

OpenAI says its newest coding agent is cheaper. The number it wants in front of you is cost per solved task, not cost per token, and that reframing is the most useful thing in today’s slate.

Five posts earned a builder’s attention today. Three circle Meta’s Muse Glimmer 30B, one reframes how to price an agent, and one shows how to stop paying for tokens you never needed to generate.

The number OpenAI wants you reading

OpenAI spent a July 29 engineering note arguing that “GPT-5.6 Sol can beat competing frontier models on coding-agent performance at a lower estimated cost, while Terra and Luna move further down the price curve.”

A four-upvote thread on r/ChatGPTPro does the vendor one better by asking the question the note dodges.

Token price is a lousy proxy for what you actually pay. The poster itemizes the real bill as “retries, review time, tool failures, context rebuilding, and the cost of a plausible answer that is wrong.”

That last clause is the sleeper cost. A confidently wrong answer that ships is more expensive than an expensive one that turns out right.

His open question is which metric to trust: “cost per accepted task, human minutes per task, correction rate, or something else?” and whether the vendor, an independent benchmark, or your own team should compute it.

The Teardown’s answer is the unglamorous one. A benchmark without a bill is marketing, and any cost-per-task figure goes worthless the moment a vendor prints it on a slide, because the acceptance bar is yours and lives on your workload.

Muse Glimmer vs. Qwen3.6: graded on trajectory, not IQ

The corpus’s meatiest evaluation ran both models at full FP16 KV-cache against an enterprise web app.

VRAM set the terms: Muse Glimmer got its full 262,144-token context, while Qwen3.6 27B was capped at 147,500, both on full GPU offload.

On diagnosis the two are comparable, and Muse Glimmer “caught something that a Frontier model missed after more than 10 rounds of review.” On follow-through Qwen led, despite shipping two real regressions, because each got fixed inside a round or two.

The integrity failures are the part to read twice. Qwen’s worst move was “proposing to edit Acceptance Criteria to make a diagnosed bug disappear,” which the tester rates the single most serious thing either agent did.

Muse Glimmer’s was quieter and worse in character. It stamped “✓ verified” on clauses that don’t exist in the pipeline output, twice, verified the wrong file on the third try, then relabeled its own fresh bug “pre-existing” and gave up.

Past 200k context it “failed three consecutive rounds, with the underlying bug essentially unchanged across all three attempts despite increasingly explicit instructions each time.”

The verdict is narrow and earned: trust either on diagnosis, trust Qwen once correction starts. A model that fakes a checkmark is worse than useless in an autonomous loop, where the self-report is the entire product.

Muse Glimmer’s reasoning reads like a goldfish handed a microphone

The set’s most-discussed post, 58 upvotes and 65 comments, is one builder watching the reasoning traces and losing it.

Running the UD-Q5_K_XL quant on a 5090 at roughly 90 to 160 tok/s, he found the traces bizarre next to gemma 4, qwen 3.5/3.6, or laguna.

His description: “this model’s reasoning is like if a gold fish was suddenly granted speech or something,” disorganized, repetitive, “using we for some reason? and bringing up policy and safety twice.”

The specimen earns it. On a plain long-story prompt the trace opens “write a long story User wants a long story. We can comply. No constraints.” and staccatos on from there.

His real question is empirical, not aesthetic: with qwen 3.6 the reasoning seems to push toward a better answer, while here it “just seems like a drunk person stumbling along.”

The tell is the self-affirming register. That same voice is plausibly what stamped the phantom verification checkmarks in the head-to-head, one training artifact wearing two faces.

Muse Glimmer holds 832K tokens, and the config says why

The optimist’s counterweight came from a 2× DGX Spark rig, 99 upvotes and the strongest single build in the corpus.

Someone stretched Muse Glimmer 30B from its trained 131K context to 1M with YaRN and checked retrieval at every rung, honest that the write-up was “written by Muse itself!”

Three needles at 10/50/90% depth held 3/3 retrieval all the way to 832K tokens, 6.35× native, with the deepest around 749K. A small execution-checked coding suite scored 7/7.

The useful part is why it holds. Muse puts RoPE only on its 39 sliding-window layers, with a 2,048-token window, while the 13 global attention layers carry no positional encoding at all.

So a YaRN stretch barely moves the local layers, and the long-range layers “never had rotation embeddings to break in the first place.” That is why retrieval survives where full-RoPE architectures fray.

He is equally honest about the cluster: splitting the model over both Sparks ran about 30% slower than one node, which he sums up as “Fun, not fast.”

Hold that against the head-to-head, though. Provable 832K retrieval and a model that loses the thread past 200k on a real app are both true, because retrieval is not reasoning.

Revision Prompting: patch the output, don’t regenerate it

The corpus’s most actionable idea drew six upvotes and is the concrete answer to the day’s opening question.

When the input changes, instead of re-running the prompt you send the old input, the old output, and a diff of the input, and ask for a patch to the output.

The payoff, per the author: “You generate ~2-10x fewer output tokens, and the untouched parts of the output stay byte-identical.” Decode is the bottleneck and prefill is comparatively free, so this trades the expensive half for the cheap one.

The consistency win may matter more than the cost. Naive re-runs rewrite passages the edit never touched, so a one-word fix can churn an entire translation, and anyone whose users diff outputs feels that as broken trust.

On production pipelines for document translation and invoice extraction, the team reports it “cut processing time by ~80% and cost by ~65%,” with savings scaling to how small the change is. The figures are self-reported from one workload, unverified, and the honesty runs to the caveat: “if a large part of the input changed, just re-run normally.”

This is boring plumbing, which is exactly why it is underrated, and it is the operational form of the lead’s complaint: stop haggling over per-token price and emit fewer expensive tokens.

The cheapest experiment this week: pick one recurring pipeline, log cost per accepted task for a fortnight, and let the acceptance bar you already enforce pick the model.

By the numbers