Skip to content

Providers & connections

Pyre is bring-your-own-key (BYOK). Native apps call the provider you configure directly. Web/PWA clients call through your paired hub so the browser never stores a key.

Provider formats

Pyre supports:

  • OpenAI-compatible chat completions: OpenRouter, OpenAI-compatible first-party APIs, NanoGPT, community proxies, LM Studio, llama.cpp, Ollama-style servers, and other compatible endpoints.
  • Anthropic-native API on native apps.
  • Localhost / LAN servers with longer patience for cold loads and slow inference.

Provider kind is partly a UI grouping and partly behavior: localhost providers can use model warm-up and longer timeouts, while Anthropic-native calls use Anthropic's own request format.

Browser and hub exception

Android and desktop apps can store provider keys in OS-secure storage and call providers directly. A browser/PWA does not. It streams chat through the paired desktop or self-host hub, and the hub calls the provider with its own key.

The proxy can forward OpenAI-style image blocks and reasoning deltas, but provider management, model browsing, smart fallback chains, and direct Anthropic-native calls stay native/hub-side.

Add a provider

  1. Open More -> API Connections.
  2. Add a connection and choose the provider format/kind.
  3. Enter the endpoint URL and API key. Local servers often allow a blank key.
  4. Browse models, pick one, or type the model id manually.
  5. Test the connection.
  6. Save and make it active when you want to use it for chat.

Pyre tidies common URL shapes, so a pasted base URL with /v1 does not become /v1/v1.

Model browser, test, and warm-up

The model browser reads the provider's model list when available. Some local servers expose non-chat models too, so pick a model that can actually chat or see images.

The test action validates the connection before you trust it in a scene. Localhost providers can also run a small warm-up request on launch so the first real reply does not pay the entire cold-load cost.

Multiple providers

Keep several providers configured and switch the active chat provider at any time. You can duplicate a provider to fork an existing setup without retyping URL, model, and advanced options.

Creator and vision can have their own provider/model routing. Guide and Impersonate follow the main chat provider in current builds, which keeps one-shot writing tools from silently using a different model than the scene.

When a web client uses a hub, chat uses the hub/server provider. The browser cannot silently choose an arbitrary saved provider from the host.

Smart provider fallback

If a generation fails, returns empty text, or appears to be a refusal, Pyre can offer to retry the same turn on another provider.

  • It asks first; it never switches silently.
  • Refusal detection is conservative so in-character apologies do not trigger it by accident.
  • Pyre tracks refusal history and can suggest the "cleaner" provider for a retry.
  • You can disable the fallback prompt under API Connections advanced settings.

Learned context limits

Pyre tries to read context length from provider model metadata. If a provider rejects a long chat for exceeding context, Pyre can learn that model's practical limit, retry with a trimmed history window, and pre-trim future turns to avoid hitting the same wall.

Manual context overrides are still available when metadata is missing or wrong.

Per-provider extra params

Each provider has a JSON extra params field merged into the outgoing request. Use it for provider-specific flags Pyre does not expose directly, such as family-specific reasoning controls.

Pyre-managed fields win on conflict. If the app controls a value, such as a sampling field from the active preset, that value takes precedence over extra params.

Prompt post-processing

Some strict endpoints dislike multiple system messages or adjacent same-role messages. Per-provider prompt post-processing can reshape the outgoing message list:

  • None
  • Merge consecutive
  • Semi-strict
  • Strict
  • Single user

Leave it off unless a provider requires it.

Debug log

The local LLM debug log viewer lives under Storage -> Developer. It is local and key-scrubbed; Pyre does not upload it. Use it when you need to inspect the exact request/response shape for a provider issue.

Security

Pyre protects keys and error surfaces:

  • API keys live in OS-secure storage on native apps.
  • Browser clients never store provider keys.
  • Header sanitization blocks CR/LF injection.
  • Provider error bodies are scrubbed for Bearer / sk- style secrets before display.

See also