Continue has two cost profiles in one tool: autocomplete fires hundreds of small requests per day, while chat and inline edits send fewer, bigger ones. The canonical setup — local model for autocomplete, paid model for chat — eliminates the high-frequency half of the bill entirely.
Continue supports Ollama and other local backends natively, and small local models are genuinely good at completion. This removes the highest-request-count workload from your API bill at a stroke.
Every provider you enable adds tokens to chat requests. Keep the ones you actually use; drop the rest — it's a per-message tax.
Slash commands encode your standard instructions once instead of re-typing (and re-billing) them in every chat.
If you lean on chat and inline edits all day across a large codebase, the context-heavy requests add up; a flat-price endpoint with no usage limits covers that half while local autocomplete covers the other.
The provider-agnostic tactics (prompt caching, retry budgets, batch APIs) are in the general playbook.
On a paid API it can be — it's the highest-frequency workload in the tool. That's why the standard advice is a local model for autocomplete (free after setup) and a paid model only for chat and edits.
Yes, that split is a first-class part of Continue's config — most cost-conscious setups pair a small local model for completions with a stronger cloud model for chat.
The structural version of all of this: run Continue on a flat monthly price with unlimited tokens, and the bill stops being a variable to manage. 2-minute Continue setup → · Best models for Continue →