Start with a workload and two ledgers
A local model can remove a per-token API charge while adding hardware constraints and operating work. To make that tradeoff concrete, this article combines a dated workstation observation with three calculations using the existing Solo calculator. The machine observation was real; the workload and prices in the calculations are illustrative. We did not install or benchmark a language model for this comparison.
The hardware ledger: available memory is a snapshot
Our October 29, 2026 workstation assessment recorded 20 logical CPUs and approximately 62.4 GiB of RAM. Available memory ranged from 37.9 to 38.5 GiB during a 30-second sample. Approximately 5.07 GiB of swap was occupied, with 145 pages swapped in and 48 swapped out during that window. These readings describe a machine already doing other work; they are not a model's memory requirement.
The sanitized host study retains those observations. Its original purpose was workflow-platform placement, so it supplies host context rather than an inference benchmark. We did not measure GPU-memory fit, a model's startup peak, context-cache use, throughput or sustained quality. It would be unjustified to turn the free-RAM figure into a recommended model size.
For a later model trial, record the exact model, runtime, quantization, context limit and concurrent requests. Ollama's FAQ explains how to inspect CPU/GPU placement with ollama ps and how to configure context length. Checking the selected execution location is a separate step from seeing a local desktop window. This is a proposed measurement procedure, not a command sequence we ran for this article.
The attention ledger: execute a cost comparison
We used 10,000 original requests, 1,200 input tokens and 400 output tokens per request, 10% extra requests for retries and 80% acceptance. The first scenario assumes $1 per million input tokens, $4 per million output tokens, $20 fixed costs and $100 review. The prices are planning inputs, not current vendor rates.
- Illustrative API budget: model cost $30.80, total $150.80 and 8,000 accepted results; unit cost $0.01885.
- Zero API prices, unchanged overhead: model cost $0, total $120 and 8,000 accepted results; unit cost $0.015.
- Zero API prices, review increased to $200: total $220 and 8,000 accepted results; unit cost $0.0275.
These three outcomes were calculated locally on November 6 with the site's existing JavaScript function. They show the consequence of the inputs. Zeroing token prices is not proof that local inference is free: electricity, purchased hardware, maintenance and time must be included in the fixed or review budget. Holding acceptance at 80% is also an assumption, not evidence that two models have equal quality.
Use the result to choose the next experiment
Under the first two scenarios, removing API charges saves $30.80 per month. Under the third, the extra review budget more than consumes that saving. A sensible next step is therefore to measure review time and accepted outcomes on the same task before buying hardware. The cost calculator can reproduce the arithmetic; its worked-case JSON includes the first two scenarios and additional input boundaries.
Choose a fixed set of permitted inputs, write an acceptance rule and track setup time separately from recurring review. Keep failed attempts in the record. Continue only when the measured operating cost and acceptable-result rate justify the next allocation. A fluent example, a zero API bill and a large available-memory reading each answer different questions.