Local LLM vs Claude for Companies: Cost by User Type

Claude reaches a company through four commercial shapes, and the one you can use depends on headcount before it depends on preference.

Two details decide which row applies to you. Team caps at 150 seats, so a company of 200 cannot put everyone on Team: anyone above that size is on metered Enterprise whether they want it or not. And Team limits are per member and not pooled, so a quiet colleague's unused allowance does nothing for the analyst who hits the wall at 2pm. The five-hour window and the weekly limit are shared across claude.ai, Claude Code and Claude Desktop, and switching models does not restore access.

The local side is simpler to describe. You take an open-weight model under Apache 2.0 or MIT, put it on a card like the 96 GB RTX PRO 6000 Blackwell (NVIDIA list price $13,250), and run it behind a gateway that handles login, rate limits and logging. The card is the cheap part. Our RTX PRO 6000 vs H100 vs L40S comparison covers the silicon; the rest of this post is about whether the model on it is good enough for each kind of user.

In our hypothetical company light users are the majority of staff and the smallest part of the bill. Take a hypothetical 140 of them, each sending about 30 requests a month at 8,000 tokens in and 1,000 out.

On Team Standard that is 140 seats at $20, or $2,800 a month. On usage-based Enterprise the seats cost the same $2,800, and the usage on Sonnet 5.5 works out to about $0.78 per person (240,000 input tokens at $2 per million plus 30,000 output tokens at $10 per million), or roughly $109 a month for all 140. Anthropic publishes no per-chat-user figure, so that number is our arithmetic on assumed volume, not a measurement.

Capability is not the problem here. For drafting an email, summarising a contract or rewriting a policy section, a single-card open model is more than enough. Qwen3.8-27B (Apache 2.0, dense 27B, 262,144-token native context) beats Opus 4.6 on instruction following on its own model card, 79.5 to 62.5 on IFBench. Gemma 4 31B, also Apache 2.0, reports 76.9% on Tau2 and ships with a technical report on arXiv. These models write fine.

The problem is that $33,600 a year of seats does not buy you out of anything. A local deployment for 140 people still needs the gateway, single sign-on, patching, monitoring and someone who owns it, and those costs sit on top of the card. On price alone, light users belong on seats.

The exception is the data. If the material those 140 people paste in is client-privileged, patient-identifiable or export-controlled, "light use" is still regulated use, and the regulated section below decides it. If you stay on Claude, two admin settings matter: Anthropic does not train on commercial data by default, but conversations users submit as feedback may be used and are kept up to five years, so turn feedback off under Organization settings, and set an organisation retention policy. Choosing the chat workspace itself is a separate decision, covered in our comparison of AI workspaces for teams.

Power users are the analysts, lawyers, engineers and operators who keep a Claude tab open all day and feed it long documents. They hit the limits first, and they are where the cloud starts to feel expensive.

Take a hypothetical 40 power users, each sending 40 requests a day for 22 working days (880 a month) at 40,000 tokens in and 2,000 out, uncached:

Add seats on top. Team Premium at $100 a seat gives these 40 people a flat $4,000 ceiling with hard walls, but only if your whole organisation is 150 seats or fewer. On Enterprise the seats are $800 and the usage is uncapped unless you cap it. Caching helps on multi-turn work (Opus 5.5 cache reads are $0.20 per million, 5% of the input price) and thinking tokens, which bill as output, push the other way.

The local side for power users is harder than it looks, because what matters is how many people are generating at the same moment and how long their documents are. One published test on a single RTX PRO 6000 ran Gemma 4 31B in FP8 with up to 24 concurrent requests and got about 27 tokens per second per request with roughly 14 requests in flight. That run used a 4,096-token context. A power user pasting a 40,000-token document is ten times that, and every extra token of context takes memory away from other users. Size a local deployment by peak simultaneous generations at your real document length, not by headcount.

Long context is also where open models visibly trail. The models that offer 1-million-token windows are 284B to 1.6T parameters, not one card, and even DeepSeek V4 Pro reports 83.5 on its own 1M-token MRCR retrieval test against 92.9 for Opus 4.6.

Our verdict for power users: Sonnet 5.5 as the default, Opus by exception, spend limits per group, and the per-user spend report reviewed monthly. Move a power user to a local model when their material is restricted, not because their bill is high.

This is the segment where "cloud is expensive" is most true and where switching away costs the most.

Anthropic's own Claude Code documentation puts the average across enterprise deployments at about $13 per developer per active day and $150 to $250 per developer per month, with 90% of users staying under $30 per active day. Agent teams in plan mode use roughly 7 times the tokens of a standard session. For a hypothetical 20 developers on usage-based Enterprise, that is $400 of seats plus $3,000 to $5,000 of usage a month. The docs do not date that average against the current model prices, so treat it as a starting point and measure your own.

