Ten Claude Developers, a €350K Bill, and the Kimi K3 Cluster It Takes

Ten developers on Claude Team Premium looks like an €864 monthly bill.

It is not.

That is the seat bill. Once developers reach their included limits, usage credits take over and the same session continues at API rates. For a team running agents all day, the token bill is the bill.

Let us use a deliberately heavy but clean example: 10 developers, each processing five billion input tokens and producing 500 million output tokens a month. Eighty percent of the work runs on Fable and 20% on Opus 5.

Then ask whether the biggest GPU server UpCloud sells today, eight NVIDIA B200s in one machine, can replace it with Kimi K3.

It cannot. But a cluster can.

The €864 subscription becomes €350,000

Team Premium lists at €86.37 per developer per month when billed annually, or €107.96 month to month after conversion. Ten seats therefore cost €864 or €1,080.

Every seat includes Claude Code and a higher usage allowance. It is still capped. When an owner enables usage credits, work beyond the allowance is charged at standard API rates.

Claude Code manages prompt caching automatically. Inside the subscription allowance, the main conversation defaults to a one-hour cache. Once usage credits take over, it drops to the cheaper five-minute cache. That is the rate that matters in this comparison.

All Claude prices in this article are converted to euros using the ECB reference rate for 2 September 2026. The real card or invoice conversion will move.

The converted model prices, including prompt caching, are straightforward:

• Fable 5.1: €8.64 per million fresh input tokens, €10.80 for a five-minute cache write, €0.22 for a cache read and €43.19 for output.

• Opus 5: €4.32 per million fresh input tokens, €5.40 for a five-minute cache write, €0.43 for a cache read and €21.59 for output.

Five billion input tokens here means five billion logical tokens processed, including cache reads. I assume a 70% cache-read rate and 30% cache writes. That is the same 70% assumption used for Kimi K3 later in the comparison.

Apply the 80/20 model split and the 70/30 cache split to one developer:

Model	Logical input	Cache reads	Cache writes	Input cost	Output cost	Total
Fable, 80%	4B	2.8B	1.2B	€13,560	€17,274	€30,834
Opus 5, 20%	1B	700M	300M	€1,922	€2,159	€4,081
One developer	5B	3.5B	1.5B	€15,482	€19,433	€34,915

Now multiply by 10:

Monthly team usage	Fable	Opus 5	Total
50B logical input tokens, 70% cache reads	€135,602	€19,217	€154,819
5B output tokens	€172,741	€21,593	€194,334
Token bill	€308,343	€40,810	€349,153

Add the seats and the planning number is €350,017 a month, or about €4.20 million a year. Month-to-month seats make it €350,233.

The actual invoice will be slightly lower because Team Premium includes some usage before pay-as-you-go starts. Anthropic does not publish that allowance as a fixed token quantity, so there is no honest exact deduction. At this volume it does not change the decision.

Cache performance moves this number. With caching disabled, the same workload costs €583,866 a month. At Anthropic’s reported 84% median cache-read rate for agent loops, it costs about €283,814. I use 70% because this is a plan, not a measurement. Replace it with the team’s cache_read_input_tokens before putting the number into a budget.

Translate the workload into throughput

Five billion output tokens over a 30-day month is an average of 1,929 output tokens a second.

Each developer needs about 193 output tokens a second on average. That sounds unreasonable for one chat. It makes sense when each developer has ten agents working across repositories, tests and tools. Each agent only needs to average about 19 tokens a second.

The team therefore looks like this:

Requirement	Team load
Developers	10
Agents per developer	10
Simultaneous agent streams	100
Average output throughput	1,929 tok/s
Peak if generation happens in half the month	3,858 tok/s
Average input throughput	19,290 tok/s

This is no longer a chatbot deployment. It is shared inference infrastructure.

One 8xB200 server cannot run Kimi K3

Kimi K3 is built for the comparison we actually care about: complex coding, long-running agents and long context. It is a 2.8-trillion-parameter mixture-of-experts model with 104 billion active parameters and a one-million-token context window.

That quality comes with a very different hardware shape. The vLLM Kimi K3 recipe estimates about 1.68 TB of VRAM for the MXFP4 checkpoint.

UpCloud’s largest public GPU server has eight B200s, 96 CPU cores, 1.92 TB of system memory and 1.536 TB of GPU memory. At €4.50 per B200-hour, it is approximately €25,920 for a 30-day month.

The checkpoint is larger than the combined GPU memory before we reserve a byte for KV cache. It does not fit.

The validated Blackwell layout uses 16 GPUs: tensor parallelism across eight GPUs inside each node, then pipeline parallelism across two nodes. NVIDIA’s own Dynamo deployment starts with 16 GB200 GPUs for aggregated serving and 32 for disaggregated prefill and decode.

