Metered agents make portable orchestration a cost decision

I spent an afternoon this week reading the pile-on. A flat-rate coding assistant flipped its agent tier over to token-metered credits, and a thousand vibe coders sat down and did the math on what a normal day of loops would burn. The anger was real and mostly fair. But the price was not the part that held my attention. The part that held my attention was how many people had no way out.

This is not one vendor's price card, and it is not worth writing about as if it were. The agent layer, the headless runs, the loops that fire while you sleep, all of it is getting priced like raw compute, separate from the chat window you type into. A second platform repackaged its own agent tier the same month, and the shape is identical in both. Running a fleet of agents against your codebase is now its own product with its own meter. That is a category move, not a single billing email.

I wrote a few days ago about instrumenting what a metered fleet actually costs per task, and that still holds: measure the spend before the bill teaches you the shape of it. But measuring only matters if you can act on what you find. The operators getting hit hardest this week are not the ones who failed to measure. They are the ones whose entire orchestration speaks exactly one vendor's dialect. When your build pipeline, your agent calls, and your tooling are all welded to a single lab, that lab's pricing decision is your cost structure, and you get to absorb it. No exit, no leverage, no second quote.

the boring setup that turns out to be the hedge

The way I run a fleet looks deliberately dull by comparison. The roles sit on different labs on purpose. One model architects, a different one builds, a third goes and researches the unfamiliar parts, a fourth tries to break what shipped. None of them is load-bearing on its own. The thing that makes that work is not loyalty to any vendor. It is that the orchestration talks to each role through a spec, not through vendor-specific glue. The builder does not regenerate against vibes, it regenerates against a written contract: inputs, outputs, invariants, edge cases. Once the work is specified instead of the tool, the lab underneath becomes swappable. I did not bolt portability on as a principle. It fell out of speccing the job.

That is the part worth sitting with if you vibe code anything past the toy stage. Spec-first discipline gets sold as a quality argument, a way to stop the agent from drifting off-contract. It is that. But the same contract that keeps the build honest is also the thing that keeps the vendor underneath replaceable, because the contract, not the vendor's call signature, is what the work depends on.

portability stopped being a taste argument

Portability used to be the kind of thing you argued for on taste. I made that case about not coupling orchestration to any single lab before any of this was billed, and the honest version of that post admitted it was partly hygiene and partly paranoia. Metered billing settles the argument with a number. When the costly work can route to whichever lab is kindest this quarter, portability stops being a virtue and starts being a line on the spend sheet.

The failure mode to watch for is the team that swears it is portable in principle while a thousand vendor-specific hooks quietly pile up in practice. Those teams find out at switching time that the lock-in was never in the contract, it was in the glue code, and the glue costs more to tear out than the meter ever would have. Portable-in-principle and portable-in-practice are not the same claim, and a pricing change is what settles the difference.

The move is unglamorous. Keep the contract layer vendor-neutral. Specify the work, not the API. Route the expensive loops to wherever the meter is kindest and leave the cheap conversational stuff wherever it is convenient. Do not hardcode one lab's call signature into the spine of your orchestration, because the spine is the expensive thing to change later.

If you are formalizing your AI orchestration and you want it to survive the next pricing change instead of flinching at it, that is exactly the kind of thing worth speccing on purpose. Work with VibeKoded if you want a sparring partner on making the orchestration portable before the next meter turns on, not after.

The meter is doing portability a strange favor. For years, keeping your orchestration loose and vendor-neutral was a discipline you practiced because it felt right and paid off rarely. Now it pays off every billing cycle, in a currency the finance side already understands. Spec the work, keep the labs swappable, and the next pricing change becomes someone else's emergency instead of yours.