Troubleshooting
When something goes wrong, Pyre tries to tell you what and why rather than hide it. This page maps the common symptoms to their cause and fix.
A generation errors out or hangs
What you see: a reply that fails with a human-readable message (offline vs timeout vs server error) and a Retry button, or a "Generating…" bubble that won't resolve.
Why: Pyre turns raw network failures into typed, readable errors instead of console stack traces. It also runs stall detection (a connect timeout and an inter-chunk timeout), so a stream that goes silent doesn't hang forever — it surfaces the stall. Dropped or garbled response frames are counted and shown too.
Fix:
- Tap Retry — many failures are transient.
- Check that your provider is up, your API key is valid, and your network is connected.
- If it keeps stalling, your provider or model may be overloaded — try again, or switch the active provider under More → API Connections.
Android
Minimizing the app mid-stream is fine — a foreground service ("Pyre — generating response") keeps an in-flight generation alive so Android doesn't kill it and drop the reply.
A provider refuses
What you see: a short reply that reads like a refusal, and (if you have another provider configured) a prompt offering to switch.
Why: Smart provider fallback detects refusals conservatively (short reply, no roleplay markup, an English refusal phrase) and offers — never silently — to retry on your next configured provider. Pyre also learns which providers tend to refuse and can suggest one that "tends to handle this better".
Fix:
- Accept the offer to switch to another provider.
- Or change the model — an uncensored / DeepSeek-family model is far less likely to refuse roleplay.
- You can disable the prompt entirely in API Connections → Advanced if you'd rather it never ask.
A Creator card came out incomplete, or not in English
What you see: a card that's missing fields, reads as truncated, or comes back in a language you didn't want.
Why: in the Creator, the model matters more than the prompt. The Creator runs a multi-pass, self-healing loop that keeps working until the card is genuinely complete, then runs a final review pass — so it takes some time by design. It's guarded by a stall cap and a hard iteration ceiling; if those are hit, the session surfaces the finish reason instead of looping forever.
Fix:
- Use a recommended / uncensored model — check the recommended-models banner under More → Character Creator.
- Give the loop time to converge; it's not a one-shot "Generate now".
- For language, you can add an instruction (e.g. "always reply in English") in the Creator's free-form "Your additions" addendum.
QR pairing or camera issues
What you see: the camera won't open, or scanning the desktop's QR code does nothing.
Why: scanning needs camera permission on the phone. Pairing can always be done by hand as a fallback — the desktop shows the host, port, and token in text, not only as a QR code.
Fix:
- Grant camera permission to Pyre, then try scanning again.
- Or type the code manually using the host + port + token shown on the desktop.
- Make sure both devices are on the same network and the desktop's LAN server is enabled (it's off until you opt in).
Sync didn't carry something across
What you see: an edit made on one device doesn't appear on the other, or an old value "wins".
Why: sync merges last-write-wins by modification time (mtime), per record (and per message). The most recently edited version is the one that survives. Sync also skips pushing while a generation is in flight.
Fix:
- Use Force sync now on the mobile device to push/pull immediately.
- Confirm both devices are on the same network and the desktop server is enabled.
- Remember that a newer edit elsewhere can overwrite an older local one — that's the merge working as intended.
Info
If Pyre nudges that "the other device is newer" (a schema-version mismatch), update the older install before relying on sync.
A local / self-hosted model's first request is slow
What you see: the very first message to a local server times out or takes a long time, then later messages are fine.
Why: this is a cold start — the local server is loading the model into memory before it can answer, and local inference is generally slower than a hosted API.
Fix:
- Pyre uses more patient timeouts for localhost providers, and can fire a warm-up preload when the app starts so the model is ready before your first message. This is a localhost-only option, controllable per provider.
- Make sure the warm-up / preload on launch option is enabled for that provider, or just send one throwaway message to trigger the load, then continue.