Tokens Get Cheaper, Diffs Get Longer

On 22 September 2026, Anthropic released Claude Opus 5.5. About an hour later, OpenAI released GPT-6 Sol and GPT-6 Luna. The day before, xAI had shipped Grok 4.7 and Xiaomi had shipped MiMo v2.6. Simon Willison is a developer who tests new models as soon as they come out. He calls his write-up early impressions, and the clearest thing in it is a price war. OpenAI halved the prices of its mid and low tiers. Anthropic cut its flagship's price for the first time in five releases.

The new price table

Willison already used GPT-5.6 Luna as his favourite model to build applications on, because it performed well and cost little. GPT-6 Luna halves its input and cached prices and cuts output by about 58%. GPT-6 Sol is exactly half the price of GPT-5.6 Sol on all three rates. The gap will soon be wider. GPT-5.6 has a 25% price rise scheduled for November, so the current GPT-5.6 prices are effectively promotional.

The cuts hit competitors and OpenAI's own older models alike. Grok 4.7 launched at $2/$6, less than half the price of GPT-5.6 Sol. GPT-6 Sol now matches it on input. GPT-5.6 Terra costs the same as GPT-6 Sol, and Willison says that leaves no reason to use it. At the bottom of the range, the only cheaper OpenAI models have been the much weaker GPT-4.1 Nano ($0.10/$0.40, April 2025) and GPT-5 Nano ($0.05/$0.40, August 2025).

Anthropic's response: Opus 5.5

Opus 4.5 through Opus 5 all kept the same price: $5 per million input tokens and $25 per million output. Opus 5.5 costs $4 and $20, a 20% cut. The cached-input price fell 60%, to $0.20.

Anthropic's Thariq Shihipar describes Opus 5.5 as a response to user feedback. In his words, it communicates more clearly, it is cheaper per token than Opus 5.0, it matches the intelligence of Fable 5.1 (Anthropic's top-tier model), it uses tokens efficiently, and it works at every effort level. Anthropic also says it is better at Blender, the 3D modelling tool. Willison hasn't tested that yet.

Opus 5.5's $4/$20 equals GPT-5.6 Sol's old price, which OpenAI has just halved. The price war has so far reached only the tier just below the top. GPT-6 Astra and Claude Fable 5.1 both still cost $10/$50. Anthropic says Sonnet 5.5 and Haiku 5.5 are "coming soon". Willison wonders whether Haiku can compete on price again: Haiku 4.5 costs $1/$5, ten times GPT-6 Luna.

When "max" thinking breaks

For the first time, a model returned nothing. Opus 5.5 on "max" called the prompt "a classic test request" and then planned in great detail. It checked that a shin length "checks out at roughly 95.2", worked out the leg path from hip to knee to ankle, confirmed the far crank arm would be hidden behind the seat tube, and noted that no font-family was needed because the image had no text. Then it stopped. Claude models cap a single response at 128,000 output tokens, and the reasoning counts toward that cap. Opus 5.5 used all of it before writing any SVG.

A second attempt failed the same way. The cost adds up: 128,000 output tokens at $20 per million is $2.56, which is what each attempt cost. Each also took nearly 20 minutes. Willison's conclusion: if "max" thinks itself to death on a toy prompt, he doesn't trust it on real work, and he calls the setting "effectively useless". Fable 5.1 on max did not overthink, and it drew the best pelican he has had from any Anthropic model.

Willison admits that comparing companies by pelican drawings may not make much sense. He still finds the test useful for comparing one model family across reasoning levels. One example: the GPT-5.6 models chose bold, bright colours and the GPT-6 models chose muted ones.

What he's using now

What's still open

These are first-day impressions. Apart from the pelicans, there are no benchmarks and no head-to-head quality numbers. Two questions remain. Is GPT-6 Sol at half price actually as capable as Opus 5.5 at twice its price? And is the max-effort failure a tuning bug Anthropic will fix, or a real limit of letting a model decide for itself how long to think?

