Asking AI to Speed Up Your Code: Lessons From 30 Models

On September 17, 2026 Anthropic published a report on what happened when it pointed an AI agent at more than 30 open-source scientific models and asked it to make them faster. The agent, described only as an internal general-purpose research model, worked for just under four weeks under the supervision of two staff who knew the science but had never written a GPU kernel. Anthropic says the models came out roughly four times faster with a small, measured loss of precision, and roughly 1.6 times faster with outputs identical to the originals.

The models are for biology, and this post is not about biology. It is about the shape of the job, which is one most companies have: software that works, is slow, and that nobody has time to tune. The report is the most detailed public account so far of an agent doing that work at scale, and the useful part is not the speed-up but the discipline around it. Everything below is drawn from Anthropic's post and the README of the open-sourced code, both read on September 18, 2026. The figures are Anthropic's own and have not been reproduced by a third party.

The models in question predict the three-dimensional shape of proteins from their chemical sequence, design new proteins, or read genetic sequences. They are widely used and expensive to run. Anthropic's earlier protein-design work had let an agent spend up to $10,000 of GPU time per target, which the company notes is out of reach for most researchers, so it set out to make the underlying models cheaper to run. An earlier pass with Claude Mythos 5.1 had sped seven of them up by as much as 2.5 times; this report covers the wider effort that followed.

Two further results sit alongside those averages. A set of custom GPU kernels, which Anthropic calls FlashPairformer, targets the two operations that dominate runtime in these models; Anthropic says they beat NVIDIA's cuEquivariance library by 2.7 to 2.9 times on one operation and 1.7 to 3.2 times on the other, depending on configuration. And a low-memory mode lets the models handle inputs larger than 10,000 tokens accurately on a single GPU node, and run at all on inputs above 70,000 tokens on one eight-GPU node, where the predictions are no longer accurate but the run completes. The company is also co-sponsoring a protein design competition with Adaptyv Bio, with up to $1 million in Claude credits and laboratory testing for over 5,000 designs.

Most requests to make code faster produce one number and an argument about whether the output changed. Anthropic's report avoids the argument by splitting the question in two before any work starts. The first number is the speed-up you get while every output stays identical: reordering work, caching what was being recomputed, removing branches that can never run. The second is the speed-up you get once you accept a stated, measured difference in the output, such as lower-precision arithmetic inside a hot loop.

The second number is only meaningful if the tolerance is chosen before the agent begins, by someone who knows what the software is for. In Anthropic's case that someone used a threshold the field already uses: a predicted molecular interface counts as acceptable when a standard quality score is above 0.23, and the fast modes were accepted because their pass rate on a pooled test set was statistically indistinguishable from the original settings. The agent did not get to define "close enough". The released code turns the same split into a user-facing vocabulary:

One line in the README is worth more than the mode names. A run prints which mode is engaged; a mode that cannot engage on the machine prints the reason and exits with an error; and, in the README's words, a kit "never falls back to stock silently". Any optimisation an agent hands you should behave the same way, because the failure you cannot see is the one that reaches production.

The report does not publish its prompts, but the sequence of work it describes is ordinary performance engineering, and it is the sequence to give an agent on any codebase.

1. Freeze a test set and a baseline. Fix the inputs, record the outputs and the timings from the untouched code, and pin the version. The released kits carry the upstream release at a pinned version next to every optimisation for exactly this reason.
2. Profile, and name the hot operations. In these models two operations on triplets of tokens dominated both time and memory, growing with the cube of the input size. Your equivalent is whatever the profiler says, not what the team assumes.
3. Take the free wins first. Cache work that is recomputed, and replace branches that always resolve the same way with their constant result. These are the changes that produce the identical-output number.
4. Then the changes that need a tolerance. Custom kernels and lower-precision paths go here, and each one is accepted or rejected against the tolerance set in advance.
5. Check outputs before you measure speed. Every accelerated model was compared with the original on its downstream task before its speed-up counted. A fast wrong answer is a bug with a good benchmark.
6. Ship it as a switch, not a fork. The user calls the tool exactly as before and names a mode. Nothing about the interface changes; only the runtime does.

The report names four kinds of optimisation. They differ in how much they can break and in what makes each safe to accept, which is the column an engineering lead should read.

The staffing detail is the one most likely to be repeated elsewhere, so it is worth stating exactly. Anthropic says the agent was supervised by two members of its technical staff who were experienced in biomolecular modelling but had no prior experience in inference optimisation or kernel engineering, and that producing such optimisations normally takes an experienced team of engineers weeks per model, with little of the work transferring between models. The supervisors supplied what the agent could not: knowledge of what a correct output looks like, which test cases matter, and which threshold the field would accept. How much of Anthropic's own research work now runs this way, by its own count, is tabled in our census of disclosed AI share-of-work figures.

The limits are stated in the same post and should travel with the numbers. The speed-ups are Anthropic's own measurements. One comparison, against a newly released fast mode in another tool, is explicitly not yet benchmarked. The largest inputs the memory mode can run are not predicted correctly, and Anthropic says so. And the released code is a reference release: the README states it is not maintained and does not accept contributions, so anyone who adopts it owns it from that day, which is the situation our guide to owning AI-built software describes.

The same job exists in most companies at a smaller scale: a nightly report that takes four hours, a pricing calculation that times out under load, an image pipeline that costs more in compute than it earns. Three things have to exist before an agent is pointed at any of them, and none of them is technical.

• A frozen test set with recorded outputs. If the current outputs are not saved, there is nothing to compare against and the identical-output number cannot be produced.
• A written tolerance, signed off by the owner. For a pricing engine that may be zero. For a recommendation ranker it may be a small change in a ranking metric. It is decided by whoever answers for the output, before the work.
• A profile of where the time goes. An agent can produce this itself, but a person should read it before approving the plan, because the hot path is where the changes will land.

The output is then two numbers and a switch. We covered the complementary case, an agent cutting test-suite time rather than runtime, in our post on Anthropic's test-impact analysis, and the same rule held there: measure against a frozen baseline, and keep the old path one flag away. If you want that done on a system you run, with the test set and tolerance agreed before an agent touches the code, our AI transformation service starts with those two documents.