OpenAI's Jerry Tworek and Box's Aaron Levie say open-source tools win because models use them best, a claim against their own side; our call is that the deciding moment may be execution, not training

Key takeaways

On September 5, Jerry Tworek, OpenAI's vice president of research, wrote that "The unexpected benefit of open source is that it allows model training companies to train on using your software (and optimizing it) for free." Then the claim that set off the argument: "Blender may have just won as a 3D asset creation software because the models will be better at using it than any proprietary ones". His reason is how well models use Blender, not how good Blender is to use. The next day, Box CEO Aaron Levie, whose company sells proprietary enterprise software, gave the software-side version of the same mechanism: "If agents produce the vast majority of software in the future, and they're most trained on open source software, they will inevitably do their best work with those tools. If you cycle this enough times, it means that open source effectively becomes the dominant software in the future as it's what everything important gets built with."

Two people, one standing on the model side and one on the proprietary-software side, both saying something that cuts against their own position. That removes the most common reason to discount a claim like this: neither is pushing a company line.

The conclusion of this piece: the shape of the mechanism is right, and it puts the deciding moment in the wrong place. Both speakers, and everyone reasoning along with them, assume that whether a model can use a given piece of software is decided at pretraining. The software's traces made it into the corpus, so the model learned it; they didn't, so it didn't. Nobody had measured that assumption. This year two papers did, and their answer runs the other way. Nearly three in ten of the operating scripts a model writes on its first attempt fail to run. But feed those failures back, together with the software's own error text, and allow at most two retries, and the share of scripts that execute goes from 70.2% to 97.4% on the 3DCodeBench authors' executability measure, single-turn against multi-turn, across the same models. That figure was measured on Blender, whose commands are already common in training data. Nothing was retrained and no corpus was added. The only new input was the error message.

Training buys only one part of what "models are better at using open-source tools" means, and on Blender two retries recovered most of it. And whether a retry is possible depends on something unrelated to a licence: whether an agent can actually run the software and read back an error written in plain language.

The route runs in six steps:

1. What this argument is about, and a rival reading in which model labs open-source their agent tooling to collect training data.

2. "The model is better at using it" split into two things that move in opposite directions. This is the piece's key split.

3. The width of that moat has been measured, and its unit is retries.

4. Proprietary vendors moved long ago, but what they bought is a different thing, and nobody has said so.

5. A very cheap control experiment that no one in the world has run.

6. Our call, and what would prove it wrong.

What does this add to the same item in the September 7 brief? Two things, both specific.

First, this piece attacks the test SecondSource wrote for its own call, and that test asked the wrong question. The brief's sentence read: "If within six months a first major proprietary application vendor publicly releases its own operating-trace corpus or an agent tool skeleton, and frames it as a distribution strategy rather than developer relations, the tool side gets hard evidence." That was checked. Autodesk, which owns Maya and 3ds Max, released a technical preview of an official MCP server for Revit in April 2026; Figma did the same in June 2025; Microsoft went further in May 2025 and made MCP a protocol layer. Revit is Autodesk's building-information-modelling software for architecture and engineering. It is not in the 3D-asset-creation category Blender sits in. Revit counts here only as one example of a proprietary vendor shipping an agent interface. All three releases were MCP operating interfaces, not the operating-trace corpus or agent tool skeleton the sentence named. The sentence's second condition, a distribution framing rather than developer relations, has not been counted separately in this piece. So the test has not been overturned. It simply cannot discriminate, because it never said what kind of thing the vendor would ship. It also cannot serve as evidence for either side, because what proprietary vendors ship and what open-source tools ship are not the same thing, and nobody has counted them apart.

Second, this piece writes down what would make it wrong, and one of those conditions it cannot rule out on its own. The 70.2%-to-97.4% figure was measured on Blender, and Blender's operating commands already exist in bulk in training corpora. So "retries work" may only mean the model already knew seven-tenths of the job and needed a nudge. Separating the two explanations requires running the same experiment on software the model has barely seen. No one has. This piece therefore stays a working read, not a settled call, and not for lack of sources: the control arm doesn't exist.

What the argument is about, and the opposite reading in SecondSource's own notes

The mechanism first, because it has a middle step that is easy to skip. One fact to pin down as well: Blender is free, open-source 3D software; Maya, 3ds Max and Revit are proprietary Autodesk products that require a paid licence.

Ask an AI to "make a 3D model of a wooden chair" and no 3D file materialises out of nothing. The most effective method today is for the model to write a piece of code, for that code to drive a professional application people already use, and for that application to build the chair. That alone is a reversal of expectations. Lucas Beyer, a multimodal researcher, co-author of SigLIP, formerly at DeepMind and now at OpenAI, said on July 25, 2026 that two years earlier he would "ABSOLUTELY NOT" have predicted this route would win. Beyer and Tworek both work at OpenAI, so Beyer's post doesn't count as independent of this piece's main anchor.

So the question becomes: which software does the model's code drive? The model has to know what that software's commands look like and what its parameters are called. Where does it learn that? The intuitive answer: from the public text about that software on the open web, meaning tutorials, source code, forums and example scripts.

That is the mechanism behind Tworek's sentence: only what is publicly observable enters the training distribution. Software that requires a login before it can be operated leaves no operating record for the model to read, so the model can't use it; Blender has everything laid out in the open, so models are especially good with it. And once the work is handed to an agent, "which tool the model is best at" becomes "which tool gets picked", because the user is no longer the one choosing the tool. The user still pays for the licence but no longer picks the tool by hand. A customer who has already bought the software lets an agent read and operate the customer's own files.

One thing to disclose here: SecondSource's internal notes carry a reading that runs the other way. It was never sent to readers and never became this publication's call. That reading takes the same mechanism as a data-harvesting strategy by model companies: labs race to open-source their own agent tooling not to win users but to get outside users to generate training data for them. The beneficiary sits on the model side, and users are supplying material for free. One physical fact, two opposite assignments of value.

This piece doesn't declare a winner, because its point is that both readings rest on the same unexamined assumption. Both presume that the moment deciding "will the model use this tool" is the training moment. If that assumption fails, both sides' questions about who collects the rent have to be asked again.

The key split: "the model is better at using it" is two things

Anecdotes blur several different things into one, and nothing is visible until they are pulled apart. So the first step is the split.

"Models are better at using Blender" breaks into two entirely different abilities:

The split matters because both speakers' claims land only on the first row. Tworek said the models will be "better at using it", not that they understand 3D better. What open source buys is the model recognising a command set, not the model acquiring taste.

A paper this June measured the two separately. 3DCodeBench is a benchmark for whether multimodal models can work as procedural 3D modellers: given text or an image, the model writes code, and the software executes it into a 3D object. The author list includes Google researchers; the paper was submitted on May 31, 2026, and tested 12 frontier models on 212 object categories.

Its two findings fall exactly on the two rows, and point in opposite directions:

• On tool fluency, failure is indeed the main story. The paper's first finding reads, verbatim, "Failures mostly arise from API mismatches": the model misremembers a function name or a parameter format. That is precisely the failure mode Tworek's mechanism predicts, and on this point Tworek is right.
• On domain ability, open source didn't rescue anything. The second half of the same sentence: "while successful renders still suffer from disconnected or floating 3D geometric components". The renders that do run have parts scattered or floating in space. The paper's qualitative analysis is blunter: models capture the basic silhouette but often fail on structural integrity, degrading into scattered geometric fragments.

So: in the Blender case, models really do speak Blender better; and the chairs still come out in pieces. The inference "models are best at using Blender, so Blender has won 3D creation" has no support on the second row. Being able to operate a tool and being able to make something usable with it are two different things, and only the first has anything to do with open source.

That is already enough to shrink "Blender may have just won" by a good margin. What actually flips the mechanism over is the next section.

The width of the moat can be measured, and its unit is retries

If "the model recognises the command set" is what open source buys, what is it worth?

The question couldn't be asked before, because nobody had measured it. 3DCodeBench measured it, with a method cleaner than expected.

The authors first had each model answer in one shot and recorded what fraction of the code actually ran inside Blender (the paper's term is executability). Then, for the scripts that failed, they did something very simple: send back the original task, the code the model wrote last time and the raw error text the software emitted, and ask for another attempt. At most two retries.

It is worth spelling out how bare that retry loop is, because it is the crux of the whole piece:

"Each retry is a fresh API call — not a chat continuation — whose user message contains the original task, the previous attempt's full Python code, and the truncated stderr/traceback"

Every retry is a brand-new call, not a continued conversation: the model remembers nothing of what just happened and receives only the task, the previous code and a truncated error. No human touches the process. The model never sees the rendered image, and nothing is retrained for it. The input is one piece of machine-generated error text.

The result:

"Aggregate executability across all 11×2=22 cells increases from 0.702 (single-turn) to 0.974 (multi-turn), representing a +27.2 pp improvement"

Executability goes from 70.2% to 97.4%. This aggregate covers 22 measurement cells across 11 models, one fewer than the 12 models tested elsewhere in the paper; which model is missing from the aggregate, and why, remains unchecked. The strongest models hit 100% outright after multiple turns.

Put that figure back into the mechanism. What the free training on a vendor's software buys, in Tworek's framing, is the probability that the model writes the script right the first time. Retries recover more than nine-tenths of the nearly three in ten scripts that fail the first time. All that takes is an agent that can run the code, get an error back and try once or twice more.

A second, independent figure points the same way. VIGA, proposed in January by a group at Berkeley, CMU and Max Planck, is a write-render-inspect-revise loop, and the paper states that it is training-free. On BlenderBench, a benchmark the same paper proposes, VIGA shows a large improvement over a single-shot baseline. The two papers come from different teams and test different tasks. Both point to the same conclusion: the loop that lets a model see its execution result replaces a large share of what was supposed to be bought with training.

This matters because it moves the deciding moment from a point a vendor can barely control to one a vendor controls completely:

• If the deciding moment is training time: all a vendor can do is lay everything out on the open web and wait for the next training run. The vendor cannot know when the crawler will come or whether it will pick anything up. The path is slow, gives no second attempt and cannot be undone. For proprietary software the cost is prohibitive, because it means abandoning the licensing model.
• If the deciding moment is run time: the job is to make the software runnable by an agent and to write error messages a model can act on. That is fast, purchasable, changeable at any time, and requires no open-sourcing at all.

That is the shift in position this piece argues for. And it happens to explain the thing nobody has said in the next section.

Proprietary vendors moved long ago, but they bought a different thing

Recall that the brief's test read: "If within six months a first major proprietary application vendor publicly releases its own operating-trace corpus or an agent tool skeleton, and frames it as a distribution strategy rather than developer relations, the tool side gets hard evidence." More than one vendor has already shipped. What they shipped, every time, is an MCP operating interface, not either of the two things the sentence named:

MCP is the key to this section. MCP is a protocol that appeared at the end of 2024 and was adopted across the industry; it gives an outside AI assistant one standard way to read or operate a piece of software. Its origin was no grand strategy: two Anthropic engineers, tired of copying and pasting between the desktop app and their editor, built it in a month and a half. By 2026 the public directories list nearly 20,000 MCP servers.

So the question "wait and see whether proprietary vendors pay to enter" has an answer: they entered more than a year ago, Autodesk included. On its own that looks like support for the "tool side collects rent" camp: even a vendor that charges by the licence, like Autodesk, is hurrying to let models use its products.

But take the Autodesk entry apart and the story changes completely. Autodesk's Revit MCP server:

• works only with Revit 2027;
• is installed from the Extensions section of `manage.autodesk.com`, meaning it sits behind the paid licence;
• and is read-only, according to Harlan Brumm of Autodesk, whose title isn't confirmed: "This release includes read-only tools that are safe for you to engage with your model without risking changes". An agent can touch a Revit model file without risk of altering it. The current tool set can't make any change to Revit. Autodesk's own page could not be retrieved; the quote and the installation details come through a secondhand relay.

In other words, Autodesk didn't buy "let models learn to operate Revit". Autodesk bought "let the agent of a customer who has already paid read that customer's own files". Commercially those are worlds apart, and the current discussion treats them as one.

Separating the three things is the table this piece exists to give:

The third row can be bought with money, and the whole industry has already bought it. The first two can't.

The second row is the one this piece considers most underrated, because it decides something else: who shows up in the tests everyone uses to compare models. That deserves its own section.

The tree above is about competition within the agent execution layer: who gets to be the commander that "gets things done across tools and devices". What this piece adds is the layer beneath it: which tools the commander can reach, and what sets that range. The fork in the tree asks who owns the execution layer. This piece asks who the execution layer can touch. If run-time reachability decides which tools an agent picks, whoever owns the execution layer also decides which vendors' software the agent can reach. That link is this piece's inference.

A very cheap control experiment that no one has run

Proving "models are better at using open-source tools" needs an experiment that is actually simple: take one set of 3D modelling tasks, have the model drive Blender for one group and Maya for the other, and compare success rates.

No one has done it.

And the reason is not that it can't be done. A check of today's main agent-operation benchmarks shows a very tidy shape:

• In 3D, it is all Blender. 3DCodeBench (2026-06), BlenderBench (2026-01), BlenderGym (cited via other papers; the original hasn't been reviewed), and another paper, "Thinking in Blender" (2026-06): four benchmarks, all built on Blender, none on Maya or 3ds Max.
• And the authors say in the paper that this wasn't a capability judgment. 3DCodeBench states, verbatim, that the authors implement on Blender 5.0 as a representative platform while the method is software-agnostic:

"we instantiate ... on Blender 5.0 as a representative platform ... but the formulation is software-agnostic"

Blender was chosen not because it measured better, but because one had to be chosen. The control arm that could tell who is right, the authors could have run. They didn't.

An honest counterexample weakens the claim above and has to be stated, because it exists: proprietary software is not shut out of benchmarks. Microsoft's own Windows Agent Arena runs on real Windows. WindowsWorld, from Harbin Institute of Technology this April, covers 17 desktop applications, including Word, Excel, PowerPoint and Acrobat, all paid proprietary software. WindowsWorld has 181 tasks. The best model tested on it succeeds on about 20.44% of them.

So the sentence "proprietary software can't get into benchmarks" is false and can't be written. But the same list has a more precise shape: the proprietary software those benchmarks cover is office software, and the image editors they include are GIMP and Microsoft Paint, not Photoshop; in 3D, Blender, not Maya. The more specialised the creative or engineering software, and the higher its per-seat price, the less it appears in public evaluation. Maya's public list price is US$2,010 a year, and a benchmark runs thousands of episodes in parallel. The rest of this paragraph is inferred from this section's logic, not measured: high-priced professional creative software like Photoshop sits in the same structural position as Autodesk. Agents are better at GIMP not because GIMP is better but because GIMP can get into the benchmarks. Over the long run, vendors that use licensing to keep agents out are losing ground to the evaluate-and-optimise loop. Open source is not beating them head-on.

This loop is self-reinforcing: software that no public test measures appears on no comparison chart of "what models are best at", and when model companies work on agent capability they optimise against those public tests. That really is a positive feedback loop favouring open source. But the loop it runs on is evaluation and optimisation, not the pretraining corpus Tworek described. The conclusion matches Tworek's, but the mechanism is evaluation and optimisation, so the remedy is different too.

Our call, and what would prove it wrong

Our call:

What decides whether a piece of software gets picked by agents is not whether its source code is public, but whether an agent can run it and read back a machine-readable error. Public source code matters at pretraining, which is slow and prohibitively costly for proprietary software. Whether an agent can run the software is decided at run time and can be bought with money. The whole industry has been buying agent interfaces for more than a year. The only measurement so far, on Blender scripts, says that up to two retries recover most of the advantage public source code buys at pretraining. That has not been tested on software the model has barely seen.

On this call, "can agents operate our product?" is not a question about open-sourcing for the C-suite of a proprietary software vendor. That vendor's answer to open-sourcing is always no, so framing it that way leads nowhere. The real questions are three concrete ones:

1. Can an agent run the product at all? Is there a machine-readable interface that doesn't require a mouse. The industry already has a ready answer in MCP, and most of a vendor's peers have shipped one.

2. When the agent hits a wall, does it get back an error in plain language? This is the piece's most counterintuitive point: a vendor's error-message quality is now a distribution asset. The 70.2%-to-97.4% figure rests entirely on it. An API that returns "Error: invalid operation" and an API that returns "parameter radius must be positive; received -1" are, to an agent, two completely different products.

3. Can the product be run free and in parallel as a test environment? This is the most expensive row and the one fewest vendors think about: it decides whether the product shows up in the comparisons others use to rank models. The form that fits is a free, parallelisable, headless execution layer for research and evaluation use. It does not require open-sourcing the product.

What would prove this wrong:

Of the four conditions, only the third has a time window; the first, second and fourth are event-triggered. The thing to watch is whether someone runs the experiment, not a date.

1. The most fragile point, and one this piece cannot rule out on its own. The 70.2%-to-97.4% figure was measured on Blender, and Blender's operating commands exist in bulk in training corpora. So "retries close the gap" may only mean the model already knew seven-tenths of the job. If someone runs the same retry experiment on software the model has barely seen, and executability does not jump with it, the core claim of this piece collapses: the training distribution is the real threshold, and retries are only its expression. No one has run that experiment; until that control exists, this piece stays a working read and doesn't upgrade.

2. If someone actually runs the Blender-versus-Maya comparison on the same tasks, and the open-source side keeps a clear advantage after controlling for the model's number of retries, then Tworek's original version gets the measurement it has always lacked, and this piece retreats. That comparison doesn't exist today, so this condition sits waiting for a reading.

3. If over the next two quarters proprietary vendors' agent interfaces start moving from read-only to writable, and stop sitting behind the paid licence, meaning the vendors really start giving up the paywall in order to get into the training distribution, that signals the vendors believe the training distribution is the crux, and this piece's reading that the vendors bought a different thing is wrong. The two-quarter window is SecondSource's own; neither speaker gave a deadline.

4. Conversely, if general graphical-interface operation matures to the point where a model can operate any program with no software-specific prior knowledge, then "publicly observable" stops being an entry condition at all, and both sides of this argument fail together. That route is still far from mature: on WindowsWorld, this April's benchmark of 17 desktop applications, the best model tested succeeds on about 20.44% of tasks.

One place is easy to skip. This whole argument, including the unpublished opposite reading in SecondSource's own notes, assumes that what a model learns to use is decided inside someone else's training cluster. The vendor has no part in that moment. The only measurement on the table, on Blender, says that much of it is decided when the vendor's software emits one line of error text. The vendor wrote that line.

Written from the same research and judgments as the Traditional Chinese edition. Sources are linked; we distinguish original documents from reporting and mark what we could not verify.