dsh-baton hands long Claude Code tasks off to DeepSeek: $3.16 instead of $14.18

A familiar scene: it is Thursday, the weekly allowance for an agentic coding tool is nearly exhausted, and two more work sessions remain. The author of a post on X describes the situation with the irony of someone who experiences it regularly. The post then presents one possible way out: the dsh-baton utility.

What kind of tool is it?

The idea is simple. An expensive model such as Claude Code or Codex should not have to grind through every long task itself. It hands the task to the cheaper DeepSeek, which runs on your machine, and then only checks the result. It is similar to a senior engineer delegating routine implementation to a junior engineer and reviewing the work afterward.

This workflow fits the way usage limits are consumed. Most tokens are spent not on difficult decisions, but on long loops: write code, run tests, fix issues, and run everything again. Reviewing the result costs considerably less than performing that entire cycle.

What the numbers promise

The project's README provides an example involving a small kanban app. Building it entirely with Opus costs $14.18. With dsh-baton using DeepSeek as the executor, the bill came to $3.16. That is a saving of about 78%, or roughly 4.5 times cheaper. The full test suite passed in both cases: 55 of 55 tests.

The post's author immediately points out the catch: execution time increased from 39 to 93 minutes. That is 2.4 times longer. It is the classic trade-off between money and time, and it is perfectly reasonable for many tasks. If the agent works overnight or in the background, an extra hour is unlikely to bother anyone. If you are waiting for the result at your screen, the benefit shrinks considerably.

How to interpret these results

It is worth remembering that this is a single example from the project's own README, not an independent benchmark. A kanban app with 55 tests is a clear and relatively uncomplicated task. There is no data on how the workflow performs on a large codebase, with non-obvious dependencies or flaky tests. The post itself received zero views, so there has not yet been any community discussion or verification.

There are hidden risks as well. Green tests only tell you what the tests cover. If the reviewing model looks only at the final result, bugs not caught by the tests may slip through. Every delegation also carries overhead: transferring context, rerunning tasks, and dealing with potential executor errors.

What to do in practice

The most sensible step is not to switch entirely to this workflow, but to test it on your own tasks. Good candidates include:

• large but clearly specified tasks with strong test coverage;
• background runs where time is not critical, such as migrations, template-based refactoring, and test generation;
• projects where the expensive model's allowance regularly runs out early.

Compare three figures for the same task: cost, time, and the number of changes required after review. If the savings remain severalfold and few changes are needed, the workflow can be adopted more broadly. If execution time grows beyond what you are willing to tolerate, leave complex tasks to the expensive model and delegate only repetitive routine work to the cheaper one.

The broader picture reveals the main trend: the agentic coding market is moving away from using one model for everything and toward combinations in which an expensive model plans and reviews while a cheaper one executes. dsh-baton is an early and, for now, lightly validated example of this approach, but the underlying logic is clear and worth testing.