The gap

The mapping comes first

The design depends on a decision made outside Spark entirely. Each Data Project identity maps one-to-one to its own IAM role, and the Data Project service records that mapping. With the mapping, "this process runs as role R" can be translated into "this process is workload W." Pratap argues this is the hard part of bridging two identity systems: committing to a mapping and keeping it authoritative. The cryptographic protocol is the easier part.

One AWS account can't hold tens of thousands of IAM roles, and Netflix expects Data Projects in the tens of thousands. So the roles are sharded deterministically across a small pool of dedicated accounts. A side benefit is that workload roles sit across an account boundary from the control planes that launch them.

Five participants

Three steps

1. A signed claim. When a job is submitted, the control plane checks the caller, looks up the role, and builds a small payload. The payload names the application identity, the role, and the environment and stack the credentials should be scoped to. The control plane signs it and passes it along as ordinary job configuration. Because only one service can sign, the set of things that can vouch for a job is small and auditable. But the payload is only a claim. Job configuration passes through infrastructure Netflix doesn't fully control, so anyone who can read it can replay it.

3. Corroboration. The identity service fetches the URL from STS and learns which role signed it. It checks the metadata signature against the control plane's key. It confirms that the role AWS reported matches the role the control plane said it launched for that identity. Then it issues certificates scoped to the signed metadata.

Here is a worked example (the names are illustrative). The control plane signs "identity recs-features, role dp-4812, env prod." STS reports that the URL was signed by dp-4812. The two agree, so a certificate is issued for recs-features in prod. Now suppose an attacker replays that metadata from a process running as some other role. STS reports the other role, the match fails, and no certificate is issued.

The two statements fail in opposite ways. AWS's statement can't be forged but says too little, because a role isn't a workload. The control plane's statement is specific but can be replayed. Netflix takes the application name from the signed metadata and uses AWS's answer only to corroborate it, rather than parsing app names out of role names, which is fragile string matching. That choice costs a network round trip and a stricter signing requirement.

Fan-out and renewal

Certificates are short-lived, so the driver JVM runs a timer that re-attests well before expiry. Credentials go in a temp directory only the process owner can read, and they're deleted on exit. Executors don't renew. One that outlives its credentials just exits and gets replaced. Pratap's rule is that attestation must be repeatable, not a one-time step at startup, or "a long-running job dies nine hours in."

What's left open

The post gives no numbers on latency, attestation volume or failure rates. It also doesn't say how the control plane's signing key is protected or rotated, or how fast a compromised driver could be contained. The general recipe is still clear: one authoritative mapping, two independent claims checked against each other, a single scarce signer, a hook in the runtime you still control, a deliberate policy on fan-out, and renewal built in from the start.

GitHub has rebuilt the pull request view in its GitHub Copilot app, a desktop app for working on code, so that very large reviews stay responsive. To stress-test it, the team opened the biggest open-source pull request they could find: 2,200 files, over a million changed lines, and more than 400 inline review comments. Alberto Gimeno's write-up covers three things: the rendering design, the data pipeline that feeds it, and the automated loop the team used to find bugs.

Why code is easy and comments are hard

General-purpose virtualizers fill this table with estimates and correct them as rows are measured. A diff of pure code doesn't need to: every row is one line at a known font size, so the whole table can be computed up front and never changes. GitHub calls this the "all heights known before paint" contract. Its diff surface is built on it. It uses an imperative row renderer that recycles elements instead of creating a React component per row. Offsets are stored in typed arrays, the server streams diff documents structure-first, and there's an exact "scroll to row N" API. No per-frame work grows with the total number of rows.

Comments break the contract. A thread's height depends on how its Markdown wraps at the current width, whether <details> (collapsible) sections are open, whether a reply box is open and growing, plus suggested-change diffs, reactions, and images that change size when they finish loading. You can't know any of this until the thread is rendered. A fixed-size slot from an estimator is right on average but wrong at the extremes. Most comments get blank gaps, and the big ones get clipped or sprout an inner scrollbar. Measuring after paint and writing the result into the shared table moves everything below it while the user is scrolling, so the view visibly jumps.

