DeepSeek V4 Flash + GPT-5.6 Luna: A $0.42 Sol Alternative?

DeepSeek V4 Flash at max and GPT-5.6 Luna at xhigh have a theoretical combined coverage of 78 out of 112 repository tasks. GPT-5.6 Sol at xhigh covers 77.

The two-model pair costs about $0.42 per task in token-price-equivalent compute. Sol xhigh costs $6.53.

The comparison is theoretical, not a demonstrated replacement. The 78-task result assumes a perfect verifier that can always recognize the correct patch, and the DeepSeek sample is still thin.

The comparison matters because of the failure overlap: when tests can identify failure, model diversity may matter more than model strength.

The numbers behind the claim

I used the public data behind Distributed Radar, a community-run benchmark of coding agents on real repositories. The snapshot was captured on August 2, 2026. Its task-table baseline was generated at 07:15 UTC.

The dataset contains 112 tasks. For ability, I used each model-and-effort cell’s majority result from the public leaderboard. For cost and time, I used the latest valid run from the public task table.

Here are the three relevant configurations:

The dollar figures are calculated from token usage and standard API prices. They are not necessarily what a Codex subscriber sees on a bill or usage meter. Hardware, provider behavior, caching, and run conditions also vary.

The 78-task coverage uses all 112 task cells. The $0.42 pair cost is a separate average across the 110 tasks where both models had complete latest-run cost and duration data. If both ran in parallel, the average slower-of-the-two completion time was 26.8 minutes, close to Sol xhigh’s 25.3 minutes.

Compare task overlap with total scores

DeepSeek Max ranks below Sol xhigh. Luna xhigh ranks below Sol xhigh. Adding their scores would be meaningless because they may solve the same tasks.

The task-level overlap is what matters:

The union is therefore:

35 + 21 + 22 = 78 tasks

The individual scores are modest, but the models solve different subsets of the tasks. DeepSeek contributes 21 successes that Luna misses. Luna contributes 22 that DeepSeek misses.

A leaderboard hides this because it ranks total passes. A router needs to know whether two models fail on the same tasks.

The union depends on a verifier

Suppose both agents return patches for one task. The 78-task union assumes that whenever either patch is correct, the system selects it.

Selecting the better patch is easy when the repository has a strong oracle:

• deterministic tests,
• a compiler or type checker,
• a linter with a fixed rule set,
• an exact data-transformation output,
• a reproducible benchmark,
• a narrow acceptance script written before implementation.

It is much harder when success depends on architectural taste, an unstated product requirement, visual quality, security judgment, or a reviewer noticing a subtle regression.

Without a reliable verifier, two answers do not create 78 successes. They create two answers and a new decision problem.

That is why I would not replace Sol with a blind ensemble. I would let Sol define the task and its acceptance criteria first. The cheap workers only become valuable after the parent has made success mechanically recognizable.

A sequential router

Running both workers on every task is the simplest comparison, but not the cheapest policy.

A sequential router could try DeepSeek first, then call Luna only when the verifier rejects the result:

Sol defines the task and tests
          ↓
DeepSeek V4 Flash max
          ↓
tests pass? ── yes ──→ Sol reviews
     │
     no
     ↓
GPT-5.6 Luna xhigh
          ↓
tests pass? ── yes ──→ Sol reviews
     │
     no
     ↓
GPT-5.6 Sol xhigh

DeepSeek failed 56 of the 112 task majorities. If Luna ran only on those failures, the modeled worker cost would average about $0.26 per task. The modeled sequential runtime would rise to roughly 34.4 minutes, because every fallback waits for the first attempt to finish.

The 34.4-minute estimate is calculated task by task, so it does not exactly equal a formula built from the rounded table averages. These are estimates, not observed agent-workflow results. They use model-level majority outcomes to simulate routing and exclude Sol’s planning and review usage. A real router also runs one worker attempt rather than a task-cell majority, so its single-run union could be lower or higher than 78.

The choice depends on what matters most:

• run both in parallel when latency matters,
• run DeepSeek first when cost matters,
• skip the cheap tier when failure is difficult to detect.

Why Luna xhigh, not Luna Max?

My earlier Luna worker setup used Luna Max. For a single worker, that is defensible: Luna Max passed 59 tasks in this snapshot, two more than Luna xhigh.

For the pair, the ranking changes.

DeepSeek Max plus Luna Max covered 77 tasks for about $0.57. DeepSeek Max plus Luna xhigh covered 78 for about $0.42. Luna Max solved more tasks alone, but its two extra aggregate passes overlapped less usefully with DeepSeek’s failure pattern.

I selected the xhigh pair after seeing this snapshot. Its one-task advantage may therefore be overfit to these results and could reverse as more DeepSeek runs arrive.

Effort is not a universal quality preset. The strongest individual setting is not automatically the best ensemble member. I found the same non-monotonic behavior in the full GPT-5.6 Sol effort curve.

Three reasons the result may shrink

1. DeepSeek has much less repetition

Every Luna xhigh task currently has three runs contributing to its majority result. DeepSeek Max has one run on 86 tasks and two runs on 26.

That makes DeepSeek’s 56-task score much easier to move. More submissions could erase some of its 21 unique wins, add new ones, or do both. This article is a dated snapshot, not a permanent model card.

2. The benchmark is mostly feature work

Of the 112 tasks, 105 are classified as feature requests. Only four are bug fixes and three are enhancements.

This says something about repository-level feature implementation. It does not establish the same coverage for security reviews, architecture, tiny bug fixes, greenfield applications, or ordinary chat.

3. DeepSeek is not a drop-in Codex worker

Radar marks the DeepSeek combinations as manual_only API runs. That matters operationally.

As of August 2026, Codex can define custom model providers, but its documented provider wire protocol is the Responses API. DeepSeek’s current documentation exposes OpenAI Chat Completions and an Anthropic-compatible interface.

Based on those two documents, a direct DeepSeek custom agent is not currently a documented plug-and-play path in Codex. Reproducing this router may require a compatible gateway that translates the protocol, or a separate harness that runs DeepSeek and returns the result to the parent workflow.

It also means code and prompts leave the OpenAI model path and go to another provider. Any real deployment needs to review that provider’s current data handling, organizational policy, authentication, and failure behavior before sending a private repository.

What an end-to-end test would measure

The next benchmark should test end-to-end routing, not add another 112-cell leaderboard row.

For each task:

1. Give Sol the requirement and ask it to write acceptance criteria without implementing the change.
2. Send the bounded task to DeepSeek Max.
3. Run the predeclared verifier.
4. If it fails, send the same contract and failure evidence to Luna xhigh.
5. Let Sol review the accepted patch without seeing which worker produced it.
6. Record final pass rate, total tokens, elapsed time, number of fallbacks, and review rejections.

That experiment would measure the workflow itself, including orchestration overhead, imperfect tests, shared repository state, and Sol’s review cost. It would also reveal whether the cheap models’ apparent diversity survives when both receive the same parent-written contract.

What this snapshot supports

The headline numbers are easy to remember: 78 tasks, $0.42, and almost the same runtime as Sol xhigh.

The narrower interpretation is more useful. DeepSeek V4 Flash Max and GPT-5.6 Luna xhigh show complementary majority successes in this snapshot. If tests can reliably recognize a correct result, that diversity creates a plausible low-cost routing strategy.

The pair has not replaced Sol. It clarifies Sol’s role: define success, spend cheap attempts where failure is observable, and reserve frontier reasoning for decisions that tests cannot make.