Repository navigation
feat(settings): power Loki with your own model — paste a key, get your best model - #921
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Anyone can now power Loki with the best model they have access to. Settings → AI → "Power Loki with your own model": pick a provider, open its key page from the link, paste, and the key is checked on the spot. If it works, the models it can actually use appear with the strongest one already chosen. One click saves. From then on your Loki chat runs on it.
Built on the shared
@bitbaum/ai-kit1.17.0 (probeByokKey, released for this, ai-kit#76), so every other app gets the same check with a version bump.What a person sees
What happens on the server
ai-kit/seal, AES-256-GCM, newBYOK_SEAL_SECRET) inuser_model_keys(migration 0081, hand-written like 0073–0080 because drizzle's snapshot stops at 0072). No API ever returns it. Saving re-checks it server-side rather than trusting the client.keyForLink): a user's link reads its key only from the per-call env ai-kit returns, and a server link reads onlyprocess.env. So a server that happened to setBYOK_API_KEYcan't answer users on the operator's account, and a user's key can't ride along to a vendor they didn't choose./api/settingsis denied in the shared demo account (the new sandbox guard caught it): a key saved there would power every visitor on someone's bill.Also fixed
Settings deep links threw a hydration mismatch. The server rendered Profile and the browser rendered the hash's tab, on every
/settings#…link — the new budget-refusal link would have hit it constantly. The tab is now read throughuseSyncExternalStorewith a server snapshot. Verified: a hard reload of/settings#aiopens AI with zero console errors.Verified, not assumed
gpt-oss-120bpreselected;your key: Groq · openai/gpt-oss-120b;ai_spend,ai_usageandprovider_quotaall had 0 rows.scripts/test/own-model.tsdrives the real walker with a faked fetch: one request, to the user's vendor, with their key and model, and never a server key. Mutation-checked: letting a user link fall back toprocess.env, and making the walker ignore the user's model, each fail it.pnpm verifygreen ·pnpm run buildgreen · client bundle stays Node-free.After merge: nothing to do on the box —
BYOK_SEAL_SECRETis already set there (generated on the box, never printed).🤖 Generated with Claude Code
https://claude.ai/code/session_016YJVAanfj8keVSXyZnTemh