AI Brief, 20 August 2026: Stripe buys the router, and OpenAI stakes out zero retention

Two of yesterday's three biggest items are about the same thing: who sits between your application and a model, and what they are allowed to see. On 19 August Stripe and OpenRouter both confirmed that Stripe has agreed to acquire OpenRouter, the routing layer that OpenRouter says now carries more than ten trillion tokens a day for over ten million developers and companies. Neither company disclosed a price, and the three outlets that reported one do not agree: Bloomberg said over seven billion dollars on 16 August, Axios said more than eight billion in cash and stock on 17 August, and the New York Times said about 7.5 billion on the 19th, all from unnamed sources. The deal is an agreement, not a completed acquisition; OpenRouter says it expects to close "in the coming weeks".

Hours later OpenAI published a post committing to keep offering zero data retention on its frontier models, and previewing a mechanism called Private Safety Processing that is meant to detect misuse across multiple interactions without OpenAI personnel ever seeing customer content. The zero-retention half is a restatement of something that has existed for years. The new half has not shipped: it is being tested with unnamed early customers, with a rollout and a technical white paper both promised for September. Read carefully, the post does not resolve the tension in its own headline so much as relocate it, because correlating behaviour across interactions is inherently stateful, and the guarantee quietly narrows from "we retain nothing" to "no OpenAI person can read it".

The day's most useful engineering result came from Liquid AI, which released 4-bit checkpoints of its four small LFM2.5 models trained with quantization-aware distillation, so that the weights survive the crudest and fastest 4-bit format rather than needing a more expensive one. The idea is sound and the files are a byte-for-byte drop-in. The announcement's headline claim is not: it says 97% of the accuracy lost to quantization is recovered, when 97% is what the models retain of their full-precision scores. The fraction of the loss actually repaired is 70.6%, 73.4%, 65.5% and 48.4% across the four sizes, and Liquid's own longer post says so. Recovery gets worse as models get bigger.

Elsewhere: Hugging Face shipped a patch that fixes a silent correctness bug in speculative decoding, where the verifier was handed a draft distribution the draft model had never sampled from. And a cluster of papers submitted on the 19th all point at the same conclusion from different directions: for agent post-training, the environment and the selector are now the bottleneck, not the model.

• Stripe has agreed to acquire OpenRouter; both companies confirmed it on 19 August, neither disclosed terms, and the reported price varies by outlet from over seven billion to over eight billion dollars.
• OpenRouter self-reports 10+ trillion tokens per day, 400+ models and 10 million developers; a live count against its public API returns 414 models and 102 providers.
• OpenAI restated zero data retention for eligible API customers and previewed Private Safety Processing, which is not yet available; consumer plans are unaffected, and a legally required CSAM carve-out survives zero retention.
• Liquid AI released QAD-trained Q4_0 checkpoints for LFM2.5 at 230M, 350M, 1.2B and 2.6B. Same file size, same speed, and 48.4% to 73.4% of the quantization loss recovered, not 97%. The licence bars commercial use above ten million dollars of annual revenue.
• Hugging Face transformers 5.15.1 fixes assisted generation returning pre-processor logits to the verifier, which broke the distribution guarantee of speculative decoding whenever sampling was on.
• A compute-normalised study of test-time scaling reports reward models correlating at only about 0.12 with true quality, making best-of-n selection close to random regardless of budget.
• No leaderboard moved. No independent reproduction of any vendor benchmark number was published on 19 or 20 August.

Stripe agrees to buy the router, and nobody will say for how much #

OpenRouter's own announcement and Stripe's newsroom release both went up on 19 August. Stripe's interest was first reported by the Wall Street Journal on 24 July and the deal itself by Bloomberg on 16 August, so the news here is the confirmation, not the rumour.

