OpenAI's AI solves 90 long-open math problems
OpenAI says an internal model generated 722 papers and closed 90 of the field's 500 hardest open problems, with each proof formalized in Lean so it can be machine-checked rather than taken on faith — a different kind of claim than a benchmark score, because a skeptic can verify it line by line instead of trusting a leaderboard. That's the real test of whether 'AI does research' means anything, and it's a genuine shift from AI applying known math to AI generating math a human hadn't yet produced. If you've ever had to defend an experimental result against reviewers who didn't trust your pipeline, the appeal of a formally checkable proof over a trust-me result will feel familiar.
What’s Lean-formalized proof?
Lean is a proof assistant — a language and checker for writing mathematical proofs so that every logical step can be verified by a computer, rather than reviewed and trusted by a human mathematician reading prose.
Pairing an LLM with Lean closes the main hole in 'AI solved a math problem' claims: a model can generate plausible-sounding proofs that are actually wrong, but a Lean-checked proof has been confirmed step by step against formal logic, so the output isn't just confident-sounding text.
The live debate is about what '90 of 500 open problems' actually means — open problems vary enormously in significance, and some of these formalized proofs may restate known techniques in Lean's syntax rather than discover new mathematical insight. Whether this is a watershed or a very well-documented version of existing math is still being argued.
Open-weights cyber risk debate is broken
Nathan Lambert argues that 'open-weight models are a cyber risk' has become a reflexive talking point in policy discourse, repeated without anyone weighing it against the economic and research value open weights actually produce — a symptom of AI-safety debate increasingly trading real tradeoff analysis for slogans. It's the kind of argument that looks airtight until someone asks what's being traded away, which is exactly the raw material worth picking apart in long-form writing rather than taking at face value.
Same model scores 2x differently by harness
Hugging Face built a capture proxy that turns unmodified coding agents — Claude Code, Codex, Hermes, OpenCode — into RL training environments by recording what already happens inside their existing harness, and found the same model weights score 62% in one harness and 33% in another, with training across multiple harnesses generalizing far better than training on just one. That reframes 'model benchmark' as really 'model-plus-harness benchmark': a great eval number tells you much less about the model alone than assumed, and a team built around one harness may be overfitting to its idiosyncrasies without knowing it. If you've ever had to control for the apparatus in a wet-lab protocol, this is the same move — the thing you run the experiment through turns out to be a variable, not a constant.
What’s RL-environment capture proxy?
A capture proxy sits between a coding agent and the APIs it normally calls, intercepting tool calls and model requests so the agent's existing harness — Claude Code, Codex, whatever it is — can be dropped unmodified into a reinforcement-learning training loop, recording the tokens and rewards needed to train against it.
It works because harnesses already standardize how a model sees tools and context; capturing that interface means you don't rebuild an environment from scratch for every coding tool, you just record what already happens when the agent runs normally.
The finding that reframes things is that the harness wrapping a model turns out to move scores as much as the model itself does. The live question is whether future agent evals need to report the harness as a first-class variable rather than an implementation detail nobody mentions.