Wires the custom relaxed-acceptance llama-server (see
../mtp-relaxed-decoding) into the stack as a new llama-mtp service,
registered as an additional OpenAI-compatible connection alongside
Ollama. ollama-auth now proxies to llama-mtp instead of the now-empty
Ollama, so LAN clients (e.g. Home Assistant's voice pipeline) keep
working against the same URL/token with no reconfiguration.
Also merges llama.cpp's `timings` extension (dropped by the generic
OpenAI response schema) into message.usage and surfaces it as a
labeled tok/s badge, so relaxed-MTP responses get the same visible
generation-speed info Ollama responses already had.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
With "show emoji in call" enabled, voice mode stayed completely silent and no request ever reached the configured TTS server. Reasoning models served with a reasoning parser return `message.content` as null and put the text in `reasoning_content`, and the emoji helper called `.replace()` on that null value and threw.
The call overlay ran the emoji request first, inside the same `try` block as speech synthesis, so that error skipped the entire TTS section. The audio cache was never filled, and the playback loop kept re-queueing the same content every 200 ms without ever playing it. Read aloud was unaffected because it synthesizes speech directly, which is why the failure looked specific to voice mode.
Fixed on both sides: the optional chain in `generateEmoji` now covers `content`, and the emoji request in the call overlay gets its own catch, matching the speech synthesis call directly below it. An emoji failure now costs the emoji instead of the whole reply.
Changing a password left every other logged-in device working until the JWT expired on its own, up to four weeks with the default settings. The hardening docs already promise the opposite: with Redis configured a password change is supposed to put the user's tokens on the revocation list, but only sign-out and OIDC back-channel logout ever wrote to it.
Both password-change paths, self-service and an admin resetting someone's password, now stamp the per-user revocation marker that token validation already checks, so every session issued before the change stops working. The acting device is signed out as well and asked to sign in again, which is the safer default when the password is being changed precisely because the old one may be compromised. Without Redis nothing can be revoked, as before, and the backend now logs a warning saying so.
The marker is written through one shared helper, so its lifetime follows the configured JWT lifetime instead of a fixed 30 days and never expires at all when JWT_EXPIRES_IN disables expiry. Back-channel logout picks that up too, where a long or disabled JWT lifetime previously let the marker expire while the tokens it revoked were still valid. API keys keep working, they are separate credentials with their own lifecycle.
Discussed in #28647.
bhethermanandClaude Sonnet 5