What OpenRouter is, in one line: a single OpenAI-compatible API in front of many models from many providers, which picks an endpoint per request on price, latency, reliability and task fit. Multiple providers serving the same open weights are treated as interchangeable, so failover and cost routing happen below the application. Its disclosed scale, all self-reported and none of it audited: more than ten trillion tokens per day, over ten million developers and companies, 90 employees, and "at least 10x growth in inference volume every year". Its Series B post from 28 May gives the earlier points on that curve, five trillion tokens a week around November 2025 rising to 25 trillion by late May. Ten trillion a day is roughly seventy trillion a week.

The one number here that is not vendor-supplied: counting directly against OpenRouter's public API on 20 August returns 414 models and 102 providers, so both its own "400+" and Stripe's "more than 80 providers" are conservative.

What the announcement actually commits to. This is worth separating carefully, because the post is warmer than its commitments. Concretely promised: same name, same product, same roadmap, and no change to existing integrations. That is a continuity-of-service pledge. Everything about neutrality is assertion without mechanism: "routing decisions will remain driven by one thing: what's best for you", and a claim that this "doesn't bend to any model, any provider, or any parent company". There is no independent subsidiary, no independent board, no contractual neutrality undertaking, no third-party audit of routing, and no time horizon attached to any of it. Pricing is not mentioned anywhere in the post, nor is data sharing with Stripe, nor what happens to the free model tier.

The adjacency worth stating plainly, because it comes from the documents rather than from speculation: OpenRouter's entire pitch is neutrality across labs, and Stripe processes payments for many of those same labs. Per TechCrunch, Stripe says 88% of the Forbes AI 50 use its products, including OpenAI and Anthropic. Whether that adjacency is ever abused is not something anyone can know today. Franco Granda of PitchBook told TechCrunch the deal gives Stripe "some degree of power over suppliers such as the frontier labs themselves"; that is one named analyst's view, not a finding.

Caveats, in order of how badly they could bite. The deal has not closed. No price is confirmed by either party and the three reported figures disagree by more than a billion dollars. Every scale number above is OpenRouter's own, with no published methodology; "developers and companies" most likely means registered accounts, but OpenRouter does not say. Bloomberg's and the NYT's articles are paywalled and were not readable here, so their figures come via CNBC and TechCrunch, both of which cite them.

OpenAI restates zero retention, and previews a way to police it anyway #

OpenAI's post, published 19 August at 19:00 UTC, is about 750 words and does two things. It commits to continuing to offer zero data retention on frontier models for eligible API customers, and it previews Private Safety Processing.

openai.com returns HTTP 403 to this environment, so the body was read through the r.jina.ai text proxy and cross-checked against the title and pubDate in OpenAI's own RSS feed. The reporter quotes below come from Axios, which was briefed two hours before publication and which was also read through the proxy.

What zero data retention already was. Prompts and responses are not retained after a request is processed, are not available to OpenAI staff for review, and are not used for training unless a customer opts in. It is not a checkbox: it requires prior approval, a qualifying use case and additional contractual terms. The default for everyone else is abuse-monitoring logs kept up to 30 days. Eligibility is defined per endpoint rather than per model in OpenAI's platform documentation: chat completions, responses, embeddings, realtime, moderations, audio and images qualify; conversations, assistants, threads, vector stores, files, fine-tuning jobs, evals, batches and videos do not. Per Axios, none of this applies to Free, Plus, Go or Pro consumer plans.

What Private Safety Processing is. The stated problem is that safety systems compatible with zero retention evaluate each interaction on its own, which misses an actor probing safeguards repeatedly, coordinating across accounts, or an agent that keeps acting after being told to stop. The proposed fix runs automated analysis across related interactions. Content stays either on infrastructure the customer controls, or on OpenAI infrastructure encrypted under keys the customer holds, with OpenAI stating its personnel hold no copy of those keys. When something is flagged, OpenAI receives what it calls a narrowly defined signal indicating the type of activity, and enforcement acts on that signal. Appeals run backwards: the customer investigates using its own logs and may choose to share content.