Now the capability gap, independent evidence first:

Vendor tables are friendlier, and you should read them with care. GLM-5.3 and Kimi K3 report parity with Fable 5 and Opus 4.8 on Terminal Bench 2.1, but those are vendor-run, against an older Claude generation, and GLM-5.3's Terminal Bench number was run inside a Claude Code harness. Those frontier open models also need a multi-GPU server, not one card. Smaller models fall off sharply: the Qwen3.6 card lists Gemma 4 26B-A4B at 13.8 on SWE-bench Pro against 49.5 for Qwen3.6-35B-A3B.

Pointing Claude Code at a local model is also its own project; we covered what breaks when Claude Code talks to a local server separately.

Our verdict for agentic work: pay for Claude Code, set a per-developer budget, and run a pilot to get your own baseline. Use local models for repositories that are not allowed to leave, and accept that the agent will be weaker there.

Back-office pipelines are where local models look strongest on paper, and where Claude's cheapest path is also its least compliant one.

Take a hypothetical pipeline of 1 million documents a month, each 3,000 tokens in and 500 out (the 500 has to include any thinking tokens):

US-only inference adds 10%, which takes Haiku batch to $302.50.

The fair comparison for a local card is Haiku plus Batch, not Opus. On the same independent index's domain scores, Haiku 5.5 sits roughly level with the best open models: Finance 44 vs 42, Legal 39 vs 38, and behind on Healthcare, 37 vs 41. At $275 a run, one $13,250 card is about 48 months of the Haiku batch bill before you buy the host, the power, the support contract or anyone's time. For non-sensitive documents, Haiku batch wins, and the break-even analysis shows how much traffic it takes to change that.

Then come two catches that change the answer for regulated work. The Message Batches API is not eligible for zero data retention or HIPAA (it keeps data 29 days for asynchronous storage), and Claude on Amazon Bedrock's Messages integration and on Microsoft Foundry does not support Message Batches at all. A regulated pipeline therefore compares a local card against full-price synchronous calls: $550 per run on Haiku, $11,000 on Sonnet under our assumptions. Batch work does not care about latency, so a single card running overnight is well suited to throughput-bound jobs, and that is the case where local wins on both price and perimeter.

For the regulated segment the first question is which data classes are allowed to reach which processor. The options form a spectrum, not a binary:

The fine print decides the purchase:

The law is narrower than vendor marketing suggests. EU AI Act Article 26 has no hosting-location rule, but it makes deployers of high-risk systems keep automatically generated logs for at least six months, which a local deployment makes your job. GDPR Chapter V governs transfers out of the EU, and an EU-US adequacy decision has existed since July 2023. ITAR's encryption carve-out is written for storing and transmitting technical data, while a hosted model has to read the plaintext to process it; our reading is that this pushes export-controlled work local, but it is a question for export counsel. The cases that truly need no external processor are narrower than "regulated": export-controlled data, client material under terms that forbid subprocessors, and data a regulator or contract keeps in-house.

Local does not solve everything either. Insider access, your own prompt logs, prompt injection and licence terms all remain your responsibility: the Llama 4 Community License has a 700-million-user clause and a "Built with Llama" display rule, while the Apache 2.0 Qwen and Gemma models carry neither. The serving stack needs real work too. Ollama has no built-in authentication and handles one request per model at a time by default, and vLLM's built-in key does not cover every route, so both belong behind a proxy. Our guides on securing an Ollama server and hardening vLLM cover that list.

Putting the hypothetical company together: 140 light users, 40 power users, 20 developers, on usage-based Enterprise because Team cannot cover 200 people. Every volume below is the assumption stated in its section, at list prices.

The total before any batch pipeline is roughly $10,600 to $16,150 a month. The power users and developers, 60 people or 30% of staff, account for $6,520 to $12,040 of it, which is 61% to 75% of the bill including seats. That share is arithmetic on our assumptions, not a measured distribution, but it shows where to look: if your bill feels expensive, on these assumptions the cause sits with these two groups, and the first fix is a spend limit and a model default before it is a GPU.

The setup that holds up is routing by user segment and data class, not choosing one side:

That last row is the easiest one to build badly: a model server stood up by one engineer, no single sign-on, no audit trail, and a different chat window from the one everyone else uses. If you want one private workspace that serves local models to all staff, Particula Lumen runs on your servers with Ollama or vLLM models, SSO with SCIM and audit logs, on a flat annual licence with unlimited users on its Business and Enterprise tiers. Per-request routing inside a single application, sending easy prompts to a cheap model, is a different problem, covered in our guide to cheap-first model routing. More on this decision for leadership teams lives in our AI for business hub.

This week, do three small things before anyone prices a GPU: