DeepSeek has always a unusual advantage in the coding-agent market: the models are strong enough to be used for serious coding work, while the API is cheap enough that developers could let agents run without constantly thinking about token burn.
DeepSeek V4 pushed that further. The V4 family uses Mixture-of-Experts models with a native 1-million-token context window. V4 Flash has 284B total parameters with 13B activated per token. V4 Pro has 1.6T total parameters with 49B activated. The architecture combines Compressed Sparse Attention and Heavily Compressed Attention, keeps DeepSeekMoE and Multi-Token Prediction, adds Manifold-Constrained Hyper-Connections, and moves most model optimization to Muon. At 1M context, DeepSeek reports that V4 Flash uses about 10% of the single-token inference FLOPs and 7% of the KV-cache footprint of DeepSeek V3.2. V4 Pro uses about 27% of the FLOPs and 10% of the KV cache.
DeepSeek team pre-train both models on more than 32T diverse and high-quality tokens, followed by a comprehensive post-training pipeline. The post-training features a two-stage paradigm: independent cultivation of domain-specific experts (through SFT and RL with GRPO), followed by unified model consolidation via on-policy distillation, integrating distinct proficiencies across diverse domains into a single model.. DeepSeek-V4-Flash-0731 shipped on July 31, keeping the same architecture and size as the preview model while substantially improving its agent benchmarks. The official release reports 82.7 on Terminal Bench 2.1, 54.2 on NL2Repo, 54.4 on DeepSWE, and 70.3 on Toolathlon-Verified. DeepSeek also disclosed something unusually relevant to developers evaluating coding models: its code-agent benchmarks were run through the then-unreleased DeepSeek Harness in minimal mode, at max reasoning effort.
DeepSeek-V4-Pro-0813 followed on August 13. So the current new models are V4 Flash 0731 and V4 Pro 0813.
What happened next is more interesting than a normal model launch. DeepSeek announced to change its API pricing. Coding platforms publicly started looking for inference providers that could absorb enormous DeepSeek traffic at better rates. At almost the same time, DeepSeek open-sourced the harness it had been using around V4, and that repository went from zero to 100k of GitHub stars within 48 hours.
The model, harness, and inference-provider layer are now part of the same engineering story.
DeepSeek V4 Flash was built for unusually cheap long-running inference
Flash’s price only makes sense when you look at the architecture.
A 284B model sounds large, but only about 13B parameters are active for each token. DeepSeek keeps the sparse DeepSeekMoE design, while its hybrid attention stack attacks one of the expensive parts of long-running agents: attention over an increasingly large context. CSA compresses KV state along the sequence dimension and performs sparse attention; HCA compresses KV more aggressively while retaining dense attention over the compressed representation.
The model also uses FP4 routed expert parameters, and DeepSeek added FP4 quantization-aware training for MoE expert weights and the attention indexer’s QK path. Its infrastructure work includes fused MoE kernels designed to overlap communication, computation, and memory access, TileLang kernels, heterogeneous KV-cache storage, and shared-prefix reuse. DeepSeek trained Flash on 32T tokens and Pro on 33T tokens.
Those choices line up closely with the economics of an agent session.
A coding agent rarely sends one isolated prompt. It repeatedly carries system instructions, repository context, previous edits, tool results, errors, and reasoning state forward. Long context therefore creates two costs: the compute required to process the sequence and the memory required to keep its KV state alive. DeepSeek V4’s efficiency work targets both. At a 1M-token context, Flash’s reported 10% FLOP and 7% KV-cache ratios versus V3.2 are a much stronger infrastructure story than simply saying that the model “supports 1M context.”
V4 also changes how reasoning survives agent turns. DeepSeek’s technical report describes a new XML-based tool-call schema using a special DSML token and preserves reasoning content across tool-calling rounds instead of discarding it after each new user turn. The design is intended to keep a cumulative reasoning history available during long-horizon agent work.
The post-training stack is similarly agent-oriented. DeepSeek first trains separate domain experts for areas such as coding, agents, mathematics, and instruction following using SFT followed by GRPO reinforcement learning. Those capabilities are then consolidated through on-policy distillation. Flash 0731 kept the base architecture and received another post-training pass rather than a new model architecture.
That combination created a compelling volume model. Before this week’s price change, V4 Flash’s first-party API cost $0.14 per million cache-miss input tokens and $0.28 per million output tokens, with cache-hit input at $0.0028 per million. V4 Pro was $0.435 input and $0.87 output, with $0.003625 cache-hit input.
For an agent that can generate millions of tokens across many parallel users, those numbers are not a small feature. They can determine whether the product can offer a flat subscription at all.
DeepSeek’s August price reset changes the agent math
DeepSeek notified about pricing change due to high demand of new models.
The exact first-party notice says the new rates take effect at 16:00 UTC on August 16, 2026. DeepSeek notified that the new structure is intended to allocate resources more reasonably and encourage users to schedule work around demand.
The new rate card is no longer flat. Peak hours are 01:00 to 04:00 UTC and 06:00 to 10:00 UTC. Everything else is off-peak, and off-peak rates are exactly half of peak pricing.
Previous prices are from the pre-change rate card; current rates are from DeepSeek’s updated pricing documentation. The percentage change above is calculated from those two schedules.
Overall increase by roughly 50% to 1,100%, depending on the model, token type, and time of day. The largest relative increase hits V4 Pro cache hits.
There is a subtle consequence here for agent developers. Caching used to make repeated DeepSeek context almost absurdly cheap. The absolute new cache-hit prices are still low, but the discount relative to the old rate has narrowed substantially. A system that was economically designed around repeatedly replaying a large stable prefix should recalculate its real cost rather than assuming the previous cache economics still apply.
Output is the other pressure point. V4 Flash output moves from $0.28/M to $0.66/M off-peak and $1.32/M at peak. Pro moves from $0.87/M to $1.98/M and $3.96/M. Coding agents are output-heavy because edits, shell plans, tool calls, reviews, retries, and subagents can all generate tokens before the user sees the finished result.
DeepSeek has also set first-party concurrency limits of 2,500 for Flash and 500 for Pro. Both models retain 1M context, up to 384K maximum output, tool calls, JSON output, the Responses API, and Anthropic-compatible access.
The broader serving economics are obvious, though. A 284B or 1.6T MoE still requires a serious distributed inference stack even when active parameter count and long-context compute have been reduced. At coding-agent scale, utilization, KV-cache capacity, concurrency, quantization, prefix reuse, and scheduling determine how cheap a provider can actually serve the model. DeepSeek’s own technical report spends significant space on exactly those inference and memory optimizations.
With new DeepSeek pricing, OpenAI jumped as first position for bets price to model ratio.
The pricing change immediately exposed how much traffic coding platforms are already trying to push through these models and demand of good open models.
Coding platforms are openly shopping for DeepSeek inference capacity
One of the clearest demand signals came from 2 coding agent platforms.
Founter of Command Code mentioned about “12 trillion tokens load” and trying to find providers that could beat DeepSeek’s new peak/off-peak pricing.
OpenCode’s number is even more explicit. OpenCode CEO Jay posted on August 16 that providers claiming they could beat DeepSeek’s price could potentially partner with them and they have around 15 trillion tokens of traffic every day from OpenCode.
Put those posts next to the price table and the provider discussion stops looking theoretical.
At 15T tokens per day, tiny differences in per-million-token economics become meaningful. You cannot convert that traffic figure directly into a bill without knowing the input/output split, cache-hit ratio, model mix, reasoning effort, and actual accepted traffic. But every $0.01 per million tokens across 15T tokens represents $150,000 of gross token-priced volume before accounting for those distinctions.
That is why coding-agent companies are now talking to inference providers publicly.
The open-weight model ecosystem also makes the market different from a closed API. A third-party provider can serve DeepSeek weights on its own infrastructure and optimize the serving stack independently. Provider pricing therefore does not have to move in lockstep with DeepSeek’s official API.
I would benchmark at least:
served checkpoint, context limit, reasoning mode, quantization, output ceiling, cache behavior, concurrency, tokens per second, time to first token, tool-call compatibility, and sustained availability
The cheapest line on a pricing table can be expensive if the route truncates the context your agent expects, slows badly under concurrency, or behaves differently during tool use. And on elf th most important aspect will be data retention.
This is also why DeepSeek’s V4 release is shifting the enterprise question from model selection to model operations. A coding product at trillions of tokens of traffic cannot afford to couple its economics to one first-party endpoint.
DeepSeek Harness may be the bigger developer launch
DeepSeek released DeepSeek Harness v0.1 alongside the V4 Pro launch on August 13. It is MIT-licensed, currently marked as a developer preview, and compatibility-breaking changes should be expected.
It got over 75.7K stars and 6.5K forks in under 24 hours and hit 100k+ Stars around end of 48hrs.
OpenClaw has also been reported at approximately 100K stars in 48 hours around its January launch. Hermes-Agent took roughly seven weeks to cross 100K. DeepSeek Harness’s first two days were dramatically faster than Hermes’s climb and roughly in the same launch-velocity as OpenClaw.
GitHub stars are attention, not production usage, and agent repositories are especially prone to viral launch curves. Still, getting roughly 75K stars inside a day is enough to say developers were interested in more than V4 Pro itself.
I have also tried using it and customizing it for my usecase and added Nebius as default provider:
I will add more customization to it in coming days.
Reddit is also talking and customizing it and users are saying “the VS Code of agent harnesses”, reflecting the idea that developers can replace almost every subsystem rather than accepting one fixed agent architecture. Another DeepSeek thread praised the flexibility but asked whether DSH might be too flexible for daily coding, pointing to the cognitive overhead of Cordis, profiles, plugins, configuration, and dependency composition.
That criticism is fair. DeepSeek Harness is in preview and lot of features will improve over time.
Inside DeepSeek Harness: Cordis instead of a hardcoded agent loop
Its underlying runtime is Cordis, a plugin framework where models, tools, file access, persistence, sandboxes, session handling, the agent loop, and other capabilities are mounted into a shared context. DeepSeek’s architecture: there is no privileged core that extensions have to patch. Plugins contribute services, typed events, and reversible effects, and their registrations unwind when they are unloaded.
That design changes what “customizing an agent” means.
A conventional agent framework often gives you a fixed loop and extension points around it. In DSH, the loop itself is one of the replaceable components. The model adapter is replaceable. The tool registry is replaceable. Persistence and sandbox implementations are replaceable. A provider swap is expected to happen at a defined capability seam rather than through conditionals scattered across the codebase.
The default stack is composed through profiles and bundles. dsh-base supplies model adapters, tools, persistence, sandbox and approval policy, settings, credentials, and telemetry. A web profile adds the browser application, while the headless profile can run without a server. Configuration layers can replace or insert Cordis rows above the base composition.
The agent state model is equally deliberate.
DeepSeek Harness has an append-only SessionEvent log. Model-visible context is projected from that log. User messages, assistant messages, streamed assistant chunks, tool calls, tool results, steps, and turns can become durable events. Forking, resuming, transcripts, telemetry, persistence, and replay are all derived from the same event stream. The architecture even asserts that anything sent to the model must be reconstructable from the log.
That gives the harness a useful property for serious agent engineering: the history the model saw is not hidden inside an opaque mutable object. You have an event history that can support replay and debugging.
The default turn flow is also explicit. A step is one model request plus its tool calls. A turn can contain multiple steps. Before a request, DSH assembles prompt sections and tool schemas, projects model history from the session log, streams the LLM response, records tool calls, sends them through pre-execution, execution, and post-execution stages, records the results, and continues if another model step is owed. Those stages expose events that plugins can observe or intercept.
The capability-seam model is probably the part I would watch most closely. DeepSeek explicitly documents a path for registering another model provider on ctx.llm, replacing filesystem or shell backends, adding persistent terminals, inserting model-visible context, intercepting requests or tool calls, changing sandbox providers, and adding UI integrations without rewriting the agent loop.
This architecture also explains an unusual detail in the V4 launch. V4 Flash’s official code-agent results were already measured through DeepSeek Harness minimal mode. The harness is part of the evaluation environment for the model itself.
That creates a useful warning for anyone comparing agentic models. “Model performance” increasingly includes harness behavior. Tool schemas, history preservation, context injection, retry rules, reasoning effort, and the exact agent loop can move the result.
V4 itself is harness-sensitive by design. Its technical report preserves reasoning history across tool rounds and introduces a specific tool-call format. A harness that throws away that state or translates it incorrectly may not be measuring the model DeepSeek intended to serve.
In coming few weeks, we can expect more stable updates and custom harness built on top of it by community.
Where Nebius Token Factory fits
This is where I see a useful provider-layer experiment.
I am extending my DeepSeek Harness setup so that the model/provider layer can include the Nebius Token Factory catalog instead of treating DeepSeek’s first-party API as the only execution route. DSH’s architecture is well suited to that work because a model provider registers through the LLM capability seam rather than requiring changes to the rest of the turn loop.
For a coding-agent company, that abstraction becomes more useful after this week’s pricing change. The application should not care whether a particular V4 request is being served by DeepSeek directly or an independent provider, as long as the route satisfies the required model behavior, context, latency, tool-call semantics, and economics.
Nebius Token Factory already serves DeepSeek models and exposes inference through an OpenAI-compatible API. Its production offering has dedicated endpoints, autoscaling, speculative decoding, multi-region routing, sub-second latency targets, and 99.9% uptime. Token Factory can handle 100M+ tokens per minute with dedicated production capacity, and its current catalog includes lots of new Open models like DeepSeek, Kimi and others. DeepSeek-V4-Pro and V4 Flash has also gone live on the platform.
Nebius also supports post-training for DeepSeek V4 Flash, including managed supervised fine-tuning, which gives teams another path besides using the generic hosted checkpoint unchanged.
The more useful logic for me is capacity plus provider independence. I use Nebius models a lot, almost daily.
Command Code is publicly talking about 12T tokens of load. OpenCode’s founder is talking about approximately 15T tokens per day that could move to a provider with better economics. With Nebius inference infrastructure that is built for hundreds of millions of tokens per minute and offers dedicated endpoints with volume pricing, they could be able to handle large demands.
If you’re a builder or developer looking to test Nebius models before making a decision, you can directly sign up for the Nebius Builder Program and get up to $50 in FREE API usage.
The first phase of open models was about whether an open-weight model could get close enough to proprietary quality.
DeepSeek V4 exposes the next problem: what happens when the model is good and cheap enough that an agent product wants to burn trillions of tokens through it?
You need an agent harness that understands the model’s reasoning and tool semantics. You need replayable state and observable tool execution. You need model routing that is not dependent to one API. You need enough inference capacity to survive a demand spike. You need to understand cache economics. You need a provider strategy before the upstream rate card changes.
DeepSeek released all three pieces of that problem into the market in the just few weeks: V4 Flash and Pro as the model layer, DeepSeek Harness as the agent layer, and a new first-party price surge that suddenly makes the inference layer impossible to ignore.
The question is no longer only whether V4 is good enough to code.
It is whether your stack is designed to operate it at scale.
Sukriya🙏🏼 See You Again Next Week! Till Then Keep Learning and Sharing Knowledge with Your Network