Continue.dev Billing Guide: Keys, Roles and Team Setup
Continue.dev is the rare tool with no billing opinions: open source, editor-native, happy to talk to any model behind any key. That neutrality makes it the perfect laboratory for pricing experiments — same sidebar, same shortcuts, different invoices. This guide shows how to run Continue on gateway keys, split models by role for maximum savings, compare keys fairly using the client's own telemetry, and roll the winning setup out to a team without turning secrets management into a second job.
Why Continue is the perfect test bench
Most tools bundle opinions about billing with opinions about workflow. Continue bundles nothing: it is an open-source client whose model backends are pure configuration. That makes it the ideal place to run pricing experiments, because the user experience stays fixed while the invoice varies. Change one config block and the same sidebar bills to a different provider.
The config file is the entire migration surface. Models per role — chat, autocomplete, embeddings, reranking — each get a provider, endpoint and key. Version-control the team base config, let developers overlay personal keys, and pricing experiments become pull requests instead of projects. No other client makes the billing layer this legible, which is why cost-conscious teams standardize here even when they flirt elsewhere for features.
- Open source, no billing opinions
- Config file as the whole migration surface
- Same UX across any backend
- Team configs in version control
Configure models by role, not by habit
Continue's killer feature for cost control is per-role models. Chat and debugging deserve the strongest reasoning you can afford; autocomplete deserves the cheapest fast model that completes sensibly; embeddings deserve whatever is cheapest per token, full stop. Defaults that use one flagship for everything waste money on every keystroke.
Write the split explicitly in config with comments explaining why each role got its model. Review it quarterly like code, because it is code that spends money. When a new generation lands, the diff is three lines and the trial is one afternoon. Teams that configure by role typically cut bills by half or more versus single-model setups with zero perceptible quality loss on daily work.
- One block per role, explicit and reviewable
- Flagship for chat, cheap for autocomplete
- Gateway keys alongside direct keys
- Smoke test each role after changes
Compare keys with the client's own data
Continue exposes enough telemetry — completion acceptance, request counts, error rates — to compare keys honestly without extra instrumentation. Run identical work weeks on each candidate key and score acceptance rate plus task success before price. A cheap key developers override constantly is not cheap; it is a tax on attention.
Add dollars per developer per week as the final column, computed from the key's price list, not vibes. Keep both configs for a month after deciding; keys have outage days and the rollback is a file swap. Document the winner per role so future model releases slot into an existing decision framework instead of restarting the debate from scratch.
- Same tickets, both keys, telemetry on
- Acceptance rate plus task success
- Dollars per week per developer
- Keep both configs for a month
Team rollout without secret chaos
Roll out with layers: a shared base config in version control holding everything except secrets, personal keys per developer for daily work, and one team gateway key with budgets for shared automation. Secrets never enter git; routing never lives in heads. New hires clone the config, paste one key and match the team's economics on day one.
Put budgets and alerts on every shared key before the team grows into them. Review per-developer spend monthly — not to police, but to spot misrouted roles and runaway loops early. The whole system stays boring on purpose: files, environment variables and quarterly reviews. Boring billing infrastructure is what lets the exciting agent work happen without finance getting involved.
- Base config in git, keys in environment
- Personal keys plus shared team key
- Budgets on shared automation keys
- Onboarding as config clone plus key paste
Keep it cheap forever
Schedule a quarterly review of every model-per-role assignment against current prices. The value ranking rotates fast; last quarter's bargain becomes this quarter's overpay silently. Use telemetry to justify downgrades — acceptance rates that hold steady on a cheaper model are permission to switch permanently.
Re-check every key's price list, not just the headline model you watch. Providers move prices on quiet models without announcements. Keep fallback configs warm for outages and deprecations. The maintenance burden is an hour per quarter, and it compounds: teams that review regularly spend less every single quarter while changing nothing about how they work.
- Quarterly model-per-role review
- Price checks on every key in use
- Telemetry-driven downgrades
- Fallback configs kept warm
Frequently asked questions
Can Continue use a third-party API key?
Yes — Continue exists for exactly this: an open-source autopilot whose model backends are fully configurable. Point its config at any OpenAI-compatible or Anthropic-compatible endpoint and every feature works against your key.
Which models should I configure?
Start with the models you already trust so only billing changes, then tier downward: flagship for chat and debugging, cheap fast models for autocomplete and bulk edits. Continue's per-role model settings make the split explicit and reviewable.
How do I compare two keys in Continue?
Compare one week of identical work on each key: completion acceptance rate, chat task success and dollars spent. Continue surfaces enough telemetry to make the comparison honest without extra tooling.
Can a team share one Continue setup?
Yes, and teams commonly do: shared base config in version control, personal keys per developer, plus a team gateway key with budgets for shared automation. Secrets stay personal; routing stays consistent.
What is the rollback plan if a new key misbehaves?
Keep the old config file untouched for a month and switch the active one back if anything misbehaves. Configs are files; rollbacks are copy commands, not migration projects.
Related guides
Keep your coding workflow moving
Kintio provides an Anthropic-compatible API for Claude Code and other developer tools. Review the fit for your workload before switching.
Explore Kintio →Last updated: