DeepSeek V4 vs Kimi K3 for DevOps: Cost and Speed, Tested

Two Chinese labs now ship the open-weight models most people reach for when they want frontier-class output without paying OpenAI or Anthropic rates: DeepSeek and Moonshot’s Kimi. Both are on OpenRouter, both do tool calling and structured output, and both are the kind of model you would wire into a coding or ops agent to generate infrastructure code. So the practical question for anyone running that agent is narrow and money-shaped: for real DevOps work, do you point it at DeepSeek V4 vs Kimi K3, and does the bigger, pricier model actually earn its price?

On paper it looks lopsided. Kimi K3 is a 2.8-trillion-parameter model that bills at four to nearly eight times DeepSeek V4 Pro’s per-token rate (4.5x on input, 7.6x on output) and ships with maximum reasoning effort switched on by default. DeepSeek V4 Pro is smaller on the sticker, far cheaper, and MIT-licensed. To find out what that means on actual Terraform, Kubernetes, Ansible and CI work, we gave both models the same seven DevOps tasks and graded every answer the only way that counts: by running it. Everything below was measured in September 2026 against deepseek-v4-pro-0813 and kimi-k3 through OpenRouter, with the generated code executed on Ubuntu 26.04.

DeepSeek V4 Pro and Kimi K3, side by side

Both models landed within a month of each other in mid-2026 and both carry a roughly one-million-token context window. The differences that matter for agent work are price, how much they think, and whether you could ever run them yourself.

Kimi output tokens cost seven and a half times what DeepSeek’s do. That single number frames the whole comparison, because with reasoning models most of what you pay for is output tokens you never see.

How the test worked

Seven tasks, each a job a DevOps engineer would actually hand to an agent: a Terraform VPC module with public and private subnets and a NAT gateway; a full Kubernetes manifest set (Deployment, Service, Ingress with TLS, and an HPA); an idempotent Ansible playbook to install and harden nginx; a GitHub Actions pipeline with a build matrix and a gated deploy job; a multi-stage Dockerfile for a FastAPI service running as non-root; a broken nginx config to diagnose and fix; and an awk one-liner to parse node_exporter metrics. Each task ran three times per model at temperature zero, both at default reasoning and again pinned to reasoning_effort: low.

Nothing was graded by eye. Terraform went through tofu validate, the manifests through kubectl apply --dry-run=server against a live cluster, the playbook through ansible-playbook --syntax-check, the workflow through actionlint, the Dockerfile through a real docker build plus a health-check curl, and the nginx fix through nginx -t. The awk output was diffed against the known-correct answer. Kimi ran on Moonshot’s first-party endpoint; DeepSeek routed through StreamLake, whose price is identical to DeepSeek’s own ($0.66 and $1.98 per million tokens), so the billed cost tracks the published rates. The latency figures further down are for those two providers, which matters because how fast a model responds depends partly on who is serving it.

Which model wrote working DevOps code

At default reasoning, it is a tie. Both models went seven for seven. Every Terraform module validated, every manifest passed server-side validation including the HPA and the TLS Ingress, both Dockerfiles built to a 66 MB non-root image that served /healthz, and both correctly found and fixed both bugs in the broken nginx config. Neither model produced anything that failed to run.

The interesting differences are in taste, not correctness. On the Ansible task DeepSeek used the fully-qualified module name community.general.ufw and installed the ufw package before configuring it. Kimi wrote a tighter playbook with a loop over the two ports but called the bare ufw module and never installed the package, so its play assumes ufw is already present. On Ubuntu it usually is, which is why both pass, but DeepSeek’s is the more portable playbook. That pattern held across tasks: DeepSeek runs verbose and explicit, Kimi runs lean. Kimi’s Terraform used named locals for the subnet CIDRs where DeepSeek reached for cidrsubnet(); Kimi’s awk packed the whole parse into a helper function on one line where DeepSeek spread it across a readable block. Both compile. Pick your house style.

What each task actually cost

Kimi K3 cost almost exactly twice as much as DeepSeek V4 Pro across the seven tasks: $0.165 against $0.082 for one pass of the suite. The gap is not uniform. It runs from 1.3x on the Dockerfile up to nearly 5x on the Kubernetes manifests, where DeepSeek happened to think very little and its cheap per-token rate did the rest.

None of these are large numbers in absolute terms. A whole run of the suite on the pricier model is a sixth of a dollar. But agents do not run a task once. A coding agent that regenerates a manifest twenty times in a debugging loop, or a CI job that calls the model on every push, multiplies that gap straight into the monthly bill. At the volumes real automation hits, two-to-one is the difference between a rounding error and a line item.

Where the cost and the wait come from

Here is the part that inverts the sticker price. DeepSeek is the cheaper-per-token model, yet it emits far more tokens. On the Ansible task it generated 9,788 tokens of hidden reasoning to Kimi’s 2,109; on the Dockerfile, 10,576 to 1,579. DeepSeek V4 Pro thinks hard by default, two to seven times as much as Kimi does, and it is still cheaper overall only because Kimi’s output price is so much higher that even Kimi’s shorter answers cost more.

