🔌 Widget reliability — chats that survive a restart, and a cursor that stays put

Released 2026-09-05

Two bugs made the chat widget feel unreliable in ways that were easy to blame on the network: chats that stopped working partway through, and a cursor that vanished after every reply. Both are fixed. You can also now point ChatterMate at any OpenAI-compatible model endpoint.

Highlights

Chats no longer fail partway through

The conversation token is meant to authenticate the socket connection. It was being re-checked on every event instead, so a chat left open longer than its token started failing one action at a time — messages that wouldn't send, and "Authentication failed" when closing the chat. It affected anonymous visitors too, which is what made it look like a network problem.

Identity now comes from the connection itself. Expiry and revocation still take effect, on the next connect.

The widget reconnects on its own

It used to give up after five attempts — roughly fifteen seconds, less than a backend restart takes — and then stay dead until the visitor reloaded the page. It now keeps retrying with backoff, presents the current token on each attempt rather than the one the socket was built with, and retries connections the server refused, which socket.io does not do by itself.

The cursor stays in the box

The input was disabled while the assistant was replying, and disabling an input blurs it — so the cursor disappeared after every message and the visitor had to click back in before they could keep typing. The field now stays open while a reply streams. Anything typed mid-reply is held and sent the moment the reply lands, so it neither starts a second answer nor goes missing.

Bring your own OpenAI-compatible endpoint

The OpenAI provider had a hardcoded URL. You can now supply a base URL with it, which covers third-party services that speak the OpenAI API — OpenRouter and the like — as well as a model server you run yourself, such as llama.cpp.

Thanks to @jorgecaravaca904 for this one.

Self-hosting: check your BACKEND_URL

The widget's socket URL is derived from BACKEND_URL. It defaults to http://localhost:8000 and neither compose file sets it, so an install that never overrode it was telling every visitor's browser to open a socket to their own machine. The widget now falls back to the origin it was actually loaded from, but setting BACKEND_URL to your public API URL is still the right thing to do.

Smaller widget fixes

• The widget addresses its host page by origin rather than broadcasting to *, so a conversation token can't be handed to a page that replaced the embedder.
• The "start a new chat?" question is withdrawn when a person joins the conversation.
• Its answers are a proper touch target on mobile.