The part the post does not resolve. Detecting a pattern across interactions is by definition stateful, so something must persist somewhere. OpenAI's answer is not to retain nothing but to move retention to the customer side, and then to narrow the privacy claim from retention to human access. Those are different guarantees. Automated systems demonstrably do process plaintext prompts and responses, which means that content is decrypted somewhere. "Personnel do not have a copy of those keys" is a statement about people, not about the system: it does not say that no OpenAI service ever holds a key in memory, and a compromise of, or a legal order against, whatever performs the decryption sits outside the stated guarantee. The post gives no enclave or trusted-execution detail, no retention period for the analysis window, and no specification of what the signal carries. All of that is deferred to the September white paper, which does not yet exist.

Three published exceptions survive zero retention and are worth knowing before anyone says "no human ever sees your data". The post's single footnote states that images flagged as potential child sexual abuse material are retained for manual review and reporting, as required by 18 U.S.C. § 2258A. OpenAI's platform documentation separately describes "Safety Retention", under which it may retain and human-review flagged content where reasonably necessary to investigate severe risk, and "Eyes Off", under which retention resumes but review is excluded unless legally required.

The competitive framing is unmistakable and second-hand. OpenAI's post refers only to "some recent frontier-model deployments" requiring retention for safety monitoring; Axios and TechCrunch both name Anthropic, reporting that it requires 30-day retention for business customers on Fable 5 and Mythos 5. Anthropic's own redacted risk report is a scanned PDF that could not be read from this environment, so those details are attributed to those two outlets rather than to Anthropic.

A same-day sibling on arXiv is worth noting alongside it: a model card for OpenAI Privacy Filter (2608.18274, submitted 18 August 19:48 UTC) describes a 1.5-billion-parameter model with 50 million active parameters per token and a 128,000-token context window, which converts an autoregressive decoder into a bidirectional banded-attention token classifier and stitches its per-token labels into spans across eight privacy categories with a constrained Viterbi decoder, in one forward pass. The intended use is local scrubbing before data leaves your infrastructure. Two honest limits: the abstract publishes no evaluation numbers at all, and the abs page states no weights or code release, so this is a described model rather than a downloadable one until proven otherwise. The paper's own disclaimer is that it is "a configurable data-minimization component within layered privacy workflows, not as an anonymization or compliance guarantee".

Nothing in this section is measured. There is no benchmark, no audit and no number of any kind in OpenAI's announcement, because the mechanism has not shipped.

Liquid AI trains 4-bit weights to survive the dumbest 4-bit format #

Liquid AI released Q4_0 checkpoints for LFM2.5 at 230M, 350M, 1.2B and 2.6B on 19 August at 13:48 UTC, trained with quantization-aware distillation rather than quantized after the fact. The files are live in the existing GGUF repos alongside the ordinary quantizations.

The reason this is interesting is the format they targeted. GGML's Q4_0 is the oldest and crudest 4-bit block format: 32 weights share one fp16 scale, packed as 16 bytes of nibbles plus 2 bytes of scale, so

$$\frac{18\times 8}{32}=4.5\text{ bits per weight}$$

where 18 is the bytes per block and 32 the weights per block. It is symmetric, with no zero-point term, so a block can only represent $d(q-8)$ for $q\in \{0,\dots ,15\}$ with $d$ the block scale: a uniform grid centred on zero and nothing else. That crudeness is exactly why it is fast, because the dequantisation inner loop is trivial and maps cleanly onto Arm dot-product instructions. Q4_K_M and Q5_K_M buy back quality by spending bits on hierarchical scales and importance-weighted bit assignment, and pay for it in throughput.

The usual response to Q4_0's quality loss is to stop using Q4_0. Liquid's response is to move the cost to training time and pay it once: distil the full-precision model into a student that is quantized in the forward pass, so the weights land somewhere that survives the crude rounding. The published method description is one sentence, and that is the single most important caveat here. There is no loss function, no teacher specification, no confirmation that a straight-through estimator is used, no training budget, no ablation, no code and no paper. This is a weights drop with a results chart, and quantization-aware distillation is not new; the contribution is the checkpoints, not the technique.

