For an individual developer, the lowest-risk starting point is usually the computer and accounts already available. First check whether a limited free plan or a small local model completes useful tasks. Buy additional hardware only after a repeatable workload demonstrates why it is needed.
This guide uses a transparent budget example. It does not report a local-model speed benchmark or claim that a free download means cost-free operation.
Choose the first experiment
| Situation | First experiment | Evidence needed before spending more |
|---|---|---|
| Occasional coding help | Existing limited free access | Whether your normal tasks fit its allowance |
| A machine with spare memory | A local model on a small task | Actual memory use, latency, and accepted result |
| Frequent complex repository work | A capped paid trial | Cost and review effort per accepted task |
| Sensitive code | Check the entire data path | Which components send code or metadata externally |
Keep a cash ceiling and a stopping rule. If the tool cannot complete a representative task after the agreed attempts, record the failure instead of repeatedly upgrading the environment until it works.
A home-computer cost example
Assume 100 watts of incremental power, two hours per day, thirty days, and $0.20 per kWh:
0.1 kW × 2 hours × 30 days × $0.20 = $1.20/month
If you buy $600 of additional hardware and allocate it over 36 months, the hardware allocation is $16.67/month. Adding electricity produces $17.87/month, before setup time or other costs. The calculator’s saved result reproduces that total.
These are illustrative assumptions. Measure the incremental draw of your real setup, including idle time if it exists because of this workload. If you already own the computer, incremental cash and allocated hardware cost answer different questions. The hardware purchase still requires cash upfront.
Check the whole local configuration
Ollama’s FAQ covers configuration, memory behavior, and local versus cloud operation. Continue’s configuration reference lets you inspect which providers and models are assigned to features. Review every enabled model role, including completion and embedding, rather than assuming one local chat model makes the whole editor local.
GitHub’s billing documentation describes Copilot Free as limited individual access. Treat free-plan allowances as a constraint to verify in the account, not an unlimited substitute for every coding workflow.
A useful acceptance test for your machine
Pick a small real change: add a validation branch and its test, explain a module before editing it, or fix a deterministic failing test. Save the starting revision and the acceptance command.
Record the model artifact, quantization, runtime, context settings, elapsed time, peak memory, retries, and reviewer corrections. Compare against doing the same kind of work without the tool. Keep task scope comparable; an autocomplete suggestion and a repository-wide migration are not equivalent units.
If the model runs out of memory, reduce unnecessary context or try a smaller artifact before buying hardware. If it fits but produces poor patches, more memory alone does not resolve the quality problem. If it is accurate but too slow, measure whether waiting time is actually on the critical path of your work.
Do not use a nominal parameter count as the whole memory budget. Weights, cache, runtime buffers, and other active applications all need space. The Ornith sizing example shows how a weight-only lower bound differs from a fit guarantee.
When paid usage makes sense
Compare the additional hardware purchase with the recurring expense it would actually replace. For example, recovering a $600 purchase by avoiding a $20 monthly subscription takes thirty months before electricity, maintenance, time, or differences in capability. If you still need the subscription for difficult tasks, the avoided amount is smaller.
Use the full cost calculator to keep those assumptions visible. A mixed setup can be reasonable: local assistance for suitable tasks, capped remote usage for others. Judge it by accepted work and the bill you can afford.
Revision note
Updated October 20, 2026. Removed the zero-operating-cost promise, unsupported local-versus-cloud performance percentages, and unverified firsthand claims. Added explicit power/hardware assumptions and a repeatable acceptance checklist.
Primary sources
Checked October 20, 2026: ollama faq; continue config; copilot billing.