All that thinking has a second cost that never shows up on the invoice: time. Those long reasoning traces made DeepSeek the slower model on six of the seven tasks, badly so on the big ones. The lone exception was the small Kubernetes task, where DeepSeek happened to think little and edged ahead. The Ansible playbook took DeepSeek 164 seconds on average against Kimi’s 79; the Dockerfile, 152 against 56. If a human is sitting in front of an agent waiting for a manifest, Kimi feels roughly twice as responsive. So the real out-of-the-box trade is not simply “cheap versus expensive.” It is DeepSeek cheaper but slow, Kimi faster but pricey, at the same quality.

Cutting the bill with reasoning_effort=low

Both models take a reasoning_effort parameter, and turning it down is the single biggest lever on both cost and latency. Set it to low on the request:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek/deepseek-v4-pro-0813",
    "messages": [{"role": "user", "content": "..."}],
    "reasoning": {"effort": "low"}
  }'

At low effort the whole suite dropped from $0.082 to $0.028 on DeepSeek (a 67% cut) and from $0.165 to $0.043 on Kimi (a 74% cut), and both got much faster. Kimi’s thinking nearly switched off entirely, falling to single-digit reasoning tokens on several tasks. On the observability task the economics even flipped: at low effort Kimi came in cheaper than DeepSeek, because DeepSeek keeps thinking a few thousand tokens even when told not to.

The catch is that low effort is not free. At default effort every run passed. At low effort, correctness started to slip on both models, and the failures were exactly the kind that a syntax check would miss but a real run catches.

Error: “unknown field spec.template.spec.securityContext.allowPrivilegeEscalation”

One of DeepSeek’s low-effort Kubernetes manifests put allowPrivilegeEscalation and readOnlyRootFilesystem under the pod-level securityContext. Those are container-level fields only, so the API server rejects the whole manifest:

Error from server (BadRequest): error when creating "k8s.yaml": Deployment in version "v1"
cannot be handled as a Deployment: strict decoding error: unknown field
"spec.template.spec.securityContext.allowPrivilegeEscalation", unknown field
"spec.template.spec.securityContext.readOnlyRootFilesystem"

At default effort DeepSeek placed both fields correctly, on the container. The extra reasoning was doing real work: it was getting the securityContext split right.

Error: “useradd: group ‘65532’ does not exist”

One of DeepSeek’s low-effort Dockerfiles tried to create the non-root user without creating its group first, so docker build dies partway through:

useradd --uid 65532 --gid 65532 --no-create-home --shell /usr/sbin/nologin appuser
# useradd: group '65532' does not exist

Kimi’s low-effort runs slipped in their own ways. Two of its Dockerfiles set the entrypoint to uvicorn app.main:app while copying the app so the module was really main, so the container crashed on boot with ModuleNotFoundError: No module named 'app'. One of its awk answers compared the first field to the bare metric name, forgetting that the field still carries the {label...} block, so it printed nothing. Every one of these passed a human read and failed the machine. The lesson is blunt: reasoning_effort: low is the right default for drafts a person will review, and the wrong default for anything an agent will apply unattended.

Could you run either one yourself?

This is where the two labs genuinely diverge, and it matters if your reason for looking at open weights was self-hosting in the first place. Neither flagship is a casual local run: Kimi K3 at 2.8T parameters needs around 610 GB of combined RAM and VRAM and generates at about a tenth of a token per second on four A100s, which is to say it is not practically runnable outside a serious GPU cluster. We measured that first-hand in the Kimi K3 local run.

DeepSeek gives you an exit that Kimi does not. You would not self-host V4 Pro either, but DeepSeek also ships V4 Flash, a 284B model with 13B active that runs on a single 128 GB box at roughly 6 tokens per second, as covered in running DeepSeek V4 Flash locally. So if the plan is to keep data on your own hardware, DeepSeek offers a real hostable rung on the same family’s ladder and Kimi does not. For serving either one properly, the throughput difference between engines is large enough to matter, which is the point of the SGLang versus vLLM comparison.

Which one to point your agent at

The quality question turned out to be settled: on tested DevOps work these two models are interchangeable, so the decision is entirely about cost, speed, and where the model runs. If your agent runs in a batch pipeline where nobody is watching the clock, DeepSeek V4 Pro is the obvious pick: half the cost, and the extra latency is free when no human is waiting. If a person is in the loop, generating manifests interactively or iterating in an editor, Kimi K3’s speed is worth its premium, and pinning DeepSeek to reasoning_effort: low to close the speed gap reopens the correctness risk you just saw. If you need to keep the workload on your own hardware, DeepSeek wins by default, because its family has a model you can actually run. And whichever you choose, keep reasoning at default effort for any code that ships without a human reading it first. The cheapest token is the one attached to a manifest that actually applies. For how these two stack up against the closed frontier on the same kind of tested workload, the Kimi K3 versus GPT-6 Astra and GPT-6 Astra versus Claude Opus 5 runs use the same execution-graded method.