What can be verified directly from the artifacts is the claim that it costs nothing. Parsing the GGUF headers of the QAD and the ordinary Q4_0 file for the same model shows identical tensor counts, identical shapes and identical per-tensor quantization types: for the 230M, 132 tensors, of which 82 are Q4_0, 49 are F32 and one is Q6_K. QAD changes the values in the tensors and nothing else, which is why the QAD file is a byte-for-byte size match and a drop-in replacement in any existing llama.cpp deployment. It is also why the throughput claim needs no benchmark: it is an identity, not a measurement.

The tensors that stay above 4 bits are worth knowing, because they are not in the announcement. The token embedding table is Q6_K in both sizes checked, every norm is F32, and so is the length-3 depthwise convolution kernel in each block, which is the defining primitive of the LFM2 architecture. That has a concrete consequence at the small end. The 230M file is 149.1 MB, which is

$$\frac{149.1\times {10}^6\times 8}{230\times {10}^6}\approx 5.19\text{ bits per weight}$$

against Q4_0's nominal 4.5, because a 1024 by 65,536 embedding table is about 29% of the parameters but, at 6.5625 bits each, roughly 37% of the file. At 230M you are largely paying for the vocabulary, not the network. The 2.6B works out at about 4.74 bits per weight, where the same table is a much smaller share.

The results, and the claim that is wrong. Liquid publishes a seven-task mean only, over GPQA Diamond, MMLU-Pro, IFEval, IFBench, Multi-IF, BFCLv4 and one size-appropriate maths task, averaged over five repeats. It states retention against the bf16 ceiling of 97.1%, 96.5%, 97.4% and 96.6% for the four sizes. The Hugging Face version's summary bullet renders this as 97% of the accuracy lost to quantization being recovered. That is a different and much stronger statement, and it is not what happened. Liquid's own longer post gives the correct figure, defining recovery as the fraction of the bf16-to-Q4_0 gap that QAD closes, and reporting 70.6%, 73.4%, 65.5% and 48.4%.

Reading the underlying scores off Liquid's chart, because it publishes no table, the 230M goes from about 31.2 with ordinary Q4_0 to about 33.6 with QAD, against a bf16 ceiling of about 34.6. That is roughly 2.4 points for zero bytes and zero slowdown, which is a good trade. The 2.6B goes from about 62.0 to about 64.1 against a 66.3 ceiling. Those bar values are approximate; they reproduce Liquid's stated retention and gap-closure percentages to within a rounding error, which is the only cross-check available.

Three more things a reader should know. The longer post claims the QAD checkpoints beat Q4_K_M, "the standard 4-bit option", and at the flagship 2.6B they do not: about 64.1 against about 64.4. The Hugging Face version says "match Q4_K_M quality", which is the accurate phrasing. Second, the copy-paste command in the post points at LiquidAI/LFM2.5-350M, which contains no GGUF files at all; the correct repo is LiquidAI/LFM2.5-350M-GGUF. Third, the licence is not open source.

LFM Open License v1.0, section 5: commercial use is licensed only
below a Threshold of $10,000,000 annual revenue. At or above it,
you are not licensed under this agreement.

That is an Apache-2.0 derivative with a revenue trigger, and the trigger is on company revenue rather than product usage, which catches many more organisations than a Llama-style monthly-active-user threshold.

Every quality and throughput number here is Liquid's own, self-run, with no named evaluation harness, no per-benchmark breakdown, no seeds and no variance figures, even though the central claims are about being within run-to-run variance. The release is a day old, so the absence of independent measurement is expected rather than suspicious. The files are small and free, which makes a side-by-side one of the cheapest useful things anyone could publish this week.

Speculative decoding was quietly sampling from the wrong distribution #

transformers 5.15.1 landed on 19 August at 10:50 UTC. Four of its five commits are ordinary maintenance: two device-placement crash fixes, a missing-config-key guard, and a fallback from Lanczos to bicubic resampling on CUDA. The fifth is not.

