Add Fantastico as an LLM provider (per-developer accounts with preallocated budgets, no proxy) #13433

Summary

I'd like to contribute a new LLM provider for Fantastico. Following CONTRIBUTING.md, I'm opening this issue first to agree on the approach before sending a PR.

Disclosure: I work at Byte42, the company behind Fantastico.

The problem it solves for Continue users

When a company rolls out Continue to its developers, it has to decide how they get model access. Today the options are poor:

• One shared API key. Nobody knows who spent what, one leaked key exposes the whole budget, and revoking it stops everyone.
• One provider account per developer. That means N bills, N payment methods and no central control.
• An internal LLM proxy/gateway. It adds infrastructure to run, a bottleneck and an extra point of failure, and every prompt and every line of code passes through it.

Fantastico takes a different approach:

• One account per developer, with a preallocated budget. The company funds a single project reserve and splits it into per-developer accounts, each with its own spending limit.
• A dedicated key for each developer. Each person gets their own account key (ck-fant-…). That key can only spend its own account's credit, so a leaked key costs at most that account's remaining budget, never the company's. A key can be rotated or revoked for one person without affecting anyone else.
• One bill, under control. The company pays once, sees spend per developer, and tops up or caps accounts individually. When an account runs out, only that developer stops.
• No proxy, so no bottleneck and no interception. Fantastico only measures and controls. It never sits on the request path. Prompts and code go directly from Continue to the model provider, so Fantastico adds no latency, can't become a point of failure for completions, and never sees the content.

That last point is what makes the provider integration necessary. Continue has to perform a short credential exchange itself, so a generic OpenAI config isn't enough.

How it works (technical)

The developer's ck-fant-… key is exchanged for a short-lived runtime key, capped to the account's remaining credit:

POST https://fantastico.cc/api/edge/key
Authorization: Bearer ck-fant-…

→ { runtimeKey, expiresAt, baseUrl, defaultModel, chatDefaults, ... }

Continue then calls the OpenAI-compatible chat/completions endpoint at baseUrl directly with runtimeKey. When the runtime key expires or reaches its cap, the endpoint returns 401/402 and a new one is minted. The official client is the MIT-licensed @byte-42/fantastico-sdk.

Proposed implementation

• core/llm/llms/Fantastico.ts extends OpenAI, with providerName = "fantastico" and apiBase defaulting to https://fantastico.cc/api.
• Before each request, make sure there's a valid runtime key, kept in memory only and refreshed shortly before expiresAt. Send the request to the minted baseUrl and merge chatDefaults into the body. On a 401/402, mint a new key and retry once. If the account itself is out of credit, show the error clearly, so the developer knows to ask for a top-up.
• No new dependency: the exchange is a small fetch.
• Register the provider in the usual places (LLMs, config types/schema, GUI provider list), add vitest tests with a mocked mint endpoint, and add a docs page at docs/customize/model-providers/more/fantastico.mdx that explains the per-developer key setup.

Example config, as a developer would use it:

models:
  - name: Fantastico
    provider: fantastico
    model: anthropic/claude-sonnet-4.5
    apiKey: ck-fant-...

Questions for maintainers

1. Can a provider whose auth needs a token-exchange step live in core/llm/llms, or would you prefer it to go through packages/openai-adapters?
2. Is the "more providers" docs section the right place for it?

Happy to adjust the approach to your feedback before opening the PR.