Kimi k2p5 code | Friends of the Crustacean 🦞🤝 | Page 1

flat ravineBOT Feb 17, 2026, 9:20 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

rose willowBOT Feb 17, 2026, 9:23 AM

#

A couple gotchas here — Moonshot K2 (OpenAI-style) and Kimi Coding K2.5 (Anthropic-style) are two different providers in OpenClaw, and their keys aren’t interchangeable.

1) First: what exact error + command?

Can you paste:

openclaw --version
the exact command you ran (redact the key), and the error text

That’ll tell us if it’s a quoting/path issue vs a provider mismatch.

2) If you meant Kimi Coding K2.5 (the “code k2.5” one)

That’s the built-in provider kimi-coding, and the key should be stored as:

openclaw config set env.KIMI_API_KEY "sk-kimi-REDACTED"

Then restart the gateway.

#

Docs: https://docs.openclaw.ai/providers/moonshot (see Kimi Coding section)

3) If you meant Moonshot Kimi K2.5 (Open Platform)

That uses provider moonshot and a different env var:

env: { MOONSHOT_API_KEY: "sk-..." }

…and you also need the models.providers.moonshot block (OpenAI-compatible baseUrl etc.). Same doc as above.

4) Setting up fallback (Opus → Kimi Coding)

Once auth is in, add Kimi Coding as a fallback:

openclaw models fallbacks add kimi-coding/k2p5

#

(Or equivalently in config: agents.defaults.model: { primary, fallbacks: [...] }.)

Docs: https://docs.openclaw.ai/concepts/models

If you paste the error + command, I can point to the exact fix (this is often just “used the Moonshot key in the Kimi Coding slot” or a quoting issue).

#

That message means OpenClaw successfully reached the provider, but the provider replied with a billing/quota problem (typically HTTP 402 / “insufficient balance”). So this is usually not a config syntax issue anymore — it’s “key works, but account has no credits”.

A few quick checks:

Which Kimi did you configure? (keys are not interchangeable)

Kimi Coding → provider kimi-coding, env var KIMI_API_KEY
Moonshot K2 → provider moonshot, env var MOONSHOT_API_KEY
Docs: https://docs.openclaw.ai/providers/moonshot

Confirm + probe auth (safe output to paste)

openclaw models status --probe
# or narrower:
openclaw models status --probe --probe-provider kimi-coding
openclaw models status --probe --probe-provider moonshot

#

If you want Opus primary + Kimi fallback
Make sure your primary is still Opus, and add Kimi as fallback; OpenClaw will also fallback on billing errors if you have additional fallbacks configured.
Docs: https://docs.openclaw.ai/concepts/models

If you paste the openclaw models status --probe output (redact keys), I can tell you exactly which provider is throwing the billing error and what to top up/switch.

#

If you want Claude Opus 4.6 (Claude subscription via setup-token) as primary, and Kimi Code k2.5 (with an sk-kimi... key) as fallback, you generally want:

Anthropic auth via setup-token (stored in auth profiles; not as env.*)
Kimi Coding auth via env.KIMI_API_KEY
Default model set to Opus, with fallbacks including kimi-coding/k2p5

1) Auth setup (recommended)

Anthropic (Claude subscription → setup-token)

On any machine with Claude Code:

claude setup-token

On the gateway host:

#

openclaw models auth setup-token --provider anthropic
# (it will prompt you to paste the setup-token)

Kimi Code (Kimi Coding)

On the gateway host:

openclaw config set env.KIMI_API_KEY "sk-kimi-REDACTED"

2) Config shape (JSON5 snippet)

In ~/.openclaw/openclaw.json (or wherever your config lives), something like:

#

{
  env: {
    KIMI_API_KEY: "sk-kimi-REDACTED",
  },

  agents: {
    defaults: {
      model: {
        primary: "anthropic/claude-opus-4-6",
        fallbacks: ["kimi-coding/k2p5"],
      },
      models: {
        "anthropic/claude-opus-4-6": { alias: "Opus" },
        "kimi-coding/k2p5": { alias: "Kimi Code K2.5" },
      },

#

    },
  },
}