Speculative decoding is distribution-preserving only because of an accept-reject correction. A draft model proposes a token $x$ from its distribution $q$ , and the target model accepts it with probability

$$\alpha (x)=min(1,\frac{p(x)}{q(x)})$$

where $p$ is the target model's distribution over the same token. On rejection the verifier resamples from the normalised residual $max(0,p-q)$ . Both halves of that correction need $q$ to be the distribution the draft actually sampled from.

PR #48007 fixes the fact that it was not. The candidate generator applied the logits processors, which is where temperature, top-k, top-p and repetition penalty live, sampled the candidate token from the processed distribution, and then returned the raw, unprocessed logits to the verifier. The processed tensor was assigned to a local variable that was never written back.

The direction of the error follows from what top-p does. Truncating to a nucleus and renormalising means the true draft probability of a surviving token is $q^{\prime }(x)=q(x)/Z$ with $Z<1$ , so $q^{\prime }(x)>q(x)$ . Feeding the verifier the raw $q$ therefore makes $p/q$ larger than the correct $p/q^{\prime }$ , and the acceptance probability comes out too generous: draft tokens were accepted that should sometimes have been rejected, and the residual resampling was computed from the wrong distribution too. The author's stated intent in the PR is "to allow coherent redistribution with the main model's outputs". The same fix is applied to the multi-token-prediction draft path.

The scope limits matter as much as the bug. Greedy decoding is unaffected, because there is no accept-reject step to get wrong. Non-assisted generation is unaffected. This bites only assisted or speculative generation with do_sample=True, it does not crash, and nobody has quantified how far outputs actually drifted. It also carries a bland title in the middle of an otherwise routine patch list, which is why it is worth a paragraph here.

One naming trap: "DFlash" appears twice in this release, referring to the candidate-generator plumbing in transformers. It is unrelated to the DFlash 2 model release covered earlier this week.

Four papers on where post-training compute is being wasted #

All four were submitted on 19 August UTC and announced in the batch of the 20th. Read together, they say the same thing from four angles: the model is no longer the constraint, and the machinery around it is.

SPADE (2608.19197, submitted 19 August 17:58 UTC, 18 authors) attacks the environment bottleneck. One model plays two roles under a single Gym-style reset()/step() interface: an Environment Designer that emits complete stateful multi-turn environments as executable code, including transitions, rewards and verifier, and a Reasoning Agent that solves them. The Designer is optimised against a regret proxy, the Agent's reward gap with versus without privileged hints, which pushes generated environments to the edge of feasibility rather than to trivial or impossible. Reported gains over the strongest fixed-environment baseline: +5.3 average across eight held-out maths, science, code and reasoning benchmarks, +5.7 on BFCL-v4 multi-turn, and +13.9 on ACEBench-Agent, with margins growing to 30-billion-parameter scale. Code and a project page are released. The abstract names no base model family, so the 30B figure is the only scale statement that can be quoted.

Test-Time Scaling in the Wild (2608.18931, submitted 19 August 13:59 UTC) attacks the selector, and is the most uncomfortable of the four. It runs what it calls the first compute-normalised comparison of five test-time-scaling families across five open-ended generation benchmarks spanning medicine, law, finance, general chat and creative writing, and decomposes the budget into exploration, whether a better candidate appears in the pool, and exploitation, whether the selector picks it. Exploration is fine. Exploitation is not: with state-of-the-art generators, reward models correlate at only ${\rho }_v\approx 0.12$ with true quality, which the authors say renders selection near-random regardless of budget. Refinement helps on one of five benchmarks and its apparent gains elsewhere are confounded. Only synthesis across candidates consistently beats a single sample, and even that recovers only about 40% of the available quality. The abstract does not say which correlation coefficient ${\rho }_v$ is, and no code release is stated.