So the unit is not one B200 and it is not one eight-GPU server. One Kimi K3 replica starts at 16 B200-class GPUs with a fast link between the two nodes.

UpCloud’s public B200 servers provide NVLink inside the server. Kimi K3 needs fast communication across servers too. The relevant UpCloud product is its dedicated GPU cluster: B200 or B300, InfiniBand, and configurations from eight to 64 nodes. UpCloud lists delivery from December 2026.

Make the assumption explicit

There is no published Kimi K3 throughput result for plain B200s. We need a capacity assumption before we can compare prices.

For this plan I assume:

• One Kimi K3 replica uses 16 B200s across two eight-GPU nodes.

• Each replica carries 100 active coding agents.

• Each agent receives 20 output tokens a second.

• Each replica therefore delivers 2,000 aggregate output tokens a second.

• Active context averages 64K tokens, and repeated system prompts and repository context produce at least a 70% prefix-cache hit rate.

This is a planning target, not a benchmark. It is deliberately simple enough to disprove with a trace replay before signing a hardware commitment.

Our team needs 100 active agents and 1,929 output tokens a second on average. One replica meets both numbers:

Kimi K3 deployment	GPUs	Capacity assumption	What it covers
1 replica	16 B200	100 agents, 2,000 tok/s	Monthly average
2 replicas	32 B200	200 agents, 4,000 tok/s	Half-month peak, or N+1 at average load

One replica leaves almost no throughput margin: 2,000 available against 1,929 required. That is acceptable only with Claude API overflow. Two replicas are the production shape if the workload really lands in half the month or the team cannot tolerate the inference service being unavailable.

The 50 billion monthly input tokens are the larger uncertainty. Kimi K3 fits only after spreading its weights across the cluster, and long contexts consume the memory left for KV cache. The 70% cache assumption is doing real work here. If the trace produces 30%, add prefill capacity or expect queues.

What the Kimi K3 cluster costs

UpCloud advertises dedicated B200 capacity from €3.99 per GPU-hour with a 36-month commitment and partial prepayment. Assuming eight B200s per node and a 30-day month:

Deployment	Nodes	GPUs	Starting monthly GPU cost
Average plus Claude overflow	2	16	€45,965
Peak capacity, or average-load redundancy	4	32	€91,930

Those are starting GPU figures, not quotes. Storage, control-plane capacity, support and the final dedicated-cluster agreement sit on top. B300 nodes may fit Kimi K3 more cleanly because eight cards provide enough aggregate memory for one replica, but UpCloud does not publish B300 pricing yet.

The comparison that matters

Option	Monthly cost	What it buys
10 Team Premium seats only	€864	Included allowances, then work pauses at the limits
Team Premium plus pay-as-you-go	About €350,017	Fable and Opus 5 with 70% cache reads
16 B200 Kimi K3 cluster	From €46,829	Average capacity with Claude overflow
32 B200 Kimi K3 cluster	From €92,794	Peak capacity, or N+1 at average load

Kimi K3 is a credible model for complex coding, but this still is not an equality sign. Cost per token is useless if the local model cannot complete the task.

The sensible architecture is hybrid. Keep Team Premium because developers still need Claude Code and the frontier models. Put the repetitive, high-volume work behind the B200 endpoint. Keep the difficult tail on Claude.

If an eval shows Kimi K3 can carry the 80% path while the existing 20% remains on Opus 5, the rough average-month bill becomes:

• €864 for Team Premium.

• From €45,965 for the 16-B200 Kimi K3 cluster.

• €40,810 for the remaining cached Opus input and output.

• €87,639 total, before storage and operations.

That is about €262,000 less than the cached all-Claude calculation. Both figures use the same stated exchange rate and the same 70% cache-read assumption, so update both when you put this into a real budget.

Take 100 completed tasks from the team. Run them through the local model. Measure accepted patches, retries and human corrections. The percentage it completes is the percentage worth routing. No benchmark can answer that for your repository.

How Ankra fits

On Ankra, this becomes a managed Kubernetes and inference stack: NVIDIA operator, multi-node vLLM or Dynamo, LiteLLM, per-user keys and budgets, dashboards, DNS and TLS. The GPU cluster remains in your UpCloud account. The prompts and model traffic stay on infrastructure you control.

You keep Claude Code as the interface and point routine work at the gateway. Claude Code supports an Anthropic-compatible endpoint through ANTHROPIC_BASE_URL. The workflow stays. The bill changes.

The GPU Chat Stack guide covers the complete deployment. I covered the privacy and control side separately in the managed private AI stack post.

---

Get started: Create a free account on Ankra and provision your first cluster inside the free 30 vCPU allowance.

Join our community: Slack

Follow us on: LinkedIn | GitHub

Contact us: [email protected]