Continue is no longer maintained (its team joined Cursor and the repo is read-only), so for a new setup Cline or Kilo Code is the safer pick; for an existing install, the levers still hold. 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 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, and the bill stops being a variable to manage. 2-minute Continue setup → · Best models for Continue →