SS Research
Local LLM vs. API Cost: When Does Self-Hosting Actually Win?
Compare local LLM vs. API cost with current token and GPU prices, capacity-constrained break-even math, operations, redundancy, quality, and caching.
01 Executive answer
Bottom line
Self-hosting does not win at a universal token count. In this worked 1,800-input/400-output scenario, a lean $4,699 local system crosses current GPT-5.6 Terra pricing at about 5,048 requests per day—but its illustrative planned capacity is only 5,750. At 5,500 requests per day it saves just $114 a month. Add a full spare and 20 monthly engineering hours, and the Terra crossing moves beyond the active node's capacity. At low, bursty, cacheable, or inexpensive-model volume, an API is economically obvious. Run locally when measured steady demand survives full-cost and quality tests, or when offline operation, control, latency, or data requirements justify paying more.
Use hosted APIs by default; run locally only after a quality-gated, capacity-valid full-cost crossing survives operations and redundancy.Confidence: moderateA model is only as good as its assumptions.
- Illustrative request shape: The common workload uses the calculator's editable request-shape convention, not an observed industry average.
- Operating month: All monthly request and API calculations use thirty operating days.
- Planning duty factor: The scenario reserves headroom by limiting planned traffic to 55% of extrapolated serial capacity.
- Hardware useful life: Purchase and setup cost are spread over a three-year decision life with no residual value.
- Lean setup labor: The lean owned case assigns sixty implementation and security hours at an illustrative fully loaded rate.
- Lean operating labor: The lean case assigns eight monthly hours to monitoring, incidents, patches, capacity, and model or server changes.
- Lean facility and monitoring: A broad allowance covers power, space, UPS and networking, plus monitoring and maintenance without pretending to measure a specific facility.
- Same service threshold: Every cost comparison assumes both endpoints first pass the same task acceptance, latency, reliability, safety, and recovery requirement.
- Production redundancy: The production sensitivity adds one passive full spare, doubles setup effort, and uses twenty monthly engineering hours; the spare adds no active capacity.
- Rented-GPU operation: Rental cost floors assume 730 GPU-hours, the lean setup amount, eight monthly engineering hours, and $100 monitoring, without redundancy or exact-stack throughput.
- Quality escalation sensitivity: The quality example values each additional human escalation at five dollars and changes the local escalation rate by 0.1 percentage point.
- DGX Spark purchase price: The worked owned-hardware scenario uses the current first-party marketplace listing checked on the data-as-of date.
- DGX Spark benchmark throughput: Capacity begins with NVIDIA's batch-one gpt-oss-120b llama.cpp benchmark and then applies explicit workload and planning assumptions.
The direct answer
Pricing checked: August 10, 2026. OpenAI's live standard short-context rates were Sol at $5 input, $0.50 cached input, $6.25 cache write, and $30 output; Terra at $2, $0.20, $2.50, and $12; and Luna at $0.20, $0.02, $0.25, and $1.20 per million tokens. Batch and Flex were half standard rates. Fast and long-context requests use different multipliers. Those mechanics are large enough to change the infrastructure decision.
Run your workload in the API vs. Local AI Calculator. Enter a capacity you have derived from a representative benchmark; do not accept its illustrative default as evidence. This article shows how to produce that input and where the calculator stops.
Cost is the second test; service equivalence is the first
A local LLM and an API are not interchangeable merely because both accept text and return tokens. Compare endpoints only after they pass the same task set and operating threshold. A cheaper local answer that creates more review, escalations, unsafe actions, malformed output, or missed deadlines is not the same unit of work.
| Test | Measure on representative traffic | Why price alone fails |
|---|---|---|
| Task quality | Acceptance, factuality, instruction following, structured-output success | A rejected output still consumes tokens and human time |
| Human burden | Review minutes, escalation rate, correction and fallback calls | A small rate difference can exceed the nominal infrastructure saving |
| Latency | TTFT, per-user generation speed, p50, p95 and p99 end-to-end latency | Aggregate tokens per second can hide a slow user experience |
| Reliability | Uptime, queueing, timeout, retry, recovery and failover | A spare or fallback changes both cost and capacity |
| Capability | Context, tools, modalities, safety controls and observability | A lower rate can buy a different service |
| Change | Upgrade cadence, regression rate and migration effort | Local control creates local ownership |
The local example uses gpt-oss-120b because it fits the chosen device and has a disclosed benchmark. OpenAI described it against the then-current o4-mini on selected 2025 benchmarks. That does not establish parity with 2026 Sol or Terra, and this article does not claim it.
165,000 requests/month × 0.1% extra escalations × $5/case = $825/month
At 5,500 requests per day, the lean local cost advantage is only $113.81 per month. The illustrative escalation change reverses it more than seven times over.
What the local LLM vs. API cost model must count
requests/day × days × [(uncached input × input rate + cached input × cache-read rate + cache writes × write rate + output × output rate) ÷ 1,000,000] + tools + retries + fallbacks
Use billed provider logs where possible. Prompt averages alone omit output mix, caching, retries, and non-token charges.
hardware/life + setup/life + engineering + power/facility + monitoring/maintenance + storage/network + redundancy
Monthly equivalence supports a crossing comparison; cash payback must keep initial purchase and setup as initial cash rather than amortizing them twice.
| Layer | Hosted API | Owned local | Rented GPU |
|---|---|---|---|
| Variable use | Input, output, cache, tools, retries | Power and wear; often small beside labor | GPU-hours, storage and transfer |
| Initial work | Evaluation, integration and controls | Evaluation, server, security, deployment and migration | Evaluation, image, server and deployment |
| Operation | Monitoring, quota, vendor and fallback | Patching, observability, incidents, capacity and upgrades | The same platform operation plus provider management |
| Reliability | Multi-region or provider fallback where required | Spare or multi-node fleet, failover and recovery | Additional instance, reserved capacity or API fallback |
| Change | Provider model and price migration | Weights, quantization, serving stack and hardware migration | Image, GPU type and provider migration |
| Quality | Review, correction and escalation | Review, correction and escalation | Review, correction and escalation |
This analysis preserves that canonical structure instead of inventing a competing registered model. The calculations are transparent Software Second inference, not AEM output. Read the Software Second methodology for the broader rule: compare credible alternatives against the same outcome and include the system that operates, not only the component with a posted price.
Worked scenario: capacity before break-even
| Input | Value | Status |
|---|---|---|
| Request shape | 1,800 input; 400 output tokens | Illustrative |
| Operating month | 30 days | Illustrative |
| Local model | gpt-oss-120b MXFP4 | Named scenario; no hosted-quality parity claimed |
| Device | One DGX Spark at $4,699 | Price checked 2026-08-10 |
| Vendor benchmark | 1,725.47 prompt; 55.37 generation tokens/second | Batch 1; 2,048 input; 128 output |
| Planning duty factor | 55% | Illustrative reserve for headroom |
| Useful life | 36 months; zero residual | Illustrative |
| Lean labor | $6,000 setup; $800/month operation | Illustrative at $100/hour |
| Facility and monitoring | $75 + $100/month | Illustrative broad allowances |
1,800/1,725.47 + 400/55.37 = 8.27 seconds/request
Prompt processing is about one second; decoding the longer output is more than seven. Output length therefore affects both API cost and local capacity.
86,400/8.27 × 55% = approximately 5,750 requests/day
The theoretical serial maximum is about 10,451 requests per day. The 55% factor is a planning assumption, not measured utilization.
| Planning factor | Entered capacity | Can a 5,048/day Terra crossing fit? |
|---|---|---|
| 30% | 3,135/day | No |
| 55% | 5,748/day, rounded to 5,750 | Yes, with about 700/day of headroom |
| 75% | 7,838/day | Yes, with less theoretical reserve |
Do not ship from this arithmetic. NVIDIA's source workload has only 128 output tokens, while this scenario assumes 400. Production TTFT and end-to-end latency include queueing, batching, networking, prefill, and decoding; per-user throughput can fall as concurrency rises even while aggregate throughput initially rises. Benchmark the exact model, quantization, server, prompt distribution, output distribution, concurrency, thermal conditions, and p95 SLO.
The lean owned system crosses Terra at 5,048 requests per day
1,800 × $2/1M + 400 × $12/1M = $0.0084/request
The 400 output tokens are only 18% of tokens but 57% of request cost. A total-token threshold would conceal that mix.
$4,699/36 + $6,000/36 + $800 + $75 + $100 = $1,272.19
The scenario has $10,699 initial cash and $975 monthly recurring cost. Its three-year local total is $45,799.
| Requests/day | Terra/month | Local/month equivalent | Lower-cost result |
|---|---|---|---|
| 100 | $25.20 | $1,272.19 | API by $1,246.99 |
| 1,000 | $252.00 | $1,272.19 | API by $1,020.19 |
| 3,000 | $756.00 | $1,272.19 | API by $516.19 |
| 5,000 | $1,260.00 | $1,272.19 | API by $12.19 |
| 5,500 | $1,386.00 | $1,272.19 | Local by $113.81 |
| 5,750 | $1,449.00 | $1,272.19 | Local by $176.81; no planned headroom |
$1,272.19 ÷ ($0.0084 × 30) = 5,048 requests/day
Here, high volume means about 151,000 monthly requests, 273 million input tokens, and 61 million output tokens—and only if the demand is steady enough to occupy the device.
| Volume | Cash payback using $10,699 initial and $975 recurring | Three-year comparison |
|---|---|---|
| 5,000/day | No payback within the 36-month life; simple extrapolation is 37.5 months | API $45,360; local $45,799—API still lower |
| 5,500/day | 26.0 months | API $49,896; local $45,799—local lower by $4,097 |
| 5,750/day | 22.6 months | API $52,164; local $45,799—local lower by $6,365, at the capacity ceiling |
Caching, batch, output length, and model choice can erase the crossing
| API workload | Cost/request | Planned local capacity | Local crossing | Capacity-valid? |
|---|---|---|---|---|
| Standard; 1,800 input and 400 output | $0.008400 | 5,750/day | 5,048/day | Yes; about 700/day headroom |
| Batch or Flex; 1,800 input and 400 output | $0.004200 | 5,750/day | 10,097/day | No |
| 60% steady cache-read share; 1,800 input and 400 output | $0.006456 | 5,750/day | 6,569/day | No; excludes write amortization |
| Standard; 1,800 input and 50 output | $0.004200 | 24,417/day | 10,097/day | Yes; about 14,320/day headroom |
| Standard; 1,800 input and 1,000 output | $0.015600 | 2,488/day | 2,718/day | No; about 230/day beyond capacity |
The cache row uses 720 uncached input tokens at $2/M, 1,080 cached-read tokens at $0.20/M, and 400 output tokens at $12/M. It omits the $2.50/M cache-write cost until the reuse schedule is known. Batch and Flex have different latency and availability characteristics, so the discount applies only if the work can accept that service.
The output-length rows recalculate local capacity instead of carrying forward the 400-output limit. At 50 output tokens, 1,800/1,725.47 + 50/55.37 is 1.95 serial seconds per request, yielding about 24,417 planned requests/day at the same 55% factor. At 1,000 output tokens, service time rises to 19.10 seconds and planned capacity falls to about 2,488/day. The 2,718/day price crossing is therefore not capacity-valid.
| Hosted endpoint | Input/output USD per 1M | Cost/request | Lean local crossing |
|---|---|---|---|
| OpenAI Sol | $5 / $30 | $0.02100 | 2,019/day |
| OpenAI Terra | $2 / $12 | $0.00840 | 5,048/day |
| OpenAI Luna | $0.20 / $1.20 | $0.00084 | 50,484/day |
| Claude Sonnet 5 introductory through Aug. 31 | $2 / $10 | $0.00760 | 5,580/day |
| Claude Sonnet 5 from Sept. 1 | $3 / $15 | $0.01140 | 3,720/day |
| Claude Haiku 4.5 | $1 / $5 | $0.00380 | 11,160/day |
| Gemini 3.5 Flash | $1.50 / $9 | $0.00630 | 6,731/day |
| Gemini 3.5 Flash-Lite | $0.30 / $2.50 | $0.00154 | 27,537/day |
This table answers how sensitive the arithmetic is to price, not which model should win. Providers tokenize differently—Anthropic warns that its newer tokenizer can produce approximately 30% more tokens for the same text, depending on workload—and task quality may differ far more than price. Export actual billed token counts and evaluate each endpoint independently.
Rented GPUs buy reversibility, not automatically lower cost
Lambda listed a GH200 96 GB at $2.29 per GPU-hour and an H100 PCIe 80 GB at $3.29 on August 10. At 730 continuously rented hours, compute alone is $1,671.70 and $2,401.70 per month. Per-minute billing makes rental useful for pilots and temporary demand; always-on rental needs the same operating-cost discipline as owned hardware.
| GPU | Compute/month | Monthly equivalent with lean setup and operation | Unconstrained Terra price crossing |
|---|---|---|---|
| GH200 96 GB | $1,671.70 | $2,738.37 | 10,867/day |
| H100 PCIe 80 GB | $2,401.70 | $3,468.37 | 13,763/day |
When local can be right even when it costs more
| Requirement | Why local may win | What local must own |
|---|---|---|
| Offline or air-gapped operation | No external inference dependency | Patch, access, logging, backup and incident controls |
| Data jurisdiction and retention | Direct placement and deletion control | Evidence that the complete local stack meets the requirement |
| Stable low latency | No internet path and direct scheduling | Queueing, concurrency, failover and peak capacity |
| Weights and customization | Pinned model, quantization and fine-tuning freedom | Regression evaluation, upgrades and migration |
| Vendor independence | More control over endpoint changes | Hardware and serving-stack dependencies remain |
| Predictable steady workload | Owned capacity can be highly occupied | Idle reserve and demand risk shift to the operator |
Privacy is not a binary local-good/API-bad claim. OpenAI says API inputs and outputs are not used for training by default; standard abuse-monitoring logs may be retained up to 30 days, and eligible customers can apply for Zero Data Retention or Modified Abuse Monitoring subject to endpoint restrictions. Local operation can provide stronger direct control, but it also transfers security, access, audit, patching and incident responsibility to the operator.
A control requirement should be stated as a requirement, measured, and priced. It is legitimate to choose a more expensive local service for offline availability or jurisdiction. It is not legitimate to claim that the local system is cheaper by leaving the cost of achieving that control out of the ledger.
Software Second decision
| Condition | Economic prior | Reason |
|---|---|---|
| Low or uncertain volume | Hosted API | Variable billing avoids idle hardware and platform work |
| Burst-heavy workload | API or hybrid | Peak capacity does not sit idle between bursts |
| Deferrable repeat work | Compare API Batch with scheduled rental | Both can avoid always-on cost |
| Steady load above a capacity-valid crossing | Evaluate owned local | Fixed cost may be occupied enough to win |
| Crossing disappears after operations or redundancy | Hosted API | The local saving was not production-real |
| Strict offline, control or jurisdiction requirement | Local may win despite higher cash cost | The constraint, not token price, is the decision |
| Near the boundary or quality varies by task | Hybrid | Local can serve routine work while API handles peaks, fallback and frontier cases |
- Export at least a representative month of billed requests, uncached input, cached reads and writes, output, retries, tool fees and fallback calls.
- Build a task evaluation and measure acceptance, human review, escalation, safety, structured-output success and failure consequence for every candidate endpoint.
- Benchmark prompt and output distributions under expected concurrency; set TTFT, p95 end-to-end latency, uptime and recovery targets.
- Price setup, security, monitoring, incidents, maintenance, upgrades, migration, power, facility, storage and required redundancy with named owners.
- Derive planned capacity from the benchmark and an explicit reserve; reject any crossing above that capacity and resize the fleet step by step.
- Test cache, batch, output length, cheaper adequate models, traffic variance and engineering hours before approving hardware.
- Pilot before purchase, and preserve an API fallback if the local quality or capacity margin is narrow.
If the infrastructure choice changes human capacity or downstream business value, carry the result into How to Calculate AI ROI and the AI ROI Calculator. Infrastructure savings are an input; they are not the whole business case.
These are generalized assumptions. Your traffic, quality threshold, engineering burden and control requirements will be different. Run the API vs. Local AI Calculator, review the methodology, then run the analysis against your company before committing capital or platform ownership.
Methodology, limitations, and sources
What supports this analysis—and what it cannot establish without company-specific evidence.
M Methodology
- Separate externally sourced facts, illustrative assumptions, model outputs, Software Second inference, and editorial judgment.
L Confidence and limitations
Confidence: moderate
- The worked endpoint is not assumed to match any hosted model's task quality, safety, latency, context behavior, tools, or reliability.
- The DGX Spark capacity is extrapolated from a vendor benchmark with a shorter output and is not a reproduced production p95 benchmark.
- Engineering, useful life, facility, monitoring, redundancy, and quality-escalation values are illustrative rather than industry averages.
- The public calculator does not derive capacity from utilization or model cache, batch, quality, tools, failures, or automatic fleet resizing.
- Rental results are always-on cost floors without measured throughput, storage, tax, availability, or redundancy.
- Prices and product specifications were checked on 2026-08-10 and can change quickly.
- The arithmetic is Software Second inference built from the calculator's cost structure; it is not output from a registered economic model.
S Sources
- OpenAI: OpenAI API pricing — accessed Aug 10, 2026
- Anthropic: Claude pricing — accessed Aug 10, 2026
- Google: Gemini Developer API pricing — Dated Aug 5, 2026; accessed Aug 10, 2026
- OpenAI: Introducing gpt-oss — Dated Aug 5, 2025; accessed Aug 10, 2026
- NVIDIA: NVIDIA DGX Spark marketplace listing — accessed Aug 10, 2026
- NVIDIA: DGX Spark hardware specifications — Dated Aug 3, 2026; accessed Aug 10, 2026
- NVIDIA Developer Blog: How NVIDIA DGX Spark’s Performance Enables Intensive AI Tasks — Dated Oct 24, 2025; accessed Aug 10, 2026
- NVIDIA: NVIDIA NIM LLM benchmarking metrics — Dated Jul 20, 2026; accessed Aug 10, 2026
- Lambda: Lambda GPU cloud instances — accessed Aug 10, 2026
- U.S. Energy Information Administration: Average price of electricity to ultimate customers by end-use sector — Dated Jul 23, 2026; accessed Aug 10, 2026
- OpenAI: Data controls in the OpenAI platform — accessed Aug 10, 2026
- arXiv: Beyond Per-Token Pricing: A Concurrency-Aware Methodology for LLM Infrastructure Cost Estimation — Dated Jun 10, 2026; accessed Aug 10, 2026
- arXiv: When Is the Same Model Not the Same Service? A Measurement Study of Hosted Open-Weight LLM APIs — accessed Aug 10, 2026