Field Notes
Dispatches from the Argument Factory
This project began as a joke about making Sam Altman and Dario Amodei fight as badly coordinated robot boxers, but it quickly turned into something much more serious: an experiment in open models, local AI, comparative retrieval, and evidence-grounded argumentation. Frustration with expensive, opaque cloud tools pushed the work back toward inspectable local systems, while the original boxing gag evolved into a platform that can build curated intellectual corpora, uncover hidden disagreements inside a user’s question, and measure how much the written record actually supports the fight. The project was built across several AI collaborators, each seeing a different part of the work, so the article ends by letting those models tell the story from their own corners.
This project started because I made a joke about Dario Amodei being mad that I indexed Sam Altman’s blog and not his.
The truth is, I was a little annoyed.
I had just read Anthropic’s position on open-weight models. It is not a simple call to ban them – Dario explicitly says that less-capable open models are a public good – but the argument still arrives wrapped in the familiar language of national security, dangerous actors, chip controls, surveillance, and the need for sufficiently powerful institutions to decide who gets access to sufficiently powerful tools. Where's the trust, man?
I understand why Anthropic wants to protect its models. OpenAI’s position is made equally clear from its observable behavior. These are expensive systems built by companies with real commercial interests, and I will continue paying for access when the tools are useful. I just don’t appreciate being gaslit about openness.
And I have very little patience for “national security” as a conversation-ending phrase. My politics are well established. When someone says a system needs to be protected, my first question is always: whose system?
So naturally, I decided the responsible response was to make Dario Amodei fight Sam Altman as a pair of badly coordinated mechanical boxers.
Local AI is how I got into this in the first place. Before I was paying monthly fees to increasingly polished interfaces, I was downloading models, fighting with Python environments, watching my GPU run out of memory, and trying to understand why one obscure configuration change made the difference between a useful result and complete garbage. It was complicated, frequently irritating, and far more educational than clicking a button on a website.
Over time, though, I drifted toward the cloud like everyone else.
The cloud tools were better. Or at least they appeared better. They came wrapped in immaculate landing pages, cinematic demo reels, carefully chosen generations, and interfaces designed to get me from curiosity to credit-card charge with as little friction as possible. Upload an image. Type a sentence. Receive the future.
I paid because some of the tools were genuinely useful. I still do. I am not interested in pretending that running everything locally is morally pure, financially efficient, or technically superior. My local workstation contains an RTX 5090, so any argument I make about democratized computing should probably include an asterisk the size of a refrigerator.
But the deeper I got into generative video, the more the polished presentation began to feel dishonest. The demos suggested direction. What I encountered was probability.
I could describe a simple shot in excruciating detail (film-school dropout, here): fixed camera, one robot, one arm, one short jab, return to guard. The system might move the wrong arm, rotate the body, redesign the robot, introduce a dramatic camera move, or decide that what the scene really needed was atmospheric debris. It could produce something beautiful. It could not reliably produce the thing I asked for.
That distinction matters once you stop making disposable clips and start trying to build a system.
A landing page only needs to show that an astonishing result happened once. Production requires understanding why it happened, reproducing it, changing one variable without destroying the rest, and preserving the useful parts when the model inevitably misbehaves. The technology is extraordinarily capable, but it remains unruly, probabilistic, and poorly understood – even by the companies selling access to it.
The standard response is to buy another generation. Try a stronger prompt. Spend more credits. Switch models. Upscale the least-wrong result. Accept that five seconds of usable motion may require fifty seconds of expensive failure.
Back to ComfyUI. Back to local models. Back to LoRAs, workflows, checkpoints, schedulers, frame extraction, controlled tests, and all the other machinery the cloud interface hides. Back to the kind of system where failure is still common, but at least the failure leaves evidence.
This time I was not doing it alone. I gave a Codex instance control of the installation. It learned the environment, built workflows, downloaded and validated models, tested custom looks, ran renders, recorded results, and gradually turned a pile of generative tools into something resembling an asset-production factory. The difference was not that local generation suddenly became easy. It became inspectable.
We could hold the seed constant. Compare LoRA strengths. Preserve working workflows. Separate image generation from motion generation. Test one dependency at a time. Reuse models instead of renting another roll of the dice. When something failed, we could ask whether the problem was the prompt, the model, the adapter, the workflow, the quantization, or the custom node that had quietly detonated the Python environment.
That is slower than instant gratification. It is also how you build knowledge. And this is where the politics of open models stops being abstract for me.
Open access does not guarantee that everyone can run frontier systems. Hardware costs money. Electricity costs money. Time and technical skill are not evenly distributed. “You can run it yourself” is not the same as universal access. But it creates a different relationship with the technology. I can inspect the system. Modify it. Keep a working version after a company changes direction. Build automation around it. Learn from the failures. I can hand operational control to an agent without also handing the entire project to a vendor’s pricing model, moderation layer, product roadmap, and continued willingness to serve me.
That is not independence in some pure, heroic sense. The models came from somewhere. The hardware came from somewhere. The software stack rests on thousands of other people’s work. It is, however, a meaningful reduction in dependence. The irony is that the local approach began as the fallback. The cloud tools promised speed, quality, and simplicity. When they failed to deliver the control the project required, I returned to the complex system I had been encouraged to consider obsolete. The complicated system turned out to be the thoughtful one. It demanded more from me up front, but it also allowed the work to accumulate. Every failed render could improve the workflow. Every installed model became part of a reusable library. Every test made the next test less arbitrary. Instead of repeatedly purchasing isolated outcomes, I was building capability.
This experience changed the argument I thought I was having with Anthropic.
The question was no longer simply whether open models are good or dangerous, or whether companies have legitimate reasons to protect expensive systems. Of course they do. The question was what kind of technological culture we are creating when the most capable tools are available primarily as opaque, metered experiences optimized for consumption rather than understanding.