Rightsizing My Agent Spend: From Opus to DeepSeek V4 Flash 0731

I wrote about the agent fleet that runs my business: eleven single-purpose bots, one repo each, all driven from Slack. What I skipped in that post is that I'd quietly stopped using most of them.

The reason was money. Every bot ran Claude Opus 4.8, and running them the way I actually wanted to, with long tool-heavy turns, several bots a day, and a critique loop that reads a whole draft twice, was costing me over $150 a week in Anthropic credits. That is a real number for a solo business, and it was buying me convenience rather than revenue. So I turned them off and went back to doing the work by hand, which defeats the entire point of having built them.

This post is what it took to turn them back on: moving the whole fleet to DeepSeek V4 Flash 0731 through the Vercel AI Gateway. The model swap itself was one line per bot. Everything around it was the actual work, and the parts that surprised me were not the parts I expected.

What the model swap actually costs

Here is the gap, per million tokens, straight off the gateway's model catalog:

38x cheaper on input. 96x on output. Against $150 a week, that puts the fleet in single-digit dollars.

The number alone would not have convinced me. What did is that V4 Flash 0731 carries the three properties an agent loop actually needs, and the catalog is explicit about all of them: tool use, reasoning, and implicit caching, with a 1M context window. A cheap model that can't call tools reliably is worth nothing in a fleet where every bot is mostly a tool-calling loop over a Slack message.

I started the migration on V4 Pro and moved the whole fleet to Flash after testing. Pro is still roughly 11x cheaper than Opus on input and 29x on output, so it's the fallback if a specific bot turns out to need more headroom. Setting the model is a string, so that's a one-line change per bot rather than a migration:

export default defineAgent({
  model: "deepseek/deepseek-v4-flash-0731",
  compaction: { thresholdPercent: 0.85 },
});

That string routes through the Vercel AI Gateway, which is the part that makes this cheap to try. The gateway fronts 312 models behind one credential and one interface, so switching vendors is a config edit instead of a new SDK, a new key, and a new billing relationship. Five of my bots had been calling the Anthropic SDK directly with their own ANTHROPIC_API_KEY; moving them onto gateway strings deleted a provider dependency from each one.

The same model runs on my desk, too

Here is the part that still surprises me: the same DeepSeek V4 Flash 0731 that costs pennies through the gateway also runs on my desk. I have an M5 Max with 128 GB of unified memory, and an 80.76 GiB quantization of V4 Flash 0731 fills most of it. No network cord, no API meter, just a model and a machine.

I did not trust that to work, so I benchmarked it. Sixty isolated coding runs across local DeepSeek, hosted DeepSeek through the gateway, and Claude Sonnet 5, twelve real repository tasks, hidden scorers, exact billing. The result: no statistical quality winner between local and hosted DeepSeek. Strict acceptance was 8/20 local versus 9/20 hosted; held-out checks were 12/20 versus 13/20. The paired comparisons could not separate them. The operational gap was far wider than the quality gap. Local had a 20-minute median agent time versus 8.7 minutes hosted, but the patches themselves were indistinguishable.

DeepSeek V4 Flash 0731 is terrific whether you are running it fully locally or through an API. The hosted route is faster and costs pennies. The local route is free, private, and works offline. Same model, same quality, two completely different deployment stories. For the fleet I use the gateway because I need the bots to answer in Slack while I sleep. For coding work on my own repositories I run it locally, because the machine is already there and the latency is my problem, not a bill.

The model was the easy part

I expected the migration to be eleven one-line changes. Then the first deploy failed:

Unsupported Eve version detected (eve@0.11.10).
Please update to version 0.18.0 or later.

Vercel had raised the minimum eve version for hosted deploys. My bots were pinned to 0.11.6. None of them could deploy at all, model config or not, and that explained something I'd been misreading for weeks. I thought the fleet had gone quiet because I'd stopped using it over cost. Some of that silence was a platform floor I hadn't noticed, quietly failing every deploy.

Current eve was 0.29.4. Eighteen minor versions in one jump, on eleven production bots, is the kind of thing that eats a weekend.

