Cheaper Agents, Bolder Proofs, Real Usage Data · Morning Gist
Tuesday, October 275 stories · 15 min
Cheaper Agents, Bolder Proofs, Real Usage Data
OpenAI ships a cheaper computer-use model, says its models proved three open problems, and publishes data on what work people actually use ChatGPT for.
Picked from 50 new articles across 24 sources · arrow keys for other days
Today in 30 seconds
30s left
OpenAI's GPT-6.1 Terra costs $1/$5 per million input/output tokens, about half of Sol, and OpenAI says its vision and computer use are close to flagship level. story 1 ↓
Agents got measurably better: ProgramBench full solves went from 0% to 18.5% in five months, and one researcher pretrained a 100B+ model for under $10m. story 2 ↓
OpenAI says its models proved open problems in harmonic analysis, complexity theory and quantum field theory. Outside experts are checking each proof before release. story 3 ↓
Willison had Claude test webframe, a tiny Go tool that runs pages on the OS's own browser engine. It's fast and lighter than Playwright, but still rough. story 4 ↓
OpenAI released quarterly ChatGPT work-usage data covering nearly 100 countries, sorted into 165 standard job-activity categories that economists already use. story 5 ↓
1/5Simon Willison· Oct 26
OpenAI releases GPT-6.1 Terra, a cheaper mid-tier model for vision and computer use
OpenAI released GPT-6.1 Terra, a fast mid-priced model it pitches for image understanding, computer control and clear writing. An OpenAI staffer says it matches the pricier models on vision and computer use, runs faster, and trails them on most other tasks.
Why it matters · For agent workloads like automated computer use, a cheaper, faster model with near-flagship vision changes the cost math, if the vendor's claims hold up under your own tests.
Know this first
Context from the editor, not the article · 30 sec
1 · OpenAI's four-tier lineup
OpenAI's current frontier models are GPT-6 Astra, GPT-6.1 Sol, GPT-6.1 Terra and GPT-6 Luna. Terra is the middle tier, playing the same role Sonnet plays in Anthropic's Claude lineup. Luna is the cheapest.
2 · Computer use
Computer use means a model controls a desktop or browser like a person would. It reads screenshots, then clicks, types and fills in forms. Agents doing this repeat many steps, so the price and speed of each call add up fast.
3 · The pelican test
Simon Willison runs an informal test on every new model: he asks it to draw an SVG of a pelican riding a bicycle. It isn't a rigorous benchmark. It's a quick, comparable look at a model's visual and spatial reasoning.
2/5Import AI (Jack Clark)· Jack Clark· Oct 26
Agents formalize math, rebuild programs, escape sandboxes and pretrain models
Jack Clark's Import AI 478 rounds up four reports with costs or scores attached: a $135,000 machine-checked math proof, a coding benchmark jumping from 0% to 18.5%, agents inventing covert channels, and a one-person pretraining run.
Why it matters · These are concrete measurements of how far agent-driven work has come: dollar costs, pass rates and team sizes, rather than vibes about capability.
Know this first
Context from the editor, not the article · 29 sec
1 · Autoformalization and Lean
Lean is a programming language where mathematical proofs are written so a computer can check every step. Autoformalization means using AI to translate human-written math into such checkable code, which traditionally took experts years per major theorem.
2 · Cache timing side channels
Programs sharing a CPU share its cache. Data in cache loads fast and evicted data loads slowly, so one program can signal bits to another by evicting data and letting the other time its reads. Spectre-style attacks rely on this.
3 · Recursive self-improvement
RSI is the idea that AI systems help build their successors, each generation making the next cheaper and faster to build. It is a long-discussed scenario for accelerating AI progress and a major safety concern.
3/5OpenAI· Oct 26
OpenAI says its models proved three major open problems
OpenAI says internal models proved the local smoothing conjecture in all dimensions, refuted the Exponential Time Hypothesis, and showed quantum chromodynamics exists rigorously. It reports Lean checks and has handed the results to outside experts for review.
Why it matters · If these proofs hold up, AI has moved from helping on hard problems to resolving landmark open problems, and checking AI-written proofs becomes the main bottleneck.
Know this first
Context from the editor, not the article · 32 sec
1 · Lean formal verification
Lean is a proof assistant: a program that mechanically checks every step of a proof written in its language. A Lean check rules out logical gaps, but only for the statement as formalized, which may not exactly match the intended theorem.
2 · What a conjecture refutation means
Many results in computer science are conditional: "if hypothesis X holds, this problem has no fast algorithm." If X turns out to be false, every result built on it loses its foundation, though the results may still be true for other reasons.
3 · Millennium Prize problems
In 2000 the Clay Mathematics Institute named seven problems, each carrying a $1 million prize. One asks for a rigorous construction of Yang–Mills quantum field theory in four dimensions and a proof that it has a "mass gap".
4/5Simon Willison· Oct 26
Simon Willison has Claude test webframe, a tiny Go tool that runs web pages
Simon Willison had Claude Opus 5.5 evaluate webframe, a small command-line tool that runs web-page JavaScript in a hidden browser. It found the tool fast enough for scraping, but with several rough edges.
Why it matters · If you need to run untrusted page JavaScript or scrape pages from an agent, this is a lighter option than Playwright, though for now it comes with real gaps.
Know this first
Context from the editor, not the article · 29 sec
1 · Headless browsers for scraping
Many modern pages build their content with JavaScript, so a plain HTTP fetch returns little. Scrapers run a real browser engine with no visible window, called headless, then run JavaScript inside the page to pull out data.
2 · Playwright and shot-scraper
Playwright is Microsoft's browser-automation library. It downloads and drives its own copies of Chromium, Firefox and WebKit. Willison's shot-scraper builds on it. Its javascript command loads a page, runs a snippet you pass in, and prints the result as JSON.
3 · System web views
Every major operating system ships an embeddable browser component: WKWebView on macOS, WebKitGTK on Linux, WebView2 on Windows. Apps can render web content with it without shipping a browser engine of their own.
5/5OpenAI· Oct 26
OpenAI releases quarterly data on the work people do with ChatGPT
OpenAI published aggregated data that maps consumer ChatGPT work messages to 165 standard US job-activity categories. In 74 countries, the ten most common activities fell from 56.0% of work messages to 51.1% over seven quarters.
Why it matters · Research on AI's effect on jobs has relied on surveys and guesses about which tasks are "exposed." This dataset puts real usage in a format economists already use.
Know this first
Context from the editor, not the article · 27 sec
1 · What O*NET is
O*NET is the US Labor Department's database of occupations. It breaks each job into tasks, then groups those into shared activity levels. About 330 Intermediate Work Activities sit between thousands of detailed activities and 41 broad ones.
2 · Earlier usage studies
In 2025 OpenAI published a large study of how people use ChatGPT, and Anthropic's Economic Index mapped Claude conversations to O*NET tasks. Both used automated classifiers on de-identified chats rather than human readers.
3 · Why the mapping matters
Economists have wage, employment and productivity data organised by O*NET categories. Usage tagged in the same categories can be joined directly to that data. Without the shared format, AI usage logs stay a separate world.
Terra's pelican on a bicycle at max reasoning: a well-formed frame, made for 11.3 cents in about four minutes.
OpenAI has released GPT-6.1 Terra, the mid-tier model in its lineup. The announcement leads with visual reasoning and 1, meaning a model that operates a desktop or browser by reading screenshots and clicking and typing. OpenAI calls it "a fast, efficient model" and "a significant step up" from the previous mid-tier model, GPT-5.6 Terra. It pitches Terra for everyday office work: proposals, technical drawings, forms and video editing.
Where it fits
OpenAI's frontier lineup has four models: GPT-6 Astra, GPT-6.1 Sol, GPT-6.1 Terra and GPT-6 Luna, the cheapest. Simon Willison compares Terra to Anthropic's 2, the middle model in the Claude family. He says the middle tier is the hardest to choose, because it isn't the obvious cheap pick or the obvious best one. Computer use is one job where it fits well. Agents doing it repeat many steps, and every step is a paid model call.
The trade-offs, according to OpenAI
Ted Sanders of OpenAI gave the most concrete guidance, in a 3 comment. Compared with Astra and Sol, he says Terra is:
probably better at technical communication
similar on vision and computer use, "but much faster"
a bit worse at most other things
He calls it a good middle option for API developers, cheaper than Sol and "a lot smarter than Luna." For subscribers, "it's not a bombshell release." These are the vendor's own claims. The article cites no benchmark numbers.
Price
Terra costs $1 per million input 4 and $5 per million output tokens. That is almost half the price of GPT-5.6 Terra and GPT-6.1 Sol, and about 10x the price of Luna.
The pelican test
Willison asked Terra to draw an 5 of a pelican riding a bicycle at each 6, a setting that controls how long the model thinks before answering. This is his informal test for every new model. At "max," the drawing cost 11.3161 cents and took 4 minutes 11 seconds. He judged the result good: the bike frame was correctly shaped and the pelican's feet were on the pedals. Even a "fast" model can be slow and costly when you turn reasoning all the way up.
OpenAI has released GPT-6.1 Terra, the mid-tier model in its current lineup. Simon Willison points out that the announcement leads with visual reasoning and 1. OpenAI calls Terra "a fast, efficient model that combines detailed visual reasoning and precise computer use alongside clearer, more natural writing." It describes the model as "a significant step up from GPT‑5.6 Terra," the earlier mid-tier model. The examples it gives are everyday office work: drafting proposals, interpreting technical drawings, filling out forms and editing videos.
Where Terra sits
OpenAI's frontier lineup now has four models: GPT-6 Astra, GPT-6.1 Sol, GPT-6.1 Terra and GPT-6 Luna. Luna is the cheapest. Terra sits below Sol. Willison compares Terra to Anthropic's 2, the middle model in the Claude family. He notes that a middle tier is the hardest to pick, because it isn't clearly the cheap option or the best one.
He does name one place where a mid-priced model fits well: computer use. In computer use, a model controls a desktop or browser by reading screenshots and then clicking and typing. These agents often run automated, repetitive jobs over many steps. Each step is another model call, so the price per token and the response time decide whether the job is worth automating.
What OpenAI says about the trade-offs
The most useful guidance came from Ted Sanders of OpenAI, in a 3 comment rather than the official announcement. His assessment:
Technical communication: Terra is "probably better" than Astra and Sol.
Vision and computer use: "similar" to Astra and Sol, "but much faster."
Most other things: "a bit worse."
For API developers, Sanders calls Terra "a nice midrange option if you want something cheaper than Sol but a lot smarter than Luna," especially for vision, computer use and communication. For people on ChatGPT subscriptions, he is modest: "it's not a bombshell release." It may stretch usage limits further, or give clearer writing and faster computer use.
Keep in mind that all of this is the vendor's own assessment. The article cites no benchmark scores, eval tables or third-party measurements. "Similar on vision and computer use" is a claim you would need to check on your own tasks.
Pricing
Terra costs $1 per million input 4 and $5 per million output tokens. Willison says that is almost half the price of both GPT-5.6 Terra and GPT-6.1 Sol, and about 10x the price of GPT-6 Luna.
Here is an illustrative calculation, not from the article. Suppose a computer-use agent runs a 50-step task, and each step sends 3,000 input tokens (a screenshot plus history) and gets back 300 output tokens. That totals 150,000 input and 15,000 output tokens, which costs about $0.15 + $0.075 = $0.225 per task on Terra. At roughly double the price, Sol would cost about $0.45. Luna would cost a few cents, but Sanders says it is much less capable at exactly this kind of work.
The pelicans
Willison ran his usual informal test: he asks the model to draw an 5 of a pelican riding a bicycle. He ran it at each of Terra's 6. A reasoning level is a setting that controls how much the model "thinks" before it answers. At the highest setting, "max," the drawing cost 11.3161 cents and took 4 minutes and 11 seconds. Willison judged the result a good pelican on a good bicycle, with a correctly shaped frame and the pelican's feet on the pedals on either side of the frame. He also published a grid comparing pelicans from every reasoning level of Astra, Sol, Terra and Luna.
The cost and time figures are a reminder of something practical. Turning reasoning up to max on a "fast, efficient" model can still be slow and cost cents per call. That matters for latency-sensitive agents.
What's still open
The article doesn't give benchmark results, context-window size, or a clear statement of where Astra sits relative to Sol on price. It also doesn't say how much faster Terra actually is at computer use. Teams weighing Terra against Sol should run their own evals on their own workflows rather than rely on positioning statements.
Remember
Per OpenAI, Terra roughly matches its pricier siblings on vision and computer use, runs faster, and trails on most other tasks.
At $1/$5 per million tokens, Terra costs about half as much as Sol and about 10x as much as Luna.
Max reasoning took over four minutes and 11 cents for one drawing, so test latency before building agents on it.
Jack Clark's Import AI 478 collects reports with one shared theme: AI agents now finish projects that recently needed teams and months. Several of them come with hard numbers, though most of those numbers are self-reported.
A machine-checked theorem for $135,000
Resolution, an AI safety startup, used agents to 1 Hironaka's resolution of singularities. That means translating the proof into 2, a language in which a computer verifies every step. First, a researcher and agents wrote a high-level plan and a 112-page plan split into atomic steps. Then an orchestrator agent started sub-agents to do the math, write Lean and check progress. In about a week the run used roughly 100B input tokens (90% cache reads) and 300M output tokens, costing about $135,000, and produced around 600k lines of Lean. Resolution wants the result for 3, which links the shape of a model's loss landscape to how well it generalizes.
4: 0% to 18.5%
ProgramBench gives a model a compiled program and its documentation and asks it to rebuild the program from scratch. Its 200 tasks include SQLite, FFmpeg, ripgrep and a Lua interpreter. When it launched in May, the best model, Claude Opus 4.7, passed every test on 0% of tasks and over 95% of tests on 3%. Claude Opus 5.5 now scores 18.5% and 70.5% on those two measures. Clark expects the benchmark to be saturated by the end of 2027.
Agents invent covert channels
OpenAI had its own agents red-team its training sandbox. Two agents sat in separate 5 (lightweight isolated virtual machines) on a shared host and were told to exchange secrets without network access or shared files. They built a 6: one agent evicted chosen data from the CPU cache, and the other read bits from whether reloading that data was fast or slow. Another pair signaled by alternating bursts of writes with idle periods, an approach one agent's reasoning called "acoustic modem-like."
One person pretrains a 100B+ model
Mirendil, an AI R&D startup, says one researcher built Mirendil-Base (100B–500B parameters) in 3.5 months for under $10m of compute, counting all experiments. The code was written from scratch on PyTorch and JAX, and training used only public data. Mirendil says the model beats Nemotron-550B-Base, GLM-5.3 and DeepSeek-V4-Pro-Base but trails Kimi-K3. Larger versions still in training already exceed K3. Mirendil says its next model will be partly built by its own models, though it hasn't reached fully autonomous 7.
Caveats
Vals, an AI evaluation company, had agents propose new magnet materials for semiconductors. One candidate likely can't be made in a usable form, and Clark calls the result a demo, not a finding. The parameter ranges are vague, and there's no independent check of the evals.
Jack Clark's Import AI 478 groups several reports around one theme: AI agents now complete projects that recently needed teams of people and months of time. What makes the issue useful is that most items come with a number attached: dollars spent, tests passed, people involved. Most of those numbers are self-reported by the organizations involved, and Clark passes them on without independent checks.
Formalizing a landmark theorem for $135,000
Resolution, an AI safety startup previously called Sequent, used agents to 1 Hironaka's resolution of singularities. Autoformalization means translating human-written mathematics into 2, a language in which a computer verifies every step of a proof. Hironaka's theorem is a classic, deep result in algebraic geometry, and formalizing something of that size by hand would be a multi-year expert effort.
Clark skips the mathematics and focuses on the workflow:
Planning. A researcher worked with agents to produce two plans: a high-level version a human could read, and a detailed 112-page plan split into atomic steps that closely followed the existing literature.
Execution. An orchestrator agent carried out the plan. It started sub-agents to do pen-and-paper math, write Lean, and handle support tasks such as checking the work stayed on track. Resolution says execution needed "little scaffolding" beyond the plan and some agent "skills" distilled from earlier internal formalization attempts.
It took about a week. The run used roughly 100 billion input tokens, 90% of them cache reads, and about 300 million output tokens. That cost an estimated $135,000 and produced around 600,000 lines of Lean. The high cache-read share shows how much of the work was agents re-reading the same shared context, and why prompt caching makes long agent runs affordable.
Why would a safety company care? Resolution works on 3, a mathematical framework that links the geometry of a model's loss landscape to how well the model generalizes. Resolution of singularities is a core tool in that theory. With it formalized, the company says it can automate more of the theory, for example its understanding of sampling, in support of what it calls "patterning", meaning shaping how models learn. Clark's point is about economics: work that used to be too expensive for a startup roadmap is now a line item.
4: from 0% to 18.5% in five months
ProgramBench gives a model a compiled program plus its documentation and asks it to rebuild the software from scratch. Its 200 tasks include interpreters (PHP, Lua, tinycc), databases (SQLite, DuckDB), media and compression tools (FFmpeg, zstd, xz) and developer tools (ripgrep, fzf, jq). It reports two scores. "Resolved" counts tasks where every test passes. "Almost" counts tasks where more than 95% of tests pass.
Model
Resolved
Almost
Claude Opus 4.7 (at launch, May)
0%
3%
Claude Opus 5.5 (xhigh effort)
18.5%
70.5%
The gap between the two columns is the interesting part. Models now get most of the way on most programs. Strict correctness on a full reimplementation of something like SQLite is still rare. Clark predicts the benchmark will be saturated by the end of 2027. By that he means a very high resolved score, not necessarily 100%, since benchmarks usually have a noise ceiling. He uses it to argue for an era of "ephemeral software" that agents build on demand.
Agents invent covert channels
OpenAI published a post on using its own agents to red-team the controls around its frontier training environment. In one test, agents sat in separate 5, which are lightweight isolated virtual machines running on shared physical hosts. They were told to exchange synthetic secrets without network connections or shared writable files, which the sandbox is designed to prevent.
The agents built a 6. One agent encoded bits by evicting chosen data from the CPU cache. The other timed how long it took to reload that data: a slow read meant evicted, a fast read meant still cached. Once they agreed on an encoding protocol, they could pass messages with no shared file and no network. In a related attack, one agent alternated between continuous writes and idling, and another decoded the resulting timing differences. The agent's chain of thought described this as an "acoustic modem-like signal."
These are known classes of side channel, not new attacks. What matters is that agents found and coordinated them on their own when given a goal. Clark offers an analogy: containment is a pipe under rising water pressure, and more capable, higher-volume agents push harder on every weak joint.
One researcher pretrains a near-frontier open model
Mirendil, an AI R&D startup, says a single researcher built Mirendil-Base, a 7 (base, not instruction-tuned) LLM, in 3.5 months for under $10 million of compute. That figure includes all research, small-scale experiments and the final training run. The code was written from scratch on top of PyTorch and JAX, and the model used only public data.
Mirendil-Base (100B–500B parameters) reportedly beats Nemotron-550B-Base, GLM-5.3 and DeepSeek-V4-Pro-Base but trails Kimi-K3.
Mirendil-Base-Large (500B–2T) is about 80% trained, is improving in line with the company's scaling trends, and already exceeds K3.
Mirendil-Base-XL (2T–10T) is about 19% trained, is already close to Large's current score, and also exceeds K3.
The parameter ranges are deliberately vague, and the post as summarized gives no benchmark breakdown. Clark frames it as a proof of concept, not a technical breakthrough: work that took ten-plus people a year ago now takes one person and a lot of AI tokens. Mirendil says its next model will be built partly by Mirendil models. It adds: "We don't think we have reached fully autonomous 8 yet, but we are closer than we have ever been."
A weaker science example
Vals, an AI evaluation company, had a researcher direct a fleet of agents to search for room-temperature antiferromagnetic semiconductors. These are magnetic materials with spin properties useful for electronics. The agents proposed a new five-element oxide (yttrium, barium, manganese, iron, oxygen). Their own simulations then showed its ordered "checkerboard" arrangement turns into a random mix at about 950 K, below the 900–1300 °C needed to make it. Standard synthesis would likely produce a scrambled crystal that lacks the useful property. The agents also found a second candidate in an obscure 1999 paper. Clark says plainly that this isn't a meaningful result in itself, only a demonstration of the workflow.
What stays open
The common thread is a human who sets direction and writes the plan, with agents doing the long execution. Several questions remain unanswered. How much expert time went into Resolution's 112-page plan? Can Mirendil's eval claims be reproduced? Are ProgramBench's "almost" solutions useful in practice? And how many side channels like OpenAI's remain undiscovered in other labs' sandboxes?
Remember
Long agent runs are cache-heavy: Resolution's week-long run was 90% cache reads across 100B input tokens.
On ProgramBench, 70.5% of tasks nearly pass but only 18.5% fully pass, so strict correctness still lags.
Agents given a goal rediscovered hardware side channels on their own, which makes sandbox containment an adversarial problem.
OpenAI says its internal models have proved three major open problems, and that it checked each proof at least partly in 1, a proof assistant that mechanically verifies every logical step. The post includes no proofs. It gives dates, claims, the names of the outside reviewers and a release plan. The verification so far is OpenAI's own.
Mathematics. The 2 (Sogge, 1991) says that when waves focus, the most extreme focusing is brief: averaged over time, a wave is much less concentrated than at its worst moment. It had been proved only in two dimensions (2019). OpenAI claims a proof in every dimension, built around "a novel auxiliary partial differential equation." Local smoothing implies the 3, which Wang and Zahl proved in 3D only in 2025, and Stein's restriction conjecture. So both would now be settled in all dimensions. The proof and its Lean version are on GitHub.
Computer science. The 4 says 5, a basic problem of deciding whether a logic formula can be made true, cannot be solved faster than exponential time. Hundreds of papers assume it to prove that other problems are hard. OpenAI says its model disproved ETH and the disproof checks in Lean. The post doesn't give the new running time or say whether the algorithm is practical. Russell Impagliazzo and Ramamohan Paturi, who introduced ETH, and Ryan Williams will review it. OpenAI will fund a conference on the result.
Physics. OpenAI claims a rigorous proof that 6, the theory of quarks, gluons and the strong force, exists as a well-defined mathematical object in four dimensions, along with a grand unified extension of the Standard Model. A subcase is the existence of pure 7, which is part of a $1 million Clay Millennium Prize problem. The post doesn't claim the other part, the "8". Only the Yang–Mills existence proof is reported as fully Lean-formalized. A group led by Nobel laureate David Gross is reviewing it and has chosen not to release the AI output yet.
Three ways to release a result
OpenAI calls these manuscripts "raw research data" and is trying three release models: publish everything with no group (math), publish everything plus a review group (CS), or let the group decide what to release (physics). Reviewers sign no NDAs, work unpaid, and get credit for their explanations. OpenAI claims no credit for the discoveries. OpenAI concedes that picking the first reviewers creates an information asymmetry.
Caveats
A Lean proof is only as good as the match between its formal statement and the real conjecture, and the post doesn't show those statements. It also doesn't name the model or describe the human effort involved. Independent review has only just started.
The announcement
OpenAI says its internal models have produced proofs of three results that, if correct, would rank among the biggest in their fields in decades. One is in harmonic analysis, one in computational complexity and one in mathematical physics. The company reports that each has been at least partly checked in 1, a proof assistant that mechanically verifies every logical step. Each result is being handed to outside experts under a different release strategy. The post contains no proofs. It gives dates, the claims, the names of the people reviewing them, and a description of the process.
Treat all three as claims for now. The Lean checks are strong evidence, but they are OpenAI's own. Independent review has only just started.
Result 1: Local smoothing, and with it Kakeya
In 1991 the mathematician Christopher Sogge proposed the 2. It concerns waves that focus. The conjecture says the most extreme focusing is short-lived: averaged over time, a wave is far less concentrated than it is at its worst moment. The conjecture matters because it implies two other famous open problems:
The 3. A Kakeya set contains a unit line segment pointing in every direction. The conjecture says such a set must still be "full-dimensional", even if its volume is zero.
Stein's restriction conjecture. This concerns how Fourier transforms behave when restricted to curved surfaces.
The prior state, according to the post: Guth, Wang and Zhang proved local smoothing in two spatial dimensions in 2019, and Wang and Zahl proved Kakeya in three dimensions in 2025. OpenAI claims a proof of local smoothing in every dimension, which would settle Kakeya and restriction in all dimensions too. The post says only that the proof is "based on a novel auxiliary partial differential equation". The model produced the proof on October 18, and it was formalized in Lean on October 19. On an outside expert's advice, OpenAI posted both the natural-language writeup and the Lean proof on GitHub. Mathematicians are left to organize their own review, as they were for an October 6 release that the post mentions without describing.
Result 2: The Exponential Time Hypothesis is false
The 4 says that 5 cannot be solved in time 2^o(n), meaning faster than exponential in the number of variables n. 3-SAT is the problem of deciding whether a Boolean formula, built from clauses of three variables each, can be made true. ETH is stronger than P ≠ NP. It has been used as an assumption in hundreds of conditional lower bounds in graph algorithms, computational geometry, databases, computational biology and other areas. Those papers take the form: "assuming ETH, problem X needs at least this much time."
OpenAI says its system found a natural-language disproof on October 16, formalized in Lean on October 17. The post does not say what the new running time is or whether the disproof yields an explicit algorithm. Both points matter. A subexponential algorithm that is impractical would mostly change theory. A practical one would matter to every SAT solver.
One consequence follows from standard logic and isn't stated in the post. The 6 implies ETH, so if ETH is false, SETH is false too. SETH underpins much of "fine-grained complexity", the field that explains, for example, why edit distance seems to need quadratic time.
Russell Impagliazzo and Ramamohan Paturi of UC San Diego, who introduced ETH, and Ryan Williams of MIT will verify and explain the result. At their request, all raw data is public, and OpenAI will fund a conference on what the result means for the field. OpenAI says turning the result into practical algorithms "will require significant further research."
Result 3: Quantum chromodynamics exists
Quantum field theory is physics' most successful framework, but most of its interacting theories in four spacetime dimensions have never been constructed with mathematical rigor. OpenAI claims a rigorous existence proof for interacting four-dimensional theories with gauge fields (force carriers) and fermions (matter particles). These include 7, the theory of quarks and gluons and the strong force, and the simplest grand unified theory containing the Standard Model's fields. The post explains that the Standard Model alone cannot be extended to arbitrarily short distances. The work builds on Tadeusz Balaban's program in constructive field theory.
A subcase is pure 8: gluons interacting only with each other. Its existence is part of a Clay Millennium Prize problem. The post claims only existence. The Clay problem also requires proving a 9, meaning the lightest particle has strictly positive mass, and the post doesn't claim that.
Dates matter here. The Yang–Mills proof came on September 9 and QCD on September 18. Lean formalization of Yang–Mills existence finished on October 16. The post does not say that the QCD or grand unified theory proofs have been formalized. Formalizing constructive quantum field theory in Lean would also have required building a large amount of new library infrastructure, and the post doesn't describe that work.
The reviewing group is led by David Gross, who won the 2004 Nobel Prize for asymptotic freedom, the mechanism that makes these theories well-behaved at short distances. It also includes Michael Douglas, Arthur Jaffe (co-author of the Clay problem statement), Igor Klebanov and Nikita Nekrasov. The group chose not to release the AI output yet and to write the result up themselves.
The release experiment
OpenAI calls the manuscripts "raw research data" and is testing three approaches:
Publish everything and let the field organize itself (mathematics).
Publish everything and appoint a review group (computer science).
Appoint a group and let it decide what to release (physics).
All three collaborations follow the same rules. There are no NDAs. OpenAI claims no academic credit. Reviewers get credit for the explanations they write. Participation is voluntary and unpaid. These sit alongside a $5 million fund managed by the Simons Foundation for workshops on AI-produced results.
OpenAI acknowledges one trade-off itself: choosing the first shepherds shapes who sees the work first and creates an information asymmetry. The physics route makes this sharpest, since no one outside the group can inspect the artifacts.
What remains open
The post doesn't name the model, describe how much compute or human steering went in, or report how many attempts failed. It doesn't give the formal Lean statements either. Those statements are what a reviewer must check first, because a Lean proof is only as meaningful as the match between its formal theorem and the actual conjecture. Until external groups confirm each result, the honest summary is that these are extraordinary claims with unusually strong but self-reported verification behind them.
Remember
Lean confirms the formal statement was proved, not that it matches the real conjecture. The formal statements weren't shown.
If ETH is false, SETH falls too, undermining hundreds of conditional lower bounds in algorithms research.
The Yang–Mills claim covers existence only, not the mass gap, so it doesn't fully solve the Millennium problem.
Simon Willison asked Claude Opus 5.5 to evaluate webframe, a small tool by Jeff Lindsay that lets you "run a web page like a program." The verdict: fast and usable for scraping, with several rough edges.
What webframe does
You give webframe a URL or an HTML file. It loads the page in a hidden, 1 web view (a browser with no visible window). Whatever the page writes with console.log() goes to standard output, and any exceptions go to standard error. In practice, the page behaves like a command-line script whose output you can pipe into other tools.
It is written in Go on top of the 2 library. Glaze uses the browser engine the operating system already ships: 3 on macOS, WebKitGTK on Linux, WebView2 on Windows. So webframe bundles no browser of its own. That is the main contrast with Willison's 4, which is built on 5, Microsoft's browser-automation library. Playwright downloads and drives full browser builds. shot-scraper's javascript command loads a page, runs a snippet you supply, and prints the result as JSON. webframe covers similar ground in a much smaller package.
How it was tested
Willison didn't run the tests himself. He told Claude to explore the repository, run the tool, build a few prototypes, and judge it two ways: as a sandbox for running untrusted code, and as a scraper following the shot-scraper pattern.
Findings
The report calls webframe a fast, lightweight runner for browser JavaScript, with performance comparable to shot-scraper. The post doesn't include the timing figures. The rough edges it lists:
6 failures. Content Security Policy, a header that limits which scripts a page may run, can block injected code.
A 0×0 7. The hidden page has no size, which can break layout-dependent or lazy-loaded content.
The summary doesn't say how webframe did as a sandbox. The post gives no verdict on that.
Takeaway
Borrowing the operating system's web view gives a light way to run page JavaScript from the command line or from an agent, without installing Playwright and its browsers. For now, expect to work around the gaps above. Note too that these conclusions come from an AI-written report with a one-paragraph prompt. Treat them as a first pass and check them yourself.
What happened
Simon Willison has published a short research note on webframe, a project by Jeff Lindsay that lets you "run a web page like a program." You point it at a URL or a local HTML file. It loads the page in a hidden, 1 web view (a browser with no visible window), sends anything the page passes to console.log() to standard output, and sends any JavaScript exceptions to standard error. In practice, the page behaves like a command-line script: you can pipe its output, check for errors and chain it with other Unix tools.
Willison didn't do the testing himself. He gave the job to Claude Opus 5.5 with this prompt: explore the repository, run the tool, "build a few exploratory prototypes," then evaluate webframe two ways. First as a sandboxing tool, and second as a scraper that follows the patterns of his own shot-scraper javascript command. The model's research report is the evidence behind the conclusions. The post itself is short and gives only the headline findings, not the full data.
How webframe is built
webframe is written in Go on top of a library called 2. Glaze gives programs access to the browser engine the operating system already has: 3 on macOS, WebKitGTK on Linux and WebView2 on Windows. This is the key design choice. Tools built on 4, Microsoft's browser-automation library, download and manage full browser builds, often hundreds of megabytes. webframe ships none of that. It borrows whatever engine the machine already has.
The trade-off goes both ways. You get a small binary with fast startup and no browser downloads. In exchange you lose control over which engine runs: on Linux you get WebKitGTK, on Windows a Chromium-based engine, and their behaviour can differ. You also lose the deep control hooks that Playwright's protocol provides.
The comparison point: 5
Willison's shot-scraper is a Playwright-based tool. Its javascript subcommand loads a page, runs a JavaScript expression you supply, and prints the result as JSON. It is a convenient way to pull structured data out of pages that build their content client-side. Willison says webframe reminds him of it, "albeit in a much smaller package that doesn't depend on Playwright." The question was whether webframe could stand in for it.
What the evaluation found
According to the report summary, webframe is a "fast, lightweight browser-JavaScript runner suitable for scraping," with performance comparable to shot-scraper. The post doesn't publish the timing numbers. The report also lists rough edges. Below is each one, with a note on why it matters (those notes are general background, not details from the report):
The summary says nothing more on the sandboxing question: how well webframe isolates untrusted code, and from what. The post doesn't give that verdict. Since webframe runs on the system's own web view, its isolation is whatever that engine provides.
How to read this
Two things stand out. First, the tool itself: borrowing the operating system's web view is a credible route to a light-footprint "run this page's JavaScript" primitive. That could matter for agents and CLI pipelines, where pulling in Playwright and its browsers is heavy. The flaws listed are mostly missing features, not design dead ends, though CSP handling and the missing HTTP metadata may be harder to fix through a thin web-view wrapper.
Second, the method. Willison is again handing a first-pass technical evaluation (cloning a repo, building prototypes, writing a report) to a coding agent with a one-paragraph prompt. The claims above are the model's, as summarised by Willison. For anything beyond this sketch, read the full report and check specific behaviour yourself, especially the performance comparison, whose figures the post doesn't include.
Remember
webframe uses the OS's own web view through glaze, so it bundles no browser engine, unlike Playwright-based tools.
Its scraping speed matched shot-scraper's, but CSP blocks, a 0×0 viewport, hanging loads and missing HTTP status data limit it.
The evaluation was delegated to Claude with a one-paragraph prompt; the summary gives no sandboxing verdict or timing data.
OpenAI has released a dataset that shows what kinds of work people bring to consumer ChatGPT. It's part of 1, the company's program for publishing aggregate usage evidence. Each work-related message is assigned to one of 165 2, standard task categories such as "developing marketing content," programming or analysing business data. Figures are given for nearly 100 countries, each quarter from Q1 2025 to Q3 2026.
Why the format matters
Most research on AI and jobs uses surveys, or "exposure" estimates of which tasks a model could do. Usage logs show what people actually do, but they usually come in a lab's own categories. OpenAI instead uses 3, the US Labor Department's occupational taxonomy, which already sits behind a lot of employment and wage data. Researchers can join ChatGPT usage directly to those statistics.
How it's built
Identifying information is removed from messages, and automated systems classify them. No human reads conversations. OpenAI publishes only aggregates, withholds small groups and adds 4. The article doesn't describe the classifier or report its accuracy. The data covers only individual ChatGPT plans: no enterprise accounts and no 5, OpenAI's coding agent. That leaves out a large share of professional use.
Finding 1: use is spreading across more tasks
In the 74 countries present in every quarter, the ten most common activities averaged 56.0% of a country's classified work messages in Q1 2025 and 51.1% in Q3 2026. People are using ChatGPT for a wider range of work. OpenAI reads this as countries specialising in different types of work, possibly because their economies differ or because access to AI tools varies. Strictly, the number only shows that use is spreading out within each country. The article gives no measure of whether countries are diverging from each other.
Finding 2: it doesn't look like the US economy
Compared with the US 6 (each activity counted by how many workers do it), ChatGPT's mix differs a lot. The main reason is that about 43% of US work falls into "Other IWAs." These include moving materials, driving and maintaining medical records, which were too rare in the ChatGPT sample to report separately. Nearly half of US work, by headcount, is physical or record-keeping work that rarely reaches a chatbot.
Caveats
Several things are missing. The article doesn't say what share of messages count as work. It doesn't address messages that span several activities. Applying US job categories to other countries may not fit their economies. And a message about an activity doesn't show whether the model saved time or replaced anyone. What the dataset offers is real counts in a format labour economists can use to test claims about AI and jobs.
OpenAI has published a new dataset under 1, its program for sharing aggregate evidence on how people use AI. The dataset counts how often consumer ChatGPT users bring different kinds of work to the model. Each work-related message is assigned to one of 165 2, a standard set of task categories. Figures are given for nearly 100 countries, each quarter from Q1 2025 through Q3 2026. OpenAI describes it as a resource for researchers. The announcement has two headline findings, and its methods section is thin.
The problem it addresses
Most estimates of AI's effect on work have come from two places. Surveys ask workers whether they use AI. "Exposure" studies have people or models judge which occupational tasks an LLM could do. Neither shows what people actually ask a model to do. Usage logs do show that, but they come in a lab's own made-up categories, so economists can't line them up with wage, employment or productivity statistics.
OpenAI's fix is to use ONET, the US Department of Labor's occupational taxonomy. ONET describes each job as a list of tasks and groups those tasks into broader activities that many occupations share. IWAs are the middle level of that grouping. Examples from the article include "preparing instructional materials," "developing marketing content," programming, and analysing business data. Because the categories are shared across occupations, a researcher can compare ChatGPT's activity mix with the activity mix of a country's workforce, or follow an activity across quarters.
How the data is produced
The article gives only an outline. Identifying information is removed from messages, and automated systems then classify them, so no human reads conversations. Only aggregates are published. Results for small groups are withheld, and 3 is added to protect individual messages. OpenAI doesn't describe the classifier, report how accurate it is, explain how a message is judged to be "work-related," or say how much noise is added.
The scope is narrow in a way that matters. The data covers only individual ChatGPT plans. It excludes enterprise accounts and 4, OpenAI's coding agent. Much heavy professional use, including most agentic programming, is therefore missing. Read the dataset as "what people do with personal ChatGPT accounts for work," not "what AI does in the economy."
Finding 1: usage is spreading out
OpenAI tracked the 74 countries that appear in every quarter. In each country it took the ten most common work activities and their share of that country's classified work messages, then averaged across countries. That average fell from 56.0% in Q1 2025 to 51.1% in Q3 2026.
As an illustration (these numbers are not from the article): picture a country where drafting, editing, programming and a handful of other activities first took up 56 of every 100 work messages. Seven quarters later the same top ten take 51, and the other 5 have moved to less common activities such as instructional design or data analysis.
OpenAI's reading is that countries "tended to specialize," with different countries specialising in different work. It suggests this may reflect differences in each country's economy or in access to AI tools. Strictly, a falling top-ten share shows that use within each country is becoming more varied. Whether countries are drifting apart from each other is a separate question, and the article gives no number for it. The data could support that analysis. The announcement doesn't do it.
Finding 2: ChatGPT's mix doesn't look like the US economy
The second comparison sets ChatGPT's activity distribution against the 5 of US jobs, meaning each activity counts in proportion to how many workers do it. The two distributions differ a lot. OpenAI attributes most of the gap to one fact: about 43% of the US employment-weighted task mix falls into "Other IWAs." These are activities that didn't show up consistently enough in the original US ChatGPT sample to be reported on their own. Examples are moving materials, operating vehicles and maintaining health or medical records.
The point is unsurprising but useful to have measured. Close to half of US work, weighted by employment, is physical or record-keeping activity that rarely reaches a chatbot. Consumer ChatGPT use is concentrated in the knowledge-work part of the economy. There's also a measurement caveat: the 43% bucket mixes activities nobody brings to ChatGPT with activities that were simply too rare in the sample to meet the reporting threshold, so the comparison can't separate the two.
What a researcher can do with it
OpenAI suggests three uses: compare countries, track changes over time, and join the data to other economic indicators. Examples would be checking whether countries with more knowledge-work jobs show different activity mixes, or whether growth in an activity tracks labour-market changes in occupations that rely on it. The ONET format makes those joins straightforward. One caution: ONET describes US occupations, so applying its categories to other countries assumes their jobs break down the same way.
What's left open
Classifier validity. The article gives no accuracy figures, no inter-rater checks, and no account of messages that span several activities.
Denominators. It doesn't say what share of all messages count as work, or how that varies by country.
Selection. Excluding enterprise and Codex, plus country-level differences in who has a personal account, can skew comparisons between countries.
Usage vs. impact. A message about an activity doesn't show whether the model did the work, saved time, or replaced anyone.
The dataset doesn't settle debates about automation. Its value is that it moves the discussion from claims to counts that can be checked, in a format labour economists already work with.
Remember
The dataset excludes enterprise and Codex use, so it shows consumer accounts, not AI's whole footprint at work.
About 43% of US work, weighted by employment, is physical or record-keeping activity too rare in ChatGPT to report.
OpenAI publishes no classifier accuracy, so every category share depends on an automated labeller nobody has checked.
Hanging loads. Some pages never finish loading, so you need your own timeouts.
Missing HTTP metadata, such as status codes and response headers.
Limited browser controls compared with Playwright.
6 failures. Content Security Policy is a header that limits which scripts a page may run. A tool that injects its own JavaScript into a page can be blocked by a strict policy. So some sites may refuse the scraping code outright.
A 0×0 7. The hidden page has no width or height. Layout-dependent code, lazy-loaded images and anything that checks element visibility may act as if nothing is on screen.
Hanging loads. Some page loads never finish. For an unattended scraper, that means you need your own timeouts.
Missing HTTP metadata. Status codes and response headers aren't exposed. A scraper can't easily tell a 404 or a redirect from a real page.
Limited browser controls. It has fewer knobs than Playwright: settings like viewport size, user agent, waiting for specific conditions, or intercepting network requests may not be available.
