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

Anthropic reported on September 17, 2026 that an internal general-purpose research agent optimized more than 30 open-source scientific models in just under four weeks, achieving roughly 4x speed-ups with a small measured loss of precision and roughly 1.6x speed-ups with bit-for-bit identical outputs. The agent was supervised by two staff who knew the science but had never written a GPU kernel, and Anthropic says the work normally takes an experienced team weeks per model. Anthropic's custom FlashPairformer GPU kernels 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, and the company open-sourced 36 drop-in optimization kits; the figures are Anthropic's own and have not been reproduced by a third party.

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 https://www.anthropic.com/research/claude-uplifts-biomolecular-modeling and the README of the open-sourced code https://github.com/anthropics/uplifting-biomolecular-modeling , both read on September 18, 2026. The figures are Anthropic's own and have not been reproduced by a third party. 1. 01Ask for two numbers, not one.The speed-up with identical outputs, and the speed-up at a tolerance you set before the work starts. Anthropic reports roughly 1.6x and roughly 4x for its structure-prediction models. 2. 02The checks came from the science, not the agent.Fast modes were accepted because they were statistically indistinguishable from the defaults on a fixed set of test cases, using a threshold the field already uses. Pick your own before the agent begins. 3. 03Every change shipped under a named mode.The released code runs stock, exact, fast or big on request, prints what is engaged, and refuses to fall back silently. That is the packaging pattern to copy. 4. 04Two staff with no kernel experience supervised 30-plus models.Anthropic says the work normally takes an experienced team weeks per model. The supervisors' job was to know what correct looked like, not how kernels work. 01 — The reportWhat Anthropic reported 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. Average speed-up, small precision loss Across over a dozen structure-prediction models, with per-model checks that the change did not affect the downstream task. Anthropic's figure, from its own benchmarks. Average speed-up, identical outputs The same models, restricted to changes that leave every output bit-for-bit as before. The post's introduction rounds this to nearly 2x; the figure caption says roughly 1.6x. Models optimised in under four weeks The repository ships 36 drop-in optimisation kits, one per upstream tool, across structure prediction, protein design, protein language models and genomics. 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. 02 — The lessonThe two numbers to ask for 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: off The pinned upstream release exactly as published, nothing engaged. The baseline every other mode is measured against. exact Faster, with outputs identical to stock. The safe default for anyone who cannot tolerate a changed result. fast Faster still, with small numeric differences the README says stay within the tool's own run-to-run variation. Usually the default where a kit ships it. big For inputs the other modes cannot hold; can split one prediction across the GPUs of a single host. 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. 03 — The methodThe method, as steps 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. "Report two speed-ups on the frozen test set: one with byte-identical outputs, one within the tolerance in TOLERANCE.md. Any change that fails either check is rejected, and any mode that cannot engage must say so and stop." That is the whole contract, and it is the part of Anthropic's report that transfers to a pricing engine or a rendering pipeline without alteration. 04 — The changesFour kinds of change, and their risk 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. | Our reading of the optimisation types named in Anthropic's September 17, 2026 post and the repository README. The safety column is our guidance, not Anthropic's. | | | | |---|---|---|---| | Change | What it does | Which number it moves | What makes it safe to accept | |---|---|---|---| | Caching | Stores a result that the code was recomputing on every pass. | Identical outputs | Byte-identical results on the test set; a check that the cache is invalidated when its inputs change. | | Dead-branch removal | Replaces a branch that always resolves the same way with its constant output. | Identical outputs | Proof, from the pinned configuration, that the branch cannot be reached; a test that fails if the configuration changes. | | Custom kernels | Rewrites the hottest operation for the hardware, as FlashPairformer does for two triangle operations. | Either, depending on arithmetic | A per-configuration comparison against the reference implementation; the tolerance stated in the mode's documentation. | | Memory mode | Trades peak memory for time so that a larger input fits on one machine. | Capacity, not speed | Accuracy checked at the sizes it claims to handle; an explicit statement of where it stops being accurate, as the post gives for inputs above 70,000 tokens. | 05 — The peopleWhat supervision looked like 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 https://www.digitalapplied.com/blog/ai-share-of-own-work-tech-companies-disclosed-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 https://www.digitalapplied.com/blog/ai-built-app-maintenance-ownership-guide describes. 06 — Your codeRunning it on your own code 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 https://www.digitalapplied.com/blog/anthropic-ci-25x-growth-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 https://www.digitalapplied.com/services/ai-transformation starts with those two documents. 07 — Next stepThe discipline was the result Write the tolerance for your slowest system this week The four-times figure will be quoted for a year. The part worth copying is that Anthropic decided what correct meant before the agent started, measured outputs before speed, and shipped every change as a mode the user chooses. Pick the slowest thing you run, save its current outputs on a fixed set of inputs, and write down how different the new outputs may be. An agent can do the rest, and you will know whether it did.