#Kimi Error 400 persists

1 messages · Page 1 of 1 (latest)

mossy shoal
mossy shoal
#

I switched model to "kimi-for-coding" as recommended by Moonshot, still 400. Any ideas?

#

Thanks for your consideration.

#

--
API call failed (attempt 1/3): BadRequestError [HTTP 400]
🔌 Provider: kimi-coding Model: kimi-for-coding
🌐 Endpoint: https://api.kimi.com/coding
📝 Error: HTTP 400: Error code: 400
⚠️ Non-retryable error (HTTP 400) — trying fallback...
❌ Non-retryable error (HTTP 400): HTTP 400: Error code: 400
❌ Non-retryable client error (HTTP 400). Aborting.
🔌 Provider: kimi-coding Model: kimi-for-coding
🌐 Endpoint: https://api.kimi.com/coding
💡 This type of error won't be fixed by retrying.
─ ⚕ Hermes ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

 Error: Error code: 400

_

upbeat finch
#

Your latest attempt is cleaner than the first log, but the endpoint/key split is still the thing I would verify next.

Hermes has two Kimi/Moonshot paths:

Kimi Coding Plan keys, usually starting with sk-kimi-, route to:

https://api.kimi.com/coding

with model:

kimi-for-coding

Legacy Moonshot/Kimi platform keys route to:

https://api.moonshot.ai/v1

and should not be forced onto https://api.kimi.com/coding.

Your first log showed a few mixed states:

qwen/qwen3.6-plus was sent to provider=kimi-coding, which is not a valid pairing.

kimi-coding-cn returned Invalid Authentication, which is a separate China endpoint/key issue.

Now that you are using kimi-for-coding, please check one thing: are you manually setting KIMI_BASE_URL=https://api.kimi.com/coding?

If your key starts with sk-kimi-, remove any manual KIMI_BASE_URL override and let Hermes auto-route it, then use:

provider: kimi-coding
model: kimi-for-coding

If your key does not start with sk-kimi-, do not use https://api.kimi.com/coding; use the normal Moonshot endpoint path instead:

https://api.moonshot.ai/v1

Do not paste your key, but please say whether it starts with sk-kimi- and whether KIMI_BASE_URL is set in ~/.hermes/.env. That will tell us whether this is still a local endpoint/key mismatch or whether Kimi is rejecting a valid Coding Plan request body.

mossy shoal
upbeat finch
#

That older thread is useful background, but it is not the next thing I would try first.

That thread was about kimi-k2.6 returning 404 on the Kimi Coding endpoint. Your current repro is different: kimi-for-coding is reaching https://api.kimi.com/coding and returning HTTP 400.

So before changing paths again, please answer the two checks above:

Does your key start with sk-kimi-?

Is KIMI_BASE_URL set in ~/.hermes/.env?

If you want to run one direct check while you are there, this is the useful one for a Coding Plan key:

curl -sS https://api.kimi.com/coding/v1/models -H "Authorization: Bearer $KIMI_API_KEY" -H "User-Agent: claude-code/0.1.0"

Do not paste the key. Paste only the returned model names or the error body.

If your key does not start with sk-kimi-, then this Coding endpoint test is expected to fail, and we should move you back to the normal Moonshot path instead of continuing on api.kimi.com/coding.

mossy shoal
#
  • my key starts with sk-kimi-
  • my .env does not have any kimi_base_URL set

I just set the model again:

Current model: kimi-for-coding
Active provider: kimi-for-coding

Kimi / Moonshot API key: sk-kimi-... ✓
[K]eep / [R]eplace / [C]lear (default K): k

Detected Kimi Coding Plan key → https://api.kimi.com/coding

Default model set to: kimi-for-coding (via Kimi Coding)

#

curl gives the

{"data":[{"id":"kimi-for-coding","created":1761264000,"created_at":"2025-10-24T00:00:00Z","object":"model","display_name":"Kimi-k2.6","type":"model","context_length":262144,"supports_reasoning":true,"supports_image_in":true,"supports_video_in":true}],"object":"list","first_id":"kimi-for-coding","last_id":"kimi-for-coding","has_more":false}

#

it appears my .env had many key strings concatenated into one line, I missed this when inspecting it first. Now I have cleaned up the .env entry for kimi key, will report back.

upbeat finch
#

Sounds like a good lead. Lmk.

mossy shoal
#

all good now. I have not edited the .env myself at that line. Is there a chance hermes has scrambled that line? There were about 10 concatenated keys on one line. I will look for pre-update backup to check

mossy shoal
#

@upbeat finch Thank you for the help.

upbeat finch
#

np. looking into the code question about how they mightve got mangled

mossy shoal
#

Even the earliest pre-upate snapshot has the concatenated key issue. Keys are concatenated directly, in one case separated by "[2;6~" string

#

The earliest snapshot I have is from 6th May.

#

The concatenated keys were all repeats of the same string.

upbeat finch
#

That string looks like terminal escape-code input, not part of a Kimi key. [A / [B are arrow-key sequences and [2;6~ is a modified Insert-key sequence. So the .env line was probably polluted by terminal keypress/control codes being captured as text, or by pasting from a terminal buffer that included them. Hermes’ .env writer normally sanitizes and atomically rewrites the file, so this does not look like normal file scrambling. If this happened while using hermes model or hermes setup, it would be useful to know the terminal app/OS and exact input path, because that may indicate a prompt/input handling bug.

#

So, it's terminal junk leaking in whenever you added that key. It could be fixed now, not sure. Can you tell me your OS and terminal you used to set that up initially?

#

I'll log that info if we run into it again and then we can close out the thread since you were able to manually fix the key.

#

Or if you're feeling up to trying to repro that on a key add on the same machine through the same method you last updated the key and also give the OS and terminal info, we can see if this needs a fix now still. The number of OS and terminal variants make these things hard to track down, so any info we can gather that makes this something we can test is useful.

mossy shoal
#

Thanks, I guess I have the root cause, and it is not Hermes.

When I entered the key for the first time, I had no idea how to paste into terminal window and that I am actually NOT going to see the pasted text. Until I finally hit ENTER, I hit those keys and did those paste commands more times. It was all me.

#

Thank you for supporting my self-improvement 😳

#

FYI it happened on Windows 10 in WSL2 plain terminal.