The headline from the recent New Stack experiment reads like an AI pitch deck. Six AI agents, a Playwright harness, and thirty-three dollars of token spend rendered a walkable 3D virtual city in a single shot. The number is real. The story is more complicated than the headline, and the complications are the part worth your time. Because the gap between “the demo run cost thirty-three dollars” and “your next agent project will cost thirty-three dollars” is measured in coordination overhead, contract design, and a verification burden that scales superlinearly with the number of agents.
What follows is not a takedown of the experiment. The experiment is a useful proof that the floor has moved. What follows is a closer read of the cost structure, the failure modes, and the specific things you would have to do to reproduce the result on your own project without the bill ballooning past the headline price.
What the dollar figure actually counts
The thirty-three dollars is the price of the inference calls, full stop. It is not the cost of the experiment. The experiment also includes a developer who spent days wiring up Playwright, designing the agent contract, debugging the inevitable coordination failures, and writing up the result. If you priced the project the way a contractor would price it, the labor alone is several thousand dollars at standard rates. The thirty-three dollars is the cost of the raw material. The cost of the workshop is separate.
This matters because the next project you try to scope will be pitched against this number. Someone in your team will hear “thirty-three dollars” and assume the next agent build is similarly cheap. It is not. The thirty-three dollars is the cost of one specific build, with one specific contract design, by one specific developer who already absorbed the learning curve on prior agent projects. Your first attempt at the same build will cost more in debugging time and more in revised inference calls as the agents re-discover the project structure each iteration.
The headline price is real but misleading. Plan your budget against the realistic version, not the demo version.
The cost that grows faster than the number of agents
The single largest hidden cost in multi-agent projects is verification. With one model, you read the output. You spot the bug. You fix it. With six agents writing to the same project, you have to verify that the file tree is consistent, that no agent wrote outside its defined scope, that the manifest matches the actual state of the project, and that the handoff points are clean. The verification work does not scale linearly with the number of agents. It scales faster than that, because every pair of agents introduces a potential conflict that has to be checked.
If you have six agents with no defined boundaries, the verification cost is the dominant cost in the project. Most of the bugs you will hit are not model bugs. They are coordination bugs, where one agent’s output conflicts with another agent’s output in ways the manifest does not catch. The debugging time on coordination bugs is hours per bug, not minutes. Add it up over a project and the inference cost is the smallest line item.
The teams that ship multi-agent projects successfully invest the verification cost up front. They write the contract that defines each agent’s read and write boundaries before the first prompt. They pick one agent to be the manifest writer and forbid the rest from touching the manifest. They log every agent call with input, output, and version metadata so the audit trail is reconstructable later. None of this work shows up in the headline price, and all of it is required to keep the project from collapsing under its own coordination debt.
What Playwright actually bought
The experiment leaned on Playwright as the orchestration layer, and that choice was load-bearing. Most agent projects die because the team tried to build a custom orchestrator. They wrote a state machine, added retry logic, built a queue, and ended up spending three weeks debugging the orchestrator instead of shipping the thing the orchestrator was supposed to build. Playwright sidesteps that trap by using the browser as the state machine. The browser already handles the messy parts of state. The agents just have to drive the browser.
The pattern is reproducible. The pattern is also specific. Playwright works because the agent output is HTML and JavaScript. If your agent output is a different medium, you need a different orchestration tool. The general principle is that you want the orchestration layer to be something battle-tested, not something you invent. The cost of inventing an orchestration framework from scratch is measured in months, not days. The cost of using the browser is measured in hours.
Five starting points that worked for teams I have watched try this pattern:
- Pick a target smaller than a virtual city for your first attempt. A single coffee shop interior is enough to hit coordination problems.
- Use three agents instead of six. Three is enough to surface the coordination failure modes. Six amplifies the verification cost without teaching you anything new.
- Write a one-page spec the agents can read before you write any prompts. The spec is the contract. The contract is the prerequisite for the rest.
- Cap your spend at ten dollars and stop when you hit it. The cap forces you to design efficiently instead of relying on the model to brute-force the answer.
- Document what broke. The writeup is more useful than the render. The render gets the clicks. The writeup moves the field.
What you can actually steal for your own build
The useful pattern from the experiment is not the dollar figure. It is the workflow. Use a battle-tested orchestration layer. Define agent boundaries before you start. Pick one agent to be the source of truth on project state. Cap your spend. Document the failures.
The less useful pattern is the project itself. Building a walkable virtual city is a cool demo and a poor first project. The visual output is hard to verify, the coordinate system is fragile, and the user research question of “what would I do with this” is wide open. Pick a project where the verification step is mechanical. A spreadsheet is good. A script that produces a CSV is good. A 3D city is harder. Start with the mechanical verification, then move to the visual projects.
Trade-offs
Multi-agent projects are not free in coordination cost. The first cost is the contract design. Six agents with no manifest writer will produce chaos in two iterations. Defining the read-write boundaries, the output format, and the handoff points takes longer than picking the model. The teams that ship successfully invest the contract design time before they ship any prompts.
The second cost is the iteration cost. Each revision requires the agents to re-discover the project structure, which means the second build costs more than the first. Treat each project as a fresh island or budget for the re-discovery cost. There is no middle ground.
The third cost is the verification cost. With one model, you read the output. With six agents, you have to verify that the manifest is consistent, that the file tree matches the manifest, and that no agent wrote outside its scope. That verification work scales superlinearly. For projects with more than four agents, budget for a dedicated verification pass on every iteration.
For solo weekend experiments, the headline price is real. For team projects that need to evolve over weeks, the maintenance cost dominates and the headline price stops being meaningful.
What I would tell past me
Three things I would send back to the version of me that tried to build an agent project with no coordination plan.
- Write the manifest before the first prompt. Every agent needs a defined scope, a defined output, and a defined handoff. The manifest is the contract. A vague contract produces chaos.
- Use the browser as your orchestrator. Playwright and similar tools are state machines someone else maintains. You do not have to invent one. Custom orchestration is where agent projects go to die.
- Plan to publish the failures. The first attempt will be a mess. That is fine. Write up what broke. The writeup is more useful than the render.
Bottom line
The interesting part of the six-agent virtual city experiment is not the thirty-three dollar headline. It is the proof that off-the-shelf agents can produce something visually real, given a clear coordination contract. The pattern is reproducible. The pattern is also fragile, and the failure modes are the same ones that plague human teams without a project manager. If you want to try this on a smaller project, the recipe is simple: pick a target smaller than Union Square, use three agents instead of six, write the manifest first, cap your spend at ten dollars, and document what broke. The documentation is the part that actually moves the field forward. The render is the part that gets the clicks.