Models and providers

Tidebreak has no model of its own and no hosted inference. You bring credentials for the providers you want, and the app talks to them directly from your machine.

Add a credential

Open Settings → Providers. Each provider is its own section: turn on Enabled, fill in the credential, and press Save configuration.

Google Gemini is the direct Gemini Developer API path and accepts a Gemini API key.

The panel never shows a saved key back to you. It shows a status — API key set, Signed in with ChatGPT, Credential set, or No credential. Clear removes the stored credential after a confirmation.

Test a provider

Saving a provider tests it: Tidebreak makes one small request with the key and address you saved, such as asking for the provider's model list, and gives up after 8 seconds. Press Test to run it again. The key stays on your machine; the result never repeats it.

The badge on each provider says what the last test found, and the card says when it ran:

ChatGPT sign-in has no test. It is checked when you sign in, and Tidebreak asks you to sign in again if OpenAI rejects it.

API keys go to your operating system's credential store, not to the database and not to a config file. Base URLs and custom models are non-secret settings.

Built-in models

Anthropic, OpenAI, xAI, Gemini, Fireworks, and Together ship with a list of built-in models. Fireworks and Together keep their host-specific model IDs and capabilities. Nothing to configure — once the provider has a credential, its models appear in the picker. The list is versioned with the app and refreshed as providers ship new models. Each provider card names its built-in models under Models.

Each entry carries what the app actually knows about it: context window, maximum output, whether it accepts images, whether it produces a reasoning stream, and which reasoning-effort levels it accepts. Those flags gate behavior, not just labels — a model is only offered an image attachment if the path that carries images is wired for it.

Hosted Kimi K3 rows preserve their native reasoning_content only when history returns to the same provider and model, including tool continuations. A provider or model switch drops that native field under the same flatten-on-switch rule used for other reasoning artifacts. Kimi K3 exposes its documented Low, High, and Max effort choices.

Custom models

Every provider except the Model Gateway also takes models you add yourself: a model the provider ships before Tidebreak lists it, a fine-tune, or anything OpenRouter, Ollama, or your own endpoint serves. OpenRouter, Ollama, and OpenAI-compatible endpoints have no built-in list, so custom models are how you use them.

To add one, open the provider in Settings → Providers and press Add model under Models. The form takes:

• Model ID, exactly as the provider's API spells it. OpenRouter IDs take the vendor/model shape, such as anthropic/claude-sonnet-5.
• Display name. Optional; pickers show the model ID when it is blank.
• Context window and Max output, in tokens. A blank field uses 32,768 and 4,096.
• Accepts images, so attached images go to the model.
• Supports tools. Turn it off to run a chat-only model that never calls tools.
• Reasons, and the effort levels the model accepts. The form offers only the levels that provider's route sends. Leave every level clear to use the provider's default effort.

Each custom model appears in its provider card with Edit and Remove, and in the model picker beside the built-in rows. When you remove one, pickers stop offering it, and a chat that used it needs another model before its next turn.

A few rules keep a custom model honest:

• A model ID the provider already has built in is refused; use the built-in row instead. If a later release builds in a model you added, Tidebreak uses the built-in model, the provider card says so, and the next save removes your copy.
• Anthropic reasoning needs a Claude 4.6 or later model ID.
• Custom OpenAI models need an API key. ChatGPT sign-in runs only the built-in models Codex accepts.

For every field you fill in, you are asserting the provider's contract yourself. Get it wrong and turns fail at the provider rather than being caught locally.

Ollama talks to a local daemon over the OpenAI-compatible chat-completions path. Enable it, add a model you have already pulled (ollama pull qwen3:0.6b is a small tool-calling option for a first test), and leave the base URL at http://127.0.0.1:11434/v1 unless the daemon is somewhere else. A key is optional — only remote or locked-down Ollama installs need one.

The generic OpenAI-compatible slot points at any other endpoint that speaks the same API, including LM Studio, llama.cpp, or vLLM:

base URL: http://127.0.0.1:1234/v1

A server on your machine usually needs no key. Leave the key empty, and Tidebreak reaches it over plain HTTP at a loopback address such as 127.0.0.1 or localhost. If the server does want a key, Tidebreak sends it only over HTTPS, unless you tick Send the key in clear text to this loopback address for a loopback IP address such as 127.0.0.1 or [::1]. Ollama follows the same rule.

Find models

Find models asks the provider which chat models you can use, so you do not have to type IDs by hand. Tidebreak sends the request from your machine with the key you saved. The answer carries model details only, never the key.

The list leaves out embedding, image, speech, and other models that cannot hold a chat, and marks the ones that are Built in or already Added. Pick the models you want, then review them. Each one arrives with the limits the provider reported, which you can change. Fill in what the provider left out, or leave a limit blank to use the default. Nothing is added until you confirm.

Each provider reports different facts about its models:

Find models needs an API key. An OpenAI-compatible endpoint needs its base URL instead, and a key only when the server asks for one; a local Ollama daemon needs no key at all. ChatGPT sign-in cannot list OpenAI models, so save an API key to use it. The request gives up after 10 seconds and says what went wrong: a rejected key, an endpoint it could not reach, or a listing it could not read.

Choose the default model

Settings → Models sets the model for two roles:

• Work — the model new work starts on until you pick one.
• Background work — the model used for the app's own internal work (titling a chat, and similar short tasks). Cheaper, faster models suit this.

Either role can be left automatic, in which case it resolves against whatever you have credentialed at the moment you use it, rather than being frozen at the time you set it.

New work starts on the first of these that applies:

1. The model you pick in the composer before you send.
2. The model you picked most recently in any conversation.
3. The Work model in Settings → Models.

So once you have picked a model anywhere, changing the default in Settings does not change what new work starts on. When your last-used model and the default differ, the model picker names both, and marks the default in its list. Pick the default there to start from it again.

Change the model for one chat

The composer has a model pill next to the send button. It names the model the chat will run against. Until a provider is configured, it reads No model. After that it shows the current model — the one from Settings if you have not pinned one, or the pin if you have. The menu lets you switch providers and models.

The same menu carries Reasoning effort for models that expose it: Default, Off, Low, Medium, High, X-high, Max. Levels a model does not accept are not offered.

Switching models mid-conversation

You can change the model in the middle of a chat and keep the thread. The conversation is stored in a provider-neutral form, so history replays to whichever provider you switch to.

Provider-specific artifacts do not survive the crossing. A reasoning trace produced by one vendor, or a search block that vendor executed on its own servers, is replayed to a different vendor as ordinary text — or dropped — rather than being translated into that vendor's equivalent. Switch back and new turns produce native artifacts again, but the ones already flattened stay flattened.

This is deliberate. The alternative is a translator per pair of providers, and those degrade in ways that are hard to see. Expect a small loss of fidelity across a switch, not a silent re-interpretation.