Providers

How Fring routes model requests, and which providers are available.

Fring routes every model request through Fring Zen, our metered gateway. You sign in once and get a curated set of models — there are no per-provider API keys to collect, store or rotate.

This is the part of Fring that differs most from a bring-your-own-key setup, so it is worth being precise about what is and isn’t possible.

Signing in

fring login

That opens the browser, authenticates you against fring.ai, and writes a key scoped to your workspace. The desktop app and the IDE extension use the same account — sign in once on any surface and the others pick it up.

To check which account and plan you are on:

fring console status

What you get

Signing in configures a single provider, opencode, pointed at the Zen gateway. Every model below is reachable through it, metered against your plan:

minimax-m2
minimax-m3
glm-5.2
glm-5.3-flash
kimi-k2.6
kimi-k2.7-code
kimi-k3
qwen3.7-plus
deepseek-v4-pro
gpt-oss-20b

All of them support tool calling; several also expose reasoning. Rather than restate per-model capabilities here — where they would go stale the first time the catalog moves — check them in the model picker, which reads the live catalog.

The catalog is served by the console, not compiled into the client, so models are added and retired without you updating anything. To see the current list from your own install:

fring models

Models are referenced as opencode/<model> — for example opencode/glm-5.3-flash. The opencode prefix is the provider id, not a brand name; it is the same identifier the gateway routes on.

Choosing a model

Set one for a project in opencode.json:

{
  "$schema": "https://fring.ai/config.json",
  "model": "opencode/glm-5.3-flash"
}

Or globally in ~/.config/fring/fring.json. In the TUI and the desktop app, the model picker in the composer changes it for the current session.

If you never choose one, Fring uses the default the console currently ships. That default is a server-side setting, so it can change without you upgrading — and choosing a model yourself always wins over it.

Providers that are not available

Once you are signed in, direct provider credentials are ignored. The console sends an allowlist — enabled_providers — and the engine treats it as a hard filter: a provider that is not on it is dropped even when you have working credentials for it, whether those come from an environment variable, an auth.json entry, or a custom loader.

So on a signed-in account, setting ANTHROPIC_API_KEY or OPENAI_API_KEY does nothing. The key is not rejected with an error — the provider simply never appears in the picker, which is worth knowing before you spend time debugging it.

Two providers are allowed: opencode (Zen) and kimi-for-coding.

A further set is explicitly disabled because it would bypass metering by routing to the same upstream models Zen already meters: minimax, minimax-coding-plan, minimax-cn, minimax-cn-coding-plan, kimi and cloudflare-ai-gateway.

Bring your own key

Gateway-routed BYOK exists in the codebase but is off. When it is enabled, supported providers are routed through Zen with your key so usage is still metered server-side, rather than being hidden from the picker. Until then, Zen is the only route.

If you need a provider we do not carry, email us — the catalog is a deliberate list, and what goes on it is driven by what people actually ask for.

Enterprise

Workspaces on an enterprise plan draw from a shared token pool rather than per-user allowances, and administrators can restrict which models their members may select. See Enterprise for pooled tokens, SSO and admin controls.