kimi.com to kimi.ai .... update kimi-web

[yoursshadow50]

in kimi-web ,it need to support kimi.ai cookies

Outside mainland China? Go to Kimi.ai
Kimi has been upgraded. If you're outside mainland China, sign in at Kimi.ai with your Google account or a non-+86 phone number to continue

[diegosouzapw]

Hey @yoursshadow50! Good news -- this is likely already supported: the kimi-web executor now points directly at the international domain (https://www.kimi.ai), and when you paste a cookie into the Kimi connection form OmniRoute extracts just the access_token from it (browser cookies are never replayed upstream).

Steps to get on the fixed path:

1. Update to the latest version (npm i -g omniroute@latest, or pull the newest Docker image)
2. Re-open the Kimi connection and re-capture the token while logged in at www.kimi.ai
3. Test a kimi-web/* model

If it still fails after that, paste your omniroute --version plus the exact error and I will trace it.

[yoursshadow50]

you are right it point kimi.ai but it only work some hours after that it showes like this Kimi session is invalid or expired — re-login at https://www.kimi.com and paste a fresh access_token ,but when use use cookie in kimi.com it stays long and work also long ....fix this issues

[diegosouzapw]

Right -- the executor talks to www.kimi.ai, so capture the access_token from a logged-in kimi.ai session specifically; a kimi.com token is domain-scoped and may behave differently even though the domains look interchangeable.

If a fresh kimi.ai token genuinely dies within hours while kimi.com cookies live longer, that's upstream session policy -- paste the expiry window you observe (hours vs days) and I'll investigate whether we can add proactive refresh before marking it an upstream limitation.

[yoursshadow50]

i dont know when i dies.....but i think it dies some few minutes....
{"level":30,"time":"2026-08-24T16:43:17.744Z","service":"omniroute","module":"sse","tag":"HTTP","method":"POST","path":"/v1/chat/completions | kimi-web/k3 | 1 msgs","msg":"📥 POST /v1/chat/completions | kimi-web/k3 | 1 msgs"}
{"level":30,"time":"2026-08-24T16:43:17.767Z","service":"omniroute","module":"sse","tag":"ROUTING","msg":"Provider: kimi-web, Model: k3"}
{"level":30,"time":"2026-08-24T16:43:17.774Z","service":"omniroute","module":"sse","tag":"AUTH","msg":"session_key=input:sha256:caced... has no available affinity target"}
{"level":30,"time":"2026-08-24T16:43:17.775Z","service":"omniroute","module":"sse","tag":"AUTH","msg":"Using kimi-web account: ***..."}
[16:43:22] 📊 [USAGE] KIMI-WEB | in=208 | out=2 | account=f5dd4cac... (estimated)
[16:43:22] 🌊 [STREAM] KIMI-WEB | k3 | 4131ms | complete

Testing 1/1 connections...
[CredentialHealth] ❌ kimi-web/f9c7adf1-9349-4fd9-a7f8-b5563d369a76 — Kimi session is invalid or expired — re-login at https://www.kimi.com and paste a fresh access_token [655ms] (failure #1, next check in 600s)

[diegosouzapw]

Found it, @yoursshadow50 -- and I gave you a wrong lead in my last reply, sorry about that. It's not an upstream session-expiry policy, it's an OmniRoute bug:

The credential health check that runs every ~10 minutes in the background validates your Kimi token against https://www.kimi.com/api/user (the China-region endpoint), but the actual chat executor talks to https://www.kimi.ai (international). A kimi.ai-scoped access_token gets rejected by kimi.com, so the health check flags your connection as "expired" and disables it -- even though your chat requests against kimi.ai were still working fine right up until that point. That's exactly the "works for a bit, then dies" pattern from your log.

Opened #11515 to track the fix (pointing the health check at kimi.ai to match the executor).

No reliable workaround until that lands, unfortunately -- the connection will keep getting gated out on the next health-check cycle regardless of how fresh the token is.

[yoursshadow50]

still the kimi-web token expires in 15 min .....even iam using v3.8.51 ,

this ss not meant expired ....i take this ss when i was added account..................
{"level":30,"time":"2026-09-02T02:59:51.789Z","service":"omniroute","module":"sse","tag":"HTTP","method":"POST","path":"/v1/chat/completions | kimi-web/k3 | 1 msgs","msg":"📥 POST /v1/chat/completions | kimi-web/k3 | 1 msgs"}
{"level":30,"time":"2026-09-02T02:59:51.798Z","service":"omniroute","module":"sse","tag":"ROUTING","msg":"Provider: kimi-web, Model: k3"}
{"level":30,"time":"2026-09-02T02:59:51.802Z","service":"omniroute","module":"sse","tag":"AUTH","msg":"session_key=input:sha256:b1f23... has no available affinity target"}
{"level":30,"time":"2026-09-02T02:59:51.802Z","service":"omniroute","module":"sse","tag":"AUTH","msg":"Using kimi-web account: ***..."}
[ERROR] [401]: Kimi error: {"code":"unauthenticated","message":"invalid user token: token has invalid claims: token is expired","details":[{}]}
{"level":30,"time":"2026-09-02T02:59:52.407Z","service":"omniroute","module":"sse","tag":"AUTH","msg":"3606a5a9 already marked unavailable (until 2026-09-02T03:00:04.186Z), skipping duplicate mark"}
{"level":40,"time":"2026-09-02T02:59:52.407Z","service":"omniroute","module":"sse","tag":"AUTH","msg":"Account 3606a5a9... unavailable (401), trying fallback"}
{"level":40,"time":"2026-09-02T02:59:52.408Z","service":"omniroute","module":"sse","tag":"AUTH","msg":"kimi-web | all 1 active accounts rate limited (reset after 12s) | lastErrorCode=401.0, lastError=Kimi error: {"code":"unauthenticated","message":"i"}
{"level":40,"time":"2026-09-02T02:59:52.408Z","service":"omniroute","module":"sse","tag":"CHAT","msg":"[kimi-web/k3] [401]: Kimi error: {"code":"unauthenticated","message":"invalid user token: token has invalid claims: token is expired","details":[{}]} (reset after 12s)"}

[diegosouzapw]

@yoursshadow50 — one correction that changes what to do next: you are not running 3.8.51. It has never been published:

$ npm view omniroute version
3.8.50

3.8.51 is the in-flight release branch. If you installed from a release ZIP, the banner shows the version string baked into that ZIP, not a published build — so "even I'm using v3.8.51" does not tell us which code you are actually running, and that matters here.

The health-probe fix from #11515 landed in #11521 (2026-08-25). The probe now validates against www.kimi.ai, matching the executor (src/lib/providers/validation/webProvidersA.ts:40). If your ZIP predates that commit, you are still hitting the original bug and the 15-minute expiry is the same problem I already described, not a new one.

So first, confirm what you are on:

npm install -g omniroute@latest   # gets 3.8.50
omniroute --version

Then re-capture the token from a logged-in www.kimi.ai session and watch whether it survives past the ~10-minute health-check cycle.

If it still dies at ~15 minutes on a confirmed 3.8.50 install, that is genuinely a new finding and I want it — with these three things:

1. The output of omniroute --version.
2. The full log line where the connection flips to unavailable, including lastErrorType and errorCode (redact the token).
3. Whether a chat request still succeeds immediately before that flip, as in your earlier log.

That third point is the one that separates the two possibilities. If chat works right up to the moment the health check disables the connection, it is still a probe/executor mismatch. If chat fails too, the token itself is genuinely expiring and that is upstream session policy — a different problem needing a different fix.

Sorry this has dragged. Let us settle which build you are on first, because I do not want to chase a bug that was already fixed in code you may not have.

[yoursshadow50]

i running image in hugging face space with "next-web " ..it has the kimi health-probe fix ,but still i get an error

[diegosouzapw]

@yoursshadow50 — thanks for narrowing it. "Runs a HF Space image that has the fix and still errors" is a much better starting point than the version question we were going in circles on. But it is still not enough to act on, and here is precisely why.

Two different things can produce "still an error", and they need opposite fixes:

1. The image does not actually contain the fix. The kimi probe fix landed in fix(kimi-web): align health probe with executor domain #11521 (2026-08-25), pointing validation at www.kimi.ai in src/lib/providers/validation/webProvidersA.ts:40. A Space image built from a ZIP or tag that predates that commit still hits the original bug no matter what version banner it prints. "next-web" tells me nothing about which commit it was built from.

2. The image has the fix and the credential is expiring. This is the failure I originally described, and it is not a bug — the Kimi web access_token from localStorage has a short life, so it works, then stops, on a timer. A Space that cannot be re-credentialed easily makes this look permanent when it is not.

So the two questions that separate them:

• What is the exact error? Status code and the response body text, redacted of any token. "An error" is compatible with both branches above; the status code is not — a 401/403 points at (2), something else usually points at (1).
• Does it fail immediately after you paste a fresh token, or only after some minutes of working? This one is decisive on its own. Working-then-failing is (2). Never-working is (1).

Please do not post the raw access_token or the Cookie header — redact them. I only need the status line and the message.

If it turns out to be (2), the useful thing to file is not a kimi bug but a credential-lifetime problem for containerized deployments, which is a real and different gap.