So I read all eighty releases between the two versions and checked every candidate breaking change against my actual code instead of guessing. Three things touched me:

• needsApproval → approval (eve 0.14.0). 21 call sites across 9 bots. A pure rename: the new ApprovalContext still carries toolInput, and ApprovalStatus still accepts raw booleans.
• ExperimentalWorkflow → experimental_workflow() (0.17.0). The marker re-export became a factory. One file, in the orchestrator.
• Sandbox runtime key removed. eve now always boots its own published image, which is mutually exclusive with requesting a stock runtime. One file.

That's it. Eighteen minor versions, three real edits, and the largest one was a find-and-replace. The things I'd braced for turned out to be non-events: the always/never/once approval helpers survived unchanged, defineTool({auth}) was removed but I'd never used it, and 0.28.0's breaking stream-event change was client-side only.

The lesson I'd carry into the next big version jump: read the changelog, then grep your own code for every candidate before you believe any of it applies to you. I flagged several scary-looking entries that turned out to be irrelevant, and the one that actually broke my build wasn't prominent in the release notes at all. It surfaced from a typecheck, not from reading.

Moving teams broke things that had nothing to do with models

I also consolidated every bot into one Vercel team so they'd share a gateway balance. That transfer broke three separate things, none of which announce themselves:

Slack died silently. My bots authenticate to Slack through Vercel Connect, and connectors are team-scoped. Moving a project to a new team leaves its connector behind. The app still deploys, still returns 200 on its health endpoint, and receives zero inbound events. Nothing errors; messages just vanish. The diagnostic that found it was runtime logs showing no inbound POSTs at all, which pointed upstream of the app entirely.

Sandbox templates orphaned. One bot had been deployed pre-transfer, and the sandbox template from that build stayed pinned to the project. Every later build failed on A sandbox with the name '...' already exists for this project. The template wasn't visible through the sandboxes API in either team, so it couldn't be deleted. eve derives the template key from the sandbox definition, so authoring one with a fresh revalidationKey sidesteps it.

Git links went stale by owner ID. One repo had moved GitHub orgs months earlier. Vercel stored the old repoOwnerId, so push events stopped matching and that project silently stopped auto-deploying for over a month before I noticed.

The through-line: platform-level moves break the plumbing between services, and plumbing failures are quiet. A health check returning 200 tells you the app is up. It tells you nothing about whether anything can reach it.

What I gave up

One honest cost, and it is not model quality.

My blog bot runs two cold readers over every draft, and they were deliberately from different vendors, one Claude, one GPT, so the critique wasn't a model grading its own output. Consolidating onto DeepSeek collapsed that to one family: V4 Pro reading and V4 Flash critiquing. Two models from one lineage will agree more often than two vendors did. I kept the second reader behind an environment variable so I can point it at another vendor if the gate starts rubber-stamping, but right now I've traded some independence for cost and I know it.

The model quality is not the worry. I benchmarked V4 Flash 0731 against Claude Sonnet 5 across sixty isolated coding runs with hidden scorers and it held its own, with no statistical quality winner in any paired comparison. What I can't speak to yet is behavior at high volume over months, across edge cases I have not hit. The per-token math is certain. The quality under sustained load is a claim I'll make after I have the data, not before.

Where it landed

Eleven bots on deepseek/deepseek-v4-flash-0731 through the gateway, on current eve, deploying from CI, answering in Slack.

The Anthropic side went from over $150 a week to what should be a few dollars, by swapping one string in eleven files. That did not require me to write anything clever.

What made the fleet worth running again was a model that turned out to be genuinely good. Not just cheap, but capable enough that I benchmarked it against Claude Sonnet 5 and could not tell the difference. That it also runs locally on my desk, for free, with the same quality, is the part I keep coming back to. The unglamorous work, paying down a platform version I'd let drift and fixing the plumbing a team transfer broke, was everything holding it up. But the foundation is a model that earns its place in both modes. DeepSeek V4 Flash 0731 is terrific whether you run it through an API or on your own hardware, and I did not expect to be able to say that.