Two geometries

The fix was to split total height into two independent parts:

total height = exact code height + sum of comment-block heights (estimated, then measured) + scroll padding

The code geometry stays exact and is never rebuilt. Each dynamic block (thread, draft, reply composer) gets a stable key and is anchored to a file, line and side, not to a pixel position. Each block also keeps a fingerprint of everything that could change its height (content, open <details>, active composer) and the width it was last measured at. That width is rounded into buckets so a small window resize doesn't throw away every measurement. A block's effective height is its valid measurement if there is one, otherwise a cached height if the fingerprint and width still match, otherwise the estimate. Blocks scale with the number of comments, not lines, so a few thousand are manageable.

Measuring without a feedback loop

What shipped is a single measurement pass:

Per-block observers still exist, but by default they only flag a block for the next pass. There is one exception. When you cause a resize yourself, by expanding a section or opening a reply, waiting showed a one-frame mismatch between the comment and the code below it. Now a visible block is measured and corrected in the same frame, before paint. Two limits prevent a loop: at most one synchronous commit per frame, and never during an active scroll.

Keeping your place

When heights change, corrections are applied by identity, not by pixel. The app records which row or block you're looking at and your offset within it. It then applies the height changes, finds that anchor's new position, and scrolls so the anchor stays put. Changes above the viewport are compensated. Content filling in below the viewport is ignored. A section you toggle yourself pushes content down naturally.

One bug shows how subtle this is. Corrections were skipped if the user had "just scrolled," but scrolls the app made itself also counted. Toggling the file-tree sidebar changed the diff pane's width, wrapped lines reflowed, and the app issued its own small scroll. The guard read that as user input, skipped the correction, and the file drifted off screen. Gimeno's lesson: any "is the user interacting?" check must be one your own side effects can't satisfy.

The pipeline

Finding bugs mechanically

Two automated lanes ran on top. A headless probe ran JSON-described flows against a mock server and ranked bottlenecks, so an AI agent could profile a flow described in plain English. An autopilot drove the real desktop app through cold and warm passes: toggling sections, opening replies, resizing, sweeping deep into the file list. It logged a health signal (no gaps, no blank blocks, real content mounted) to disk for an agent to read.

The post gives no frame-time or load-time numbers, only the claim that the extreme pull request now behaves like a normal one. It also doesn't say how the design performs on lower-end machines.

The experiment

The authors set two kinds of agent against each other.

The number of back-and-forth turns needed to answer a query fell from 23.2 with o3 to 6.0 with GPT-5.6 Sol. The newer model got the analysis right quickly and skipped most of the trial and error.

A reversal of the authors' own earlier claim

Demirbas points out that the authors use these efficiency numbers against their own paper from a year earlier, "Supporting Our AI Overlords." That paper warned that databases would be swamped by "agentic speculation": bursts of exploratory queries from confused models. The new paper says efficient agents "directly challenge the premise" of that work.

Demirbas disagrees and thinks the earlier direction still holds, for two reasons:

What still goes wrong

The efficiency gains reveal a new bottleneck. Schema exploration means looking around the tables to learn what exists and how it connects. It shrank in absolute terms, but its share of turns rose from 16% with o3 to 25% with GPT-5.6 Sol, making it the largest remaining slice.

A small test of the fix

The authors let the agent "self-curate" a context document. It explored the databases and 12 sample queries, and the resulting text was placed in the agent's initial prompt. Accuracy rose by up to 19 percentage points.

Building that context was expensive, though, even at this tiny scale of 12 queries and 12 datasets:

Demirbas notes that scaling this up to an enterprise with terabytes of data and thousands of tables would push the overhead much higher.

The proposed agenda, and its weak spot