Two papers on on-policy distillation landed within an hour of each other and belong together, because both find that the loss is fine and the accounting is broken. GC-OPD (2608.19181, submitted 19 August 17:54 UTC) normalises the task-verifier reward and the trajectory-level distillation score separately within each rollout group, treats their difference as a signed teacher-verifier disagreement, and redistributes that residual onto tokens in proportion to their distillation advantages. It raises the five-benchmark average of the official Qwen3-4B checkpoint from 29.08 to 40.47 and Qwen3-8B from 35.12 to 44.65, with code released. The honest reading of those numbers is not the eleven-point headline: vanilla on-policy distillation already reaches 39.31 and 43.56 under the same setup, so the contribution of the group calibration itself is about 1.2 and 1.1 points. Open-MOPD (2608.19098, submitted 19 August 16:50 UTC) asks why multi-teacher distillation underperforms, and answers that it is token-level budget misallocation rather than gradient conflict: sequence-length disparity across domains, convergence drift from non-uniform learning rates, and reward staleness from asynchronous updates. On a controlled SmolLM3-3B-Base benchmark, standard multi-teacher distillation captures only 35.6% of the headroom available against a domain-routed oracle ensemble; token-share balancing plus gap-aware budget allocation and student reward refresh takes that to 83.4%. The recipe, training trajectories and evaluation suites are open-sourced.

Cacheable by Design? (2608.18261, submitted 18 August 19:23 UTC, single author) is a pre-registered negative result, which is rare enough to be worth reading on its own. The setting is a 235-billion-parameter mixture-of-experts model, Qwen3-235B at Q4_K_M and 134 GB, served from a single 8 GB GPU, where measured decode is 0.44 tokens per second warm and matches a pure bytes-per-token bandwidth model. Routing telemetry on Qwen3-30B finds adjacent-token expert reuse at twice chance, 95% of traffic using 52.5% of experts, and an LRU cache of 13.4% of experts serving 66% of requests, so the locality is real. The pre-registered hypothesis was that training routers with auxiliary locality losses would exploit it. It does cut misses by up to 60%, and every configuration fails the pre-registered 1% perplexity gate; a 340M rung shows the tax rising slightly rather than shrinking with scale. What worked instead was training-free cache-aware rerouting stacked on top of trained locality, together giving roughly 80% miss reduction at up to 3.4% perplexity. Note that the 80% figure is the combination, not the training-free half alone. Code, the telemetry tool, traces and the frozen pre-registration are released.

Also notable #