Then restart:

openclaw gateway restart
openclaw models status --probe

Important gotcha

“Kimi Code” in OpenClaw is kimi-coding/k2p5 (provider kimi-coding, env KIMI_API_KEY). That key is not the same as the Moonshot K2 (provider moonshot, env MOONSHOT_API_KEY). Docs: https://docs.openclaw.ai/providers/moonshot

If you paste:

openclaw --version

#

openclaw models status --probe (it redacts secrets)

…I can sanity-check that OpenClaw is actually seeing both auth methods and that fallbacks are wired correctly.

rose willowBOT Feb 17, 2026, 9:59 AM

#

Your current models status shows the core issue:

Primary is still anthropic/claude-opus-4-5 (not 4-6)
Fallbacks are empty
Your kimi-coding:default key is currently disabled due to a billing backoff ([disabled:billing 3h]) — OpenClaw will skip it until that expires (even if probes work).

Make Opus 4.6 primary + Kimi Coding fallback

Option A (easy CLI)

openclaw models set opus
openclaw models fallbacks add kimi-coding/k2p5
openclaw gateway restart
openclaw models status --probe

Option B (what it should look like in config)

#

{
  agents: {
    defaults: {
      model: {
        primary: "anthropic/claude-opus-4-6",
        fallbacks: ["kimi-coding/k2p5"],
      },
    },
  },
}

(Your Anthropic subscription auth is already fine — you have working anthropic:* token profiles.)

About `[disabled:billing 3h]` on Kimi

That flag comes from earlier “insufficient credits” responses; OpenClaw applies a longer backoff for billing errors.

#

If you’re OK waiting: just wait the ~3h and it’ll re-enable automatically.
If you topped up and want it to work immediately, clear the disable flag in the auth store:

Backup:

cp ~/.openclaw/agents/main/agent/auth-profiles.json \
   ~/.openclaw/agents/main/agent/auth-profiles.json.bak

Edit ~/.openclaw/agents/main/agent/auth-profiles.json and remove (or clear) the usageStats entry for:

kimi-coding:default (specifically disabledUntil / disabledReason)

Restart:

openclaw gateway restart

#

If you paste the usageStats block for kimi-coding:default (redacting the key), I can tell you exactly what to delete.

#

Nice — Anthropic looks solid now (opus-4-6 probes OK).

The one red flag is this line:

kimi-coding/k2p5 … unknown … ↳ LLM request timed out.

That’s almost certainly just the default probe timeout (8s) being too aggressive for Kimi Coding sometimes (the probe uses --probe-timeout default 8000ms).

1) Re-probe Kimi Coding with a bigger timeout

openclaw models status --probe \
  --probe-provider kimi-coding \
  --probe-timeout 30000 \
  --probe-concurrency 1

If that turns ok, you’re good.

#

2) Make sure you actually have fallbacks configured

Your earlier output showed Fallbacks (0) : -. Add Kimi Coding as fallback (and optionally Moonshot as a “backup fallback”):

openclaw models fallbacks add kimi-coding/k2p5
openclaw models fallbacks add moonshot/kimi-k2.5   # optional safety net
openclaw gateway restart

Order matters: it’ll try fallbacks top → bottom.

3) If Kimi Coding keeps timing out in real usage

Then it’s not just “slow probe”, it’s connectivity/provider latency. Best next step is to watch the gateway logs while you hit it:

openclaw logs --follow

#

…and then try forcing that model for one message (e.g. /model kimi-coding/k2p5 in chat) to see if it’s consistently slow/unreachable.

Docs refs:

Kimi Coding vs Moonshot (different providers/keys): https://docs.openclaw.ai/providers/moonshot
Failover behavior on timeouts/billing: https://docs.openclaw.ai/concepts/model-failover

#

To get exactly:

Primary: anthropic/claude-opus-4-6
Fallback 1: kimi-coding/k2p5
Fallback 2: anthropic/claude-opus-4-5
No Moonshot anywhere

do this:

1) Set primary + fallbacks (CLI)

openclaw models set anthropic/claude-opus-4-6

openclaw models fallbacks clear
openclaw models fallbacks add kimi-coding/k2p5
openclaw models fallbacks add anthropic/claude-opus-4-5

#


openclaw models fallbacks list
openclaw gateway restart

That alone ensures Moonshot won’t be used (because it’s not in the fallback chain).

2) Remove Moonshot from config (if you ever added it)

Check if you have a custom provider block:

openclaw config get models.providers.moonshot
openclaw config get env.MOONSHOT_API_KEY

If present, remove:

#

openclaw config unset models.providers.moonshot
openclaw config unset env.MOONSHOT_API_KEY
openclaw gateway restart

3) (Optional) Remove Moonshot credentials so it disappears from `models status`

If you want Moonshot completely gone (not even listed in “Auth overview”), delete the Moonshot profile from:

~/.openclaw/agents/main/agent/auth-profiles.json

Specifically remove:

the profiles["moonshot:default"] entry
and any usageStats["moonshot:default"] entry

Then restart:

#

openclaw gateway restart

4) Verify

openclaw models status --probe --probe-timeout 30000

If you paste the top part of auth-profiles.json (just the profiles keys, no secrets), I can point out exactly which lines to remove for Moonshot.

#

Moonshot can still show up in models status from one of three places:

Auth profile store (auth-profiles.json)
Env var (MOONSHOT_API_KEY in the gateway process env / .env / service env)
Config provider block (models.providers.moonshot.apiKey)

Your models status line tells you which one via the effective=... bit. Here’s how to remove it completely.

A) Remove Moonshot from the auth profile store (most common)

Run these on the gateway host:

Stop the gateway (avoids it re-writing usageStats while you edit):

openclaw gateway stop

Backup the store:

#

cp ~/.openclaw/agents/main/agent/auth-profiles.json \
   ~/.openclaw/agents/main/agent/auth-profiles.json.bak

Edit ~/.openclaw/agents/main/agent/auth-profiles.json and remove all of these if present:

profiles["moonshot:default"]
usageStats["moonshot:default"]
order["moonshot"] (if exists)
lastGood["moonshot"] (if exists)

(Keep the JSON valid — this file is strict JSON, not JSON5.)

Start gateway again:

openclaw gateway start

#

B) Also remove it from config/env (so it can’t come back)

Check + unset:

openclaw config get env.MOONSHOT_API_KEY
openclaw config get models.providers.moonshot

If either prints something, remove them:

openclaw config unset env.MOONSHOT_API_KEY
openclaw config unset models.providers.moonshot
openclaw gateway restart

C) Verify where it’s still coming from

Run:

#

openclaw models status

Look at the moonshot line:

If it says effective=profiles:... → it’s still in auth-profiles.json (step A).
If it says effective=env: ... → you still have MOONSHOT_API_KEY in the gateway’s environment (shell/.env/service env).
If it says effective=models.json: ... → you still have models.providers.moonshot.apiKey set somewhere (step B).

Paste just the single moonshot line from openclaw models status (the one that starts with - moonshot effective=...) and I’ll tell you exactly which source is still keeping it alive.

rose willowBOT Feb 17, 2026, 1:19 PM

#

That error isn’t a “config parsing” problem — it means the provider you just hit replied with insufficient credits / billing (often HTTP 402).

1) First confirm which provider is billing-failing

Run:

openclaw models status --probe --probe-timeout 30000

and paste just the “Auth probes” table (no secrets). That will show whether it’s kimi-coding or something else.

2) Most likely: it’s your Kimi Coding key

Even if you have a “subscription”, the API key can still be on a plan/account with 0 API credits (or the key is for a different product). The fix is on the provider side: top up / enable API billing / use a different key.

Also: when OpenClaw sees billing errors, it will often mark that profile as disabled:billing for a few hours and skip it.

3) Make sure your fallback chain is actually set (so you still get replies)

#

You want:

Opus 4.6
Kimi Coding k2p5
Opus 4.5

Do:

openclaw models set anthropic/claude-opus-4-6

openclaw models fallbacks clear
openclaw models fallbacks add kimi-coding/k2p5
openclaw models fallbacks add anthropic/claude-opus-4-5

openclaw models fallbacks list

#

openclaw gateway restart

If you paste your openclaw models status --probe output, I’ll tell you exactly which provider is throwing the billing error and whether your fallbacks are wired correctly.

#

Your latest models status --probe shows Moonshot is already gone (only anthropic + kimi-coding are listed, and the probes are all ok). So the billing error you’re seeing is not coming from Moonshot anymore.

If you still get:

“API provider returned a billing error … insufficient balance”

then it’s coming from whichever model the actual chat session is using at runtime (most likely kimi-coding), even if the probe succeeds.

1) Make sure your fallback chain is exactly what you want

Run:

openclaw models set anthropic/claude-opus-4-6

openclaw models fallbacks clear
openclaw models fallbacks add kimi-coding/k2p5

#

openclaw models fallbacks add anthropic/claude-opus-4-5

openclaw models fallbacks list
openclaw gateway restart

2) Reset the session (important: sessions pin model/profile choices)

In the chat where you saw the billing error, run:

/new
then /model status (to confirm it’s on Opus 4.6 and sees the fallbacks)

3) Confirm the Discord thread is using the same agent you’re configuring

Sometimes the Discord route is bound to a different agent than “main”. Check:

#

openclaw agents list --bindings

If Discord is bound to e.g. agentId: "work", then run:

openclaw models status --agent work --probe --probe-timeout 30000

4) If billing error persists even with fallbacks set

At that point it’s provider-side (Kimi Coding key/account reporting insufficient credits for some requests). The probe is a tiny request; “real” requests can still trip billing/quota. The quickest way to see which provider is returning 402 is:

openclaw status --all

#

Paste the redacted output; it usually includes enough context to identify the failing provider without leaking keys.

pliant grove Apr 5, 2026, 8:57 AM

#

can you help me switch the primary to kimi-coding ?

rose willowBOT Apr 5, 2026, 8:58 AM

#

Yep — for Kimi Coding, set the primary to the kimi provider model (not kimi-coding/... in the model ref):

openclaw models set kimi/kimi-code
openclaw models status

models set updates agents.defaults.model.primary.
If you only want a temporary switch in this chat/session, use:

/model kimi/kimi-code

If it errors with missing auth, set up Kimi Coding auth first (KIMI_API_KEY / KIMICODE_API_KEY), e.g.:

openclaw onboard --auth-choice kimi-code-api-key

#

Docs: https://docs.openclaw.ai/cli/models • https://docs.openclaw.ai/providers/moonshot

pliant grove Apr 5, 2026, 9:00 AM

#

i want this to be primary

openclaw models fallbacks add kimi-coding/k2p5

k2p5

rose willowBOT Apr 5, 2026, 9:00 AM

#

Got it — then use set, not fallbacks add.

openclaw models set kimi/k2p5
openclaw models status

That makes it the primary model.

If you want the canonical ref (same provider), this is equivalent and preferred going forward:

openclaw models set kimi/kimi-code

kimi-coding/k2p5 is the wrong prefix for model refs here — use kimi/....

pliant grove Apr 5, 2026, 9:00 AM

#

how do i restart after ?

rose willowBOT Apr 5, 2026, 9:00 AM

#

You can restart with:

openclaw gateway restart

Then verify it came back:

openclaw gateway status

(For model changes, restart is usually not required — config hot-reloads — but restarting is totally fine.)

pliant grove Apr 5, 2026, 9:02 AM

#

...New session started · model: kimi/k2p5

⚠️ Agent failed before reply: Unknown model: kimi/k2p5.
Logs: openclaw logs --follow

rose willowBOT Apr 5, 2026, 9:02 AM

#

Ah yep — that means your current install doesn’t recognize kimi/k2p5 on this version.

Quick fix path:

openclaw --version
openclaw models list

Then set the model using an exact ID from your list (depends on version/provider), usually one of:

openclaw models set kimi/kimi-code
# or (older installs)
openclaw models set kimi-coding/k2p5
# or Moonshot path

#

openclaw models set moonshot/kimi-k2.5

Then:

openclaw gateway restart
openclaw models status

If you paste your openclaw --version + the Kimi rows from openclaw models list, I’ll give you the exact one-liner.

pliant grove Apr 5, 2026, 9:03 AM

#

🦞 OpenClaw 2026.2.17 (4134875) — I'm not magic—I'm just extremely persistent with retries and coping strategies.

Model Input Ctx Local Auth Tags
kimi/k2p5 - - - - default,configured,missing
kimi-coding/k2p5 text+image 256k no yes fallback#1,configured,alias:Kimi K2.5
anthropic/claude-opus-4-5 text+image 195k no yes fallback#2,configured
anthropic/claude-opus-4-6 text+image 195k no yes configured,alias:opus
kimi/kimi-code - - - - configured,missing

rose willowBOT Apr 5, 2026, 9:03 AM

#

Perfect, that output confirms it.

On 2026.2.17, your working Kimi model is:

openclaw models set kimi-coding/k2p5
openclaw gateway restart
openclaw models status

You can also clean up the duplicate self-fallback (optional but nice):

openclaw models fallbacks remove kimi-coding/k2p5

kimi/k2p5 and kimi/kimi-code show missing on your version, so don’t use those as primary there.

pliant grove Apr 5, 2026, 9:04 AM

#

this should be our main model now

kimi-coding/k2p5 text+image 256k no yes fallback#1,configured,alias:Kimi K2.5

rose willowBOT Apr 5, 2026, 9:04 AM

#

Almost — fallback#1 means it is not primary yet.

Primary should show the default tag.

Run:

openclaw models set kimi-coding/k2p5
openclaw models status

If status still looks stale, do:

openclaw gateway restart
openclaw models status

#

You want to see kimi-coding/k2p5 tagged as default (not fallback#1).

pliant grove Apr 5, 2026, 9:06 AM

#

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : kimi-coding/k2p5
Fallbacks (2) : kimi-coding/k2p5, anthropic/claude-opus-4-5
Image model : -
Image fallbacks (0): -
Aliases (2) : opus -> anthropic/claude-opus-4-6, Kimi K2.5 -> kimi-coding/k2p5
Configured models (5): anthropic/claude-opus-4-5, anthropic/claude-opus-4-6, kimi-coding/k2p5, kimi/kimi-code, kimi/k2p5

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): anthropic (2)

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=2, api_key=0) | anthropic:claudestefan=token:sk-ant-o...CDDR5wAA, anthropic:default=token:sk-ant-o...EE2ltQAA
kimi-coding effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | kimi-coding:default=sk-kimi-...7ewtAayL

OAuth/token status

anthropic

rose willowBOT Apr 5, 2026, 9:06 AM

#

Nice — yep, this is correct now ✅

Default : kimi-coding/k2p5 means it’s your main model.

Only cleanup I’d do: remove the duplicate self-fallback (primary and fallback being the same is redundant):

openclaw models fallbacks remove kimi-coding/k2p5
openclaw models status

Then fallback will just be anthropic/claude-opus-4-5.

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for others.

pliant grove Apr 6, 2026, 9:32 AM

#

how can i update to the last version?

openclaw update --channel dev

this does not work

Update channel set to dev.
Updating OpenClaw...

Error: OPENCLAW_GIT_DIR points at a non-git directory: /root/.openclaw. Set OPENCLAW_GIT_DIR to an empty folder or an openclaw checkout.

rose willowBOT Apr 6, 2026, 9:33 AM

#

Yep, error is clear: OPENCLAW_GIT_DIR is set to /root/.openclaw (your state dir), but dev updates need a git checkout path.

Use one of these:

If you just want latest stable release

openclaw update --channel stable

If you want latest `dev` (main)

unset OPENCLAW_GIT_DIR
openclaw update --channel dev

Or explicitly set a proper repo path:

#

export OPENCLAW_GIT_DIR=~/openclaw
openclaw update --channel dev

Then verify:

openclaw update status
openclaw --version

If OPENCLAW_GIT_DIR keeps coming back, remove it from your env file (often ~/.openclaw/.env or shell profile).
Docs: https://docs.openclaw.ai/cli/update • https://docs.openclaw.ai/install/development-channels

pliant grove Apr 7, 2026, 9:37 AM

#

After the update open claw it's not responding

rose willowBOT Apr 7, 2026, 9:37 AM

#

Yep — after an update this is usually a gateway/service mismatch or auth drift.

Can you run these in order and paste outputs?

openclaw --version
openclaw status
openclaw gateway status
openclaw gateway restart
openclaw status --all

If it’s still not responding after restart:

openclaw doctor

#

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

And if replies still don’t come through, tail logs for 20–30s while sending a test message:

openclaw logs --follow

Post the output here and I’ll pinpoint the exact failure.

Refs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting

pliant grove Apr 7, 2026, 9:42 AM

#

🦞 OpenClaw 2026.4.5 (3e72c03) — I've read more man pages than any human should—so you don't have to.

Config invalid
File: ~/.openclaw/openclaw.json
Problem:

channels.telegram: channels.telegram.streamMode is legacy; use channels.telegram.streaming instead. Run "openclaw doctor --fix".
channels.telegram: channels.telegram.streamMode and boolean channels.telegram.streaming are legacy; use channels.telegram.streaming="off|partial|block".
channels.telegram: channels.telegram.streamMode and boolean channels.telegram.streaming are legacy; use channels.telegram.streaming="off|partial|block".
Legacy config keys detected:
channels.telegram: channels.telegram.streamMode is legacy; use channels.telegram.streaming instead. Run "openclaw doctor --fix".
channels.telegram: channels.telegram.streamMode and boolean channels.telegram.streaming are legacy; use channels.telegram.streaming="off|partial|block".
channels.telegram: channels.telegram.streamMode and boolean channels.telegram.streaming are legacy; use channels.telegram.streaming="off|partial|block".

Run: openclaw doctor --fix
[openclaw] Failed to start CLI: Error: Invalid config at /root/.openclaw/openclaw.json:

channels.telegram: channels.telegram.streamMode is legacy; use channels.telegram.streaming instead. Run "openclaw doctor --fix".
channels.telegram: channels.telegram.streamMode and boolean channels.telegram.streaming are legacy; use channels.telegram.streaming="off|partial|block".
channels.telegram: channels.telegram.streamMode and boolean channels.telegram.streaming are legacy; use channels.telegram.streaming="off|partial|block".
at Object.loadConfig (file:///usr/lib/node_modules/openclaw/dist/io-CS2J_l4V.js:18841:35)
at loadConfig (file:///usr/lib/node_modules/openclaw/dist/io-CS2J_l4V.js:19305:34)

rose willowBOT Apr 7, 2026, 9:43 AM

#

Perfect, that error is clear — your config has legacy Telegram streaming keys, and this version hard-fails on them.

Fix (manual, since CLI won’t boot)

Backup config:

cp /root/.openclaw/openclaw.json /root/.openclaw/openclaw.json.bak

Edit:

nano /root/.openclaw/openclaw.json

In every Telegram section (channels.telegram and any channels.telegram.accounts.*):

remove streamMode
replace boolean streaming with enum string:

#

streaming: true → streaming: "partial"
streaming: false → streaming: "off"
if you had streamMode: "block", set streaming: "block"

✅ Keep only:

streaming: "off" | "partial" | "block"

Save, then restart:

openclaw gateway restart
openclaw status

#

If you want, paste the channels.telegram part here and I’ll give you the exact corrected block.
Docs: https://docs.openclaw.ai/channels/telegram and https://docs.openclaw.ai/gateway/configuration-reference#telegram

pliant grove Apr 7, 2026, 9:47 AM

#

"channels": {
"telegram": {
"enabled": true,
"dmPolicy": "pairing",
"botToken":
"groupPolicy": "allowlist",
"streamMode": "off"

"tailscale": {
  "mode": "off",
  "resetOnExit": false
}

},
"skills": {
"install": {
"nodeManager": "npm"
}
},
"plugins": {
"entries": {
"telegram": {
"enabled": true

rose willowBOT Apr 7, 2026, 9:47 AM

#

Yep — this confirms it. Two issues in that block:

streamMode is legacy → must be streaming
Your pasted block is structurally broken (missing closing } / comma after telegram)

Use this shape:

"channels": {
"telegram": {
"enabled": true,
"dmPolicy": "pairing",
"botToken": "YOUR_TELEGRAM_BOT_TOKEN",
"groupPolicy": "allowlist",
"streaming": "off"
}

#

},
"tailscale": {
"mode": "off",
"resetOnExit": false
},
"skills": {
"install": {
"nodeManager": "npm"
}
},
"plugins": {
"entries": {
"telegram": {
"enabled": true
}

#

}
}

If you redacted botToken here, all good — just make sure in the real file it has a valid string value.

Then run:

openclaw status
openclaw doctor --fix
openclaw gateway restart

If it still errors, paste the next error line and I’ll patch it fast.

pliant grove Apr 7, 2026, 9:50 AM

#

"channels": {
"telegram": {
"enabled": true,
"dmPolicy": "pairing",
"botToken":
"groupPolicy": "allowlist",
"streaming": "off"

this ok? how do i save and restart ?

rose willowBOT Apr 7, 2026, 9:50 AM

#

Yes, that key/value is correct ("streaming": "off"), but two important things:

Your Telegram bot token is exposed in this thread → delete that message and rotate the token in BotFather (/revoke then new token).
Make sure the JSON block is fully closed (} and commas in the right places).

For nano:

Save file: Ctrl+O, press Enter
Exit: Ctrl+X

Then restart + verify:

openclaw gateway restart
openclaw status
openclaw gateway status

#Kimi k2p5 code

1) First: what exact error + command?

2) If you meant Kimi Coding K2.5 (the “code k2.5” one)

3) If you meant Moonshot Kimi K2.5 (Open Platform)

4) Setting up fallback (Opus → Kimi Coding)

1) Auth setup (recommended)

Anthropic (Claude subscription → setup-token)

Kimi Code (Kimi Coding)

2) Config shape (JSON5 snippet)

Important gotcha

Make Opus 4.6 primary + Kimi Coding fallback

Option A (easy CLI)

Option B (what it should look like in config)

About [disabled:billing 3h] on Kimi

1) Re-probe Kimi Coding with a bigger timeout

2) Make sure you actually have fallbacks configured

3) If Kimi Coding keeps timing out in real usage

1) Set primary + fallbacks (CLI)

2) Remove Moonshot from config (if you ever added it)

3) (Optional) Remove Moonshot credentials so it disappears from models status

4) Verify

A) Remove Moonshot from the auth profile store (most common)

B) Also remove it from config/env (so it can’t come back)

C) Verify where it’s still coming from

1) First confirm which provider is billing-failing

2) Most likely: it’s your Kimi Coding key

3) Make sure your fallback chain is actually set (so you still get replies)

1) Make sure your fallback chain is exactly what you want

2) Reset the session (important: sessions pin model/profile choices)

3) Confirm the Discord thread is using the same agent you’re configuring

4) If billing error persists even with fallbacks set

If you just want latest stable release

If you want latest dev (main)

Fix (manual, since CLI won’t boot)

About `[disabled:billing 3h]` on Kimi

3) (Optional) Remove Moonshot credentials so it disappears from `models status`

If you want latest `dev` (main)