The most useful model news of the week is not a leaderboard victory. It is a routing event.
On July 30, OpenAI cut GPT-5.6 Luna to \$0.20 per million input tokens and \$1.20 per million output tokens, an 80% reduction. One day later, DeepSeek put the official DeepSeek-V4-Flash-0731 API into public beta. Those releases do not make every other model obsolete. They do make an old habit obsolete: treating the inexpensive tier as a polite compromise you use only when quality does not matter.
For a large share of production agent work, the relevant comparison is now DeepSeek V4 Flash 0731 versus GPT-5.6 Luna. They sit essentially adjacent on an independent intelligence aggregate, 50 and 51 respectively, while their list prices are low enough to change what can be automated at all. That is the headline. The important work is resisting the temptation to turn it into a simplistic one.
I do not care which lab wins a launch-day argument. I care whether an agent closes a ticket, lands a safe patch, resolves a support case, or produces a valid artifact within its budget and latency envelope. A benchmark score is evidence about that question. It is not the answer. Token price is also evidence. It is not the answer. The routing table should move only when cost per completed task moves.
That standard is more demanding than price-per-token comparison, and it is exactly why these two announcements matter together. DeepSeek offers startlingly cheap output and an unusually deep cached-input discount, with vendor-stated agent results that are strong enough to demand investigation. Luna gives teams an aggressively priced, well-specified API option at 51 on the independent Artificial Analysis Intelligence Index. Neither lets an engineering organization skip measurement. Both make it expensive to keep routing every ordinary job to a premium model out of inertia.
First, identify the release correctly
The model under discussion is DeepSeek-V4-Flash-0731, the official July 31 release, and the deepseek-v4-flash API is in public beta. This is not the April V4-Flash-Preview with a new coat of marketing paint. DeepSeek says the official release retains the preview model's architecture and size while upgrading the V4-Flash API and agent capability. The official announcement also says the release natively supports the Responses API and is adapted for Codex. Read the primary announcement, not an old preview thread: DeepSeek's July 31 change log.
That distinction matters operationally. Teams often pin an alias, run a brief evaluation, then spend months arguing from a stale mental model. Here the version name is concrete: DeepSeek's pricing table identifies the model version behind deepseek-v4-flash as DeepSeek-V4-Flash-0731. Pin the dated model where your provider contract allows it. Record the exact reasoning setting, tool schema, system prompt, retry behavior, and evaluation date. If you cannot reproduce your own comparison in six weeks, you did not evaluate a model. You observed a weather pattern.
The release discussion has also been muddled by the assumption that local deployment must wait. The public, ungated repository at the DeepSeek V4 Flash 0731 page now publishes the complete checkpoint as 48 safetensors shards in fp8, with 74 files total, under the MIT license, uploaded on 2026-08-01. Open weights make self-hosting a real option. But 284B total parameters with 13B active still means serious inference hardware, and a public checkpoint is not the same as a validated deployment. Benchmark the self-hosted path against the first-party API before committing hardware.
OpenAI's cut is not a cosmetic discount
OpenAI's July 30 revision is straightforward enough to state and consequential enough to deserve attention. GPT-5.6 Luna now costs \$0.20 input and \$1.20 output per million tokens. GPT-5.6 Terra falls 20% to \$2 input and \$12 output. GPT-5.6 Sol remains at its existing price. OpenAI also replaced Priority Processing for Sol with Fast mode, advertised at up to 2.5 times Standard speed and priced at twice the Standard rate. The full details are in OpenAI's price-performance announcement.
Luna is explicitly positioned for cost-sensitive, high-volume workloads. It has a 1,050,000-token context window, a 128,000-token maximum output, \$0.20 uncached input, \$0.02 cached input, and \$1.20 output per million tokens. Those are not trivia for an agent platform. Long repositories, retrieved runbooks, conversation histories, and repeated tool instructions all become economically plausible in a different way when your stable prefix hits cache. See the Luna model documentation.
But the footnotes are where real invoices live. Prompts over 272,000 input tokens are charged at two times the input rate and 1.5 times the output rate for the full request. Cache writes are billed at 1.25 times the uncached input rate. A team that says “Luna is \$0.20 input” while sending 400,000-token megapropts is not doing capacity planning. It is doing wishful arithmetic.
Sol's Fast mode deserves the same skepticism. Faster completion can improve a user-facing coding loop and increase worker utilization. It can also double your model price while doing nothing for the actual bottleneck, which may be test execution, a serial tool call, database contention, or a human approval queue. Buy faster inference when latency raises completion rate or increases valuable throughput. Do not buy it to improve a dashboard number.
The independent picture: near peers, not identical agents
Artificial Analysis puts DeepSeek V4 Flash 0731 at 50 on its Intelligence Index v4.1 and GPT-5.6 Luna at 51. That one-point gap is a useful corrective to vendor theater. It says the two models are near each other on this aggregate, not that they are interchangeable on every task. The index incorporates nine independent evaluations: GDPval-AA v2, tau3-Banking, Terminal-Bench v2.1, SciCode, Humanity's Last Exam, GPQA Diamond, CritPt, AA-Omniscience, and AA-LCR. Artificial Analysis labels these intelligence evaluations independently measured. Its DeepSeek page and Luna page are the comparison baseline I would start from.
The surrounding frontier makes the tradeoff clearer. Claude Opus 4.8 is 56, and Claude Opus 5 is 61, on the same index. Both are listed at \$5 input and \$25 output per million tokens, with \$0.50 cache-hit input. Gemini 3.6 Flash is 50, matching DeepSeek's index score, listed at \$1.50 input and \$7.50 output with \$0.15 cached input. Gemini 3.5 Flash-Lite is 36 at \$0.30 input and \$2.50 output with \$0.03 cached input. Terra is 55 at \$2 and \$12, while Sol is 59 at \$5 and \$30. Those pages are available for Opus 4.8, Opus 5, Gemini 3.6 Flash, Gemini 3.5 Flash-Lite, Terra, and Sol.
This does not mean a 61 model is bad value. A premium model can be spectacular value on a rare, high-stakes task where a weaker agent fails repeatedly, damages a branch, or consumes an engineer's afternoon. It means that paying premium rates for the median task now needs an explicit argument. “It feels safer” is not an argument. “It completes 14 percentage points more of our hard migrations and reduces median human intervention by 30 minutes” is an argument.
There is a speed dimension as well. Artificial Analysis reports 172.1 output tokens per second for Luna, 125.6 for Terra, and 63.5 for Sol. Gemini 3.6 Flash is listed at 219.6 tokens per second and Gemini 3.5 Flash-Lite at 360. Token rate matters for interactive loops, but again it is not the same thing as task rate. An agent that emits fast, unnecessary reasoning and retries a malformed tool call is fast in the least useful sense. Measure elapsed time to a valid merge, resolved case, or accepted workflow state.
DeepSeek's nine agent scores are a lead, not a verdict
DeepSeek's own published agent table is impressive. It reports 82.7 on Terminal Bench 2.1, 54.2 on NL2Repo, 76.7 on Cybergym, 54.4 on DeepSWE, 70.3 on Toolathlon verified, 25.2 on Agents' Last Exam, 25.1 on Automation Bench Public, 68.7 on DSBench-FullStack, and 59.6 on DSBench-Hard. The full list is in DeepSeek's release notes.
Each number points toward a distinct kind of agent ability. Terminal Bench 2.1 asks whether an agent can use a terminal to finish realistic command-line tasks, with all the ordinary hazards of state, tools, and environment manipulation. An 82.7 vendor score, if it generalizes, is a serious signal for coding and operations agents. DeepSWE is closer to software-engineering issue resolution, where the model must find the relevant code, reason about the change, edit, and validate. A 54.4 result is not a claim that half of all GitHub issues are now solved, but it is much more meaningful than a polished code-completion demo.
NL2Repo shifts toward repository-level work from natural-language requests. Its 54.2 score matters because production work is rarely a blank-file generation exercise. Toolathlon verified is about using tools successfully under verified evaluation, and its 70.3 score is relevant to agents that must navigate APIs rather than merely explain them. Cybergym adds security-oriented task environments and DeepSeek reports 76.7 there. That should interest security-automation teams, but it should not cause anyone to grant an unreviewed agent broad production permissions. A benchmark does not change your threat model.
Agents' Last Exam at 25.2 and Automation Bench Public at 25.1 are equally useful precisely because they are lower. They remind us that broad, long-horizon autonomy remains difficult. A model can look dominant on a bounded terminal environment and still struggle with ambiguous real-world automation. The two DSBench results, 68.7 for FullStack and 59.6 for Hard, are also not neutral public yardsticks: DeepSeek identifies both as internal. They may be valid internal evaluation work. They are not evidence you should use as though a third party independently reproduced them.
Here is the caveat that should appear in every serious discussion of this launch: all nine of those agent scores are vendor-stated, run on DeepSeek's own harness, and have not received third-party reproduction. Public code-agent tasks used DeepSeek Harness in minimal mode, at max effort, top_p=0.95, and temperature 1.0. The harness itself is not just plumbing. It determines tool formatting, shell behavior, timeout policy, context assembly, retry rules, test invocation, truncation, and whether a near-miss gets another turn. Change those choices and agent scores move.
Cosmic's analysis states this plainly: the figures are DeepSeek-reported and harness-sensitive, and independent evaluation is required. That warning does not invalidate DeepSeek's results. It tells us how to use them. Treat the table as a strong hypothesis generator. Do not treat it as your deployment acceptance test.
Artificial Analysis provides a more useful external anchor. It measures DeepSeek at 79% on Terminal-Bench 2.1 and reports a GDPval-AA v2 Elo of 1559, alongside the 50 Intelligence Index. The 79% figure is below DeepSeek's 82.7 on the vendor table, which is exactly the kind of divergence an adult evaluation process expects. Same named benchmark does not guarantee identical harness, prompting, model settings, or execution protocol. The fact that the independent number remains strong is encouraging. The fact that it is different is the lesson.
Output tokens are not an implementation detail
DeepSeek's published token rates are extraordinary: \$0.14 per million cache-miss input tokens, about \$0.0028 per million cache-hit input tokens, and \$0.28 per million output tokens. It supports a one-million-token context and up to 384,000 output tokens. On paper, that makes it hard to beat for large repeated contexts and tool-heavy workflows. The official details are in DeepSeek's pricing table.
The first operational trap is reading \$0.28 output and concluding the model is always cheap. Artificial Analysis records DeepSeek V4 Flash 0731 using about 210 million output tokens across its Intelligence Index evaluation suite, against a 62 million token median. Its launch analysis also cites roughly 206 million tokens, depending on the reporting cut. The exact difference between those two rounded totals is not the point. The point is that this model is unusually verbose under the evaluation configuration.
That verbosity can erase a large part of a headline token-price advantage. It can also harm latency, push an agent into timeouts, expand logs, and introduce more opportunities for a reasoning trace to wander away from the task. Cheap output should encourage careful controls, not a license to leave every agent at maximum effort forever.
Suppose two agents see the same 100,000 uncached input tokens. Luna's input portion is about \$0.02; DeepSeek's is about \$0.014. If Luna emits 10,000 output tokens, its output portion is about \$0.012. If DeepSeek emits 30,000, its output portion is about \$0.0084. DeepSeek still wins on direct token cost in that simple example, but the advantage is much smaller than an input-only comparison suggests. If the extra output creates one more tool turn or adds seconds to a customer-facing interaction, the cheapest raw model may not be cheapest in the workflow.
Now change the workload to a stable 100,000-token prefix that actually hits cache. Luna's cached input is about \$0.002. DeepSeek's is about \$0.00028. That roughly 98% DeepSeek cache discount is the real weapon for repeated repo context, policy packs, tool specifications, and static system instructions. Artificial Analysis attributes part of DeepSeek's roughly 60% lower cost per task versus Luna on the first-party API to this dynamic. It is a genuine advantage, but only for a cache hit. If your request template is constantly changing, your RAG ordering is nondeterministic, or every job carries a unique transcript, you are buying at the cache-miss rate.
Cache economics therefore belong in system design, not only vendor comparison sheets. Put stable instructions first. Keep schemas stable. Canonicalize retrieved context ordering where semantically safe. Separate reusable repository maps from task-specific diffs. Track cache-hit rate by route and tenant. If a provider's cache mechanics make an otherwise good prompt impossible to reuse, that is a product cost, not a minor API detail.
Capacity, ceilings, and the boring realities that win incidents
DeepSeek lists a concurrency limit of 2,500 for deepseek-v4-flash, compared with 500 for deepseek-v4-pro. A request counts from send until the complete response returns. Read that as a first-class capacity parameter, not marketing garnish: DeepSeek's rate-limit documentation is explicit.
A fivefold difference in concurrent requests matters when a fleet fans out over many small work items. It can reduce queueing, lower the need for tenant throttles, and make a cheap model much easier to operationalize at batch scale. It does not mean 2,500 is your safe application-level concurrency. Your own tool backends, sandboxes, databases, Git providers, and budget guardrails will usually impose lower practical limits. A model call that stays open while it streams a large answer holds one of those concurrent connections the entire time. Verbosity and concurrency are coupled.
This is another reason to care about completion rather than token economics alone. A model with cheap output but long average generations can consume more concurrency slots. A faster model at a higher rate can sometimes yield lower cost per completed task if it clears queues and prevents timeout-driven retries. You need a queueing and reliability view of the fleet, not merely a procurement table.
The same applies to context windows. One million tokens is attractive, but massive context is not automatically useful context. Long prompts can dilute retrieval, obscure authority boundaries, and induce the model to summarize instead of act. Luna's surcharge beyond 272,000 input tokens is a healthy forcing function: ask whether your agent really needs that transcript, or whether it needs a compact state representation and a search tool. DeepSeek's apparent lack of that particular price cliff does not remove the quality problem.
How I would route these models today
I would make both models defaults in a measured router, not crowns in a model beauty contest.
DeepSeek V4 Flash 0731 is the obvious candidate for high-volume, cache-friendly agent work where tool execution is bounded and a cheap fallback path exists. Think repository maintenance with stable instructions, repeated document extraction pipelines, deterministic internal automations, broad issue triage, and code changes whose test suite gives rapid feedback. Its 2,500 concurrency ceiling and cache-hit pricing make it particularly interesting for batch fleets. Start at a controlled effort level. Cap output. Enforce tool budgets. Log the reason an agent escalated.
GPT-5.6 Luna is the clean default for teams that value its API integration, need the 1.05 million-token context, want a clearly documented high-volume offering, or observe better completion on their actual tool protocol. At \$0.20 input and \$1.20 output, the old excuse that an OpenAI route is necessarily too expensive for routine work is gone. Its 51 independent index score makes it a serious primary route, not just a fallback after a premium model.
Terra, Sol, and the Claude models should remain escalation routes, not discarded inventory. Route tasks upward when the expected value of better reasoning exceeds the expected incremental spend. That could mean a migration touching payments, an ambiguous incident requiring careful diagnosis, a difficult cross-repository refactor, or a task where human intervention is expensive. Sol Fast mode belongs in genuinely latency-sensitive escalation paths after you demonstrate that inference, rather than tools, is the bottleneck. Opus 5's 61 index score is a reason to preserve access to it. It is not a reason to pay its \$5 and \$25 token rates for every classification job.
Gemini remains relevant, especially when its throughput characteristics and ecosystem fit win in practice. Gemini 3.6 Flash at an independent score of 50 is directly comparable in aggregate capability to DeepSeek 0731, but its listed \$1.50 input and \$7.50 output pricing demands a concrete reason for the premium. Gemini 3.5 Flash-Lite's 360 output tokens per second can be useful for shallow, latency-sensitive routes, but its 36 score says not to mistake speed for agency.
I would implement promotion and demotion as an experiment, not a committee preference. Define task classes. Randomly assign a meaningful slice to competing routes. Hold the tool environment, prompts, max turns, timeout, and human review policy as constant as possible. Record success, cost, wall time, tool errors, retry count, output tokens, cache status, and human cleanup time. Weight failures by business impact. Compare completed tasks, not isolated responses.
Then compute the metric that should decide the routing table:
cost per completed task = total model cost + tool cost + retry cost + expected human remediation cost
For a regulated or destructive workflow, add expected loss from an unsafe completion. For a customer-facing workflow, add latency penalties where they are real. A cheap agent that needs a human to repair one in five results is not cheap. A premium agent that reliably removes hours of review can be a bargain. The arithmetic will differ by route, which is precisely why one universal “best model” is mostly an excuse not to instrument your platform.
The new frontier is compelling because it gives production teams more room to run that experiment. DeepSeek V4 Flash 0731 offers prices and capacity that make broad testing affordable, but its strongest agent claims still need independent reproduction in your harness. GPT-5.6 Luna offers a dramatic price reset and a closely matched independent index score, but its long-context pricing and cache-write rules need to be included in the bill. The premium frontier remains real. It is simply no longer the automatic default.
That is the durable lesson from these two releases. Stop routing by brand, launch-day benchmark screenshots, or nominal cents per million tokens. Route by measured cost per completed task. Everything else is commentary.
Top comments (0)