• Ollama v0.32.15 (19 August) adds a model metadata cache. Before it, every generate, chat and embed request parsed the GGUF manifest, read the config, loaded the template and re-derived capabilities, and did so twice per request because the handler and the scheduler each called GetModel independently. The fix resolves the model once, caches it keyed on name plus template-engine state, uses singleflight so concurrent misses load once, and invalidates on the manifest digest rather than a TTL, so a pull or create that changes content invalidates automatically. The contributor reports about 300 ms of per-request overhead removed and time-to-first-token falling from 995 ms to 524 ms; treat the second figure carefully, because the before and after runs had different average prompt lengths (1,338 versus 832 tokens), and time-to-first-token scales with prompt length. Inter-token latency and throughput are unchanged, which is what a fixed setup cost looks like. It is still flagged pre-release on GitHub, so the current stable release is v0.32.14. The release notes list one change; the tag contains seven, including a fix for the server wedging on a mid-stream parser error.
• llama.cpp build b10502 (19 August) is the first llama.cpp release to carry build attestation, in 45 added lines of CI configuration. Decoding the published Sigstore bundle shows a SLSA Provenance v1 predicate inside an in-toto Statement v1, DSSE-signed with a keyless Fulcio certificate from the workflow's OIDC identity and logged in Rekor, binding 25 artifact digests to the workflow file, repository, commit 0adcc3b and Actions run that produced them. Downloading one artifact and hashing it reproduces its subject digest exactly. A downstream user verifies with gh attestation verify <file> --repo ggml-org/llama.cpp. What this defeats is a tampered mirror or a swapped release asset; what it does not defeat is a malicious commit on master, since the builder identity is the branch itself. It covers b10502 onward only, and verification is opt-in.
• Simon Willison published an evaluation of smolvm as a sandbox for untrusted code on 19 August at 23:16 UTC, and the provenance is the interesting part: he did not run it. He tasked an agent, which found that its own container was already a Firecracker guest with no /dev/kvm and no nested virtualisation, and so ran the test battery on GitHub Actions runners instead, which do expose /dev/kvm. The measured figures are the agent's: 577 to 643 ms for a full create-boot-exec-teardown cycle on a local Alpine image, about 48 ms for warm execution against a persistent machine, a while True loop killed at the timeout with no leftover host processes, and a fork bomb exhausting the guest's own PID space in about a second while host load stayed at 0.69. The report carries a banner saying an LLM wrote all of it, and Willison's editorial contribution is two sentences praising the workaround. Two corrections worth having: smolvm's VMM is libkrun, not Firecracker, despite several third-party write-ups saying otherwise, and there is a separate unrelated project also called SmolVM. The project's own security notes are candid: not a hardened multi-user control plane, and releases are unsigned with no provenance attestations.
• WhiteMatter (2608.18486, 19 August 03:24 UTC) proposes routing each token's layer states into a smaller set of cached key-value channels, so any attention layer can read a representation from any depth rather than only its own. Setting the number of channels below the number of layers shrinks the cache. It reports outperforming a vanilla Transformer with 50% more layers, and retaining most of that gain at 50% KV-cache compression. No model scales, no numeric retention figure and no code release appear on the abstract page, which is why it is here rather than in a section.
• Allocating Recurrent Compute in Looped Language Models (2608.18230, 18 August 18:18 UTC) finds that looping whole blocks is the wrong unit: repeating only the token-mixing layers while running the dense feed-forward once retains 41.5% of full-loop's aggregate CORE improvement at 110M parameters while cutting recurrent-backbone projection FLOPs by 45.9%.
• The benchmark boards did not move. No dated changes on 19 or 20 August on Artificial Analysis, whose newest changelog entry is still 18 August, nor on SWE-bench Verified, ARC-AGI, LiveCodeBench, MTEB, Terminal-Bench or the Open LLM Leaderboard. More notably, no independent reproduction or failure to reproduce of any vendor-reported number was published in the window. A pass over the day's candidates also turned up a claim that Artificial Analysis had added a model called G9v3-39A5B on 19 August; it did not. That model was added on 3 August, and the claim was dropped.
• Sources that could not be reached, so you know what is missing rather than assuming it was covered: openai.com and Axios both return 403 and were read through a text proxy; Bloomberg, the New York Times, The Information and Axios Pro are paywalled and were read only through outlets citing them; Reddit is now unreachable by every route including the proxy that used to work; the LMArena per-model changelog is unreadable by any route tried, so 19 and 20 August model additions there cannot be ruled out; and Anthropic's August risk report is a scanned PDF that this environment has no way to extract text from.

What to watch #

• OpenAI's September white paper on Private Safety Processing. The questions it has to answer are specific: does the analysis run inside a trusted execution environment or in ordinary compute, how long does content persist inside the analysis window, what does the signal actually carry, and can an approved zero-retention customer decline the processing. The post implies it cannot, since the mechanism is framed as the precondition for continuing to offer zero retention, but it does not say so.
• Whether the Stripe and OpenRouter deal closes as expected "in the coming weeks", and whether anything structural accompanies it. An independent subsidiary, a neutrality undertaking or an audit of routing would change how much yesterday's assurances are worth. Silence would also be informative.
• An independent measurement of Liquid's QAD checkpoints. Both files are free, small and differ only in weight values, so a side-by-side on any public harness is a few GPU-minutes. The specific thing worth testing is whether the seven-task mean is hiding uneven damage, because 4-bit degradation usually concentrates in multi-step reasoning and long-horizon tool use.
• Whether the reward-model correlation of about 0.12 holds up on other evaluation sets. If it does, a great deal of best-of-n and tree-search infrastructure is being paid for on the assumption that the selector works.