Connect and "Use as LLM" on the LiteLLM Gateway card now resolve that
card's own saved key (engine_api_keys[name]) server-side in
routes/docker.py, ahead of the old global llm_api_key fallback. The
browser can no longer reliably forward a saved key at all -- it's
masked to "__configured__" in every /api/settings response the moment
it's saved -- so relying on a frontend-forwarded header alone left
Connect silently using a stale global key after LiteLLM's own key was
rotated, surfacing a misleading /api/version 404 instead of the real
401.
"Use as LLM" now goes through a dedicated /use-as-llm endpoint that
saves the exact credential Connect just verified (llm_url normalized
to .../v1, llm_api_key copied from the card), rather than a
separately-typed value that could drift again.
Also documents per-user provider-key storage as an explicit item for
the deferred multi-user/identity planning pass.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Three research passes into what multi-user hosting would require found the
app has zero multi-tenancy today: one global settings/database/voice
library, no browser-UI authentication at all, global (not per-user)
concurrency limits, and no consent/audit mechanism for voice cloning.
The user wants a single shared, interconnected login/profile system across
all their self-hosted apps rather than a per-app login, extending the
GoTrue+Postgres+PostgREST stack OurFlashcards already runs on the NUC — so
this is recorded as a deferred, cross-repo initiative rather than
implemented now. One policy decision was made and is captured for future
implementation: voice cloning will require a consent attestation with an
audit trail once accounts exist.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