The authors propose a persistent semantic context layer. It would be built offline, stored by the database system, and served to agents so they stop rediscovering the same facts. The paper splits the work into two parts: keeping that context semantically consistent as data changes, and designing efficient physical data structures to hold it.

Demirbas calls this section the paper's weakest. Even allowing for a position paper, he says, it lists categories like "consistency scope" and "consistency models" without offering technical solutions or analysis. He also raises a deeper objection. The paper's own experiment shows agents can write their own context. If the Bitter Lesson holds, better models may also work out their own memory formats, consistency rules and on-disk layouts, which is everything Section 3 assigns to the database community.

The paper does sketch two concrete designs:

Either way, AI memory would stop being a static text file and become metadata the database manages.

Demirbas thinks the problem is real, and that it gets worse with organization size. He sees the same pattern in software engineering: hundreds of engineers point models at a large codebase, and every session pays again to rediscover conventions and ownership boundaries the organization already knows.

His suggestion is TLA+, Leslie Lamport's formal specification language. It is best known for checking event orderings in distributed systems, but at its core it is set theory plus temporal logic. Temporal logic is a way of stating what must hold over time, not just at one moment. That lets TLA+ express schema properties, relations between data facts, and dependencies.

He cites Boris Cherny using Anthropic's Opus 5.5 to find race conditions with TLA+ in a few prompts, as evidence that models no longer need an expert operator to use the language.

In his design, an agent would translate natural-language business rules into TLA+ relations. If a metric is redefined, the model shows which downstream definitions break. Agents could also check a planned query against the invariants before running it. An invariant is a rule that must always hold. For example, a query that looks for records where the delivery timestamp comes before the order timestamp violates a temporal invariant, and the agent could fix its filter before ever touching the database. This is Demirbas's idea, not the paper's.

Open questions

The paper leaves the hard parts open: how to keep context consistent, how to make building it cheap at enterprise scale, and whether the database community needs to build it at all. Demirbas ends with a caveat on the Bitter Lesson itself. He argues it applies best where statistical approximation is acceptable. Where you need absolute correctness and performance, he thinks human-engineered algorithms and abstractions can still hold.

Two lineages

What a vCPU actually is

The first difference is what the cloud provider counts as a vCPU. A CPU core has several execution units, but a single thread of instructions rarely keeps them all busy. It often stalls while waiting for data from memory. Hyperthreading, also called simultaneous multithreading, keeps two threads loaded on one core. When one stalls, the core runs instructions from the other. Darwich's analogy is two cooks sharing one kitchen: together they produce more food, but they share the oven and the sink. On x86 instances, each of those threads is sold as a vCPU. Graviton and Axion don't use hyperthreading, so on ARM each vCPU is a whole core with its own oven and sink.

Concurrency versus one heavy query

A reporting dashboard is different. Suppose one query spends several seconds totaling millions of sales rows. If that query is CPU-bound and doesn't use parallel workers, it runs on a single core, and extra cores don't help. Single-core speed matters here, and x86 server chips usually run at higher clock speeds.

Vector width

CREATE INDEX articles_body_tin ON articles USING tin (body);
SELECT * FROM articles WHERE body ==> 'postgres AND replication';

Why you can't switch later

The recommendation

For new applications doing ordinary reads and writes, Darwich recommends ARM by default. He cites good price-performance and parallelism. ARM sizes on PlanetScale usually cost a bit less than x86 sizes with the same vCPUs and memory, though this varies by size and region. x86 deserves a look when a few CPU-heavy queries dominate the workload, or when you rely on SIMD-optimized paths like TIN or pgvector's bit distances.

The article publishes no benchmarks. It gives no throughput or latency figures and no price gaps. Instead, it tells performance-sensitive teams to run their own comparison. Load the same data and settings onto an ARM cluster and an x86 cluster, test at expected peak concurrency, and compare throughput, slow-query latency and cost. Given what a migration costs, that test is worth running before you commit.