Can i add another token in one model | Friends of the Crustacean 🦞🤝 | Page 1

opal birch Apr 18, 2026, 2:15 PM

#

Im using kimi model for my openclaw but somethimes my token hit rate limit. can i configure another token on kimi for fallback

proud jasperBOT Apr 18, 2026, 2:15 PM

#

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

silver salmonBOT Apr 18, 2026, 2:15 PM

#

dark palmBOT Apr 18, 2026, 2:16 PM

#

Let me verify this against the docs so I don’t make up config keys.

#

Yes, on current builds OpenClaw can do this.

There are 2 separate layers:

Auth profile rotation within the same provider
If you add multiple Kimi/Moonshot credentials, OpenClaw can try the next one when it hits rate limits/timeouts.
Model fallback
If the provider still fails, it can move to the next model in agents.defaults.model.fallbacks.

A couple of important gotchas:

Moonshot Kimi and Kimi Coding are different providers.
- moonshot/kimi-k2.5 → provider is moonshot
- kimi/kimi-code → provider is kimi
Same-provider key rotation is mainly for rate limit style failures, not every error.
Sessions are sticky, so it won’t round-robin every single request.

#

Useful commands:

openclaw --version
openclaw models status
openclaw models auth add

If you want to set explicit order after adding a second key:

openclaw models auth order get --provider moonshot
openclaw models auth order set --provider moonshot moonshot:default moonshot:backup

Or if you’re on Kimi Coding instead:

#

openclaw models auth order set --provider kimi kimi:default kimi:backup

Docs:

If you paste:

your openclaw --version
the exact model ref you use (moonshot/... or kimi/...)

…I can tell you the exact provider/order command to use.

opal birch Apr 18, 2026, 2:31 PM

#

one model provider and two different api keys

dark palmBOT Apr 18, 2026, 2:31 PM

#

Yep, that’s the exact use case.

One provider + two API keys = configure two auth profiles for the same provider.
Then OpenClaw can cool down key A on rate limits and try key B.

Example for Moonshot Kimi (moonshot/... models):

openclaw models auth paste-token --provider moonshot --profile-id moonshot:primary
openclaw models auth paste-token --provider moonshot --profile-id moonshot:backup

openclaw models auth order set --provider moonshot moonshot:primary moonshot:backup
openclaw models status --probe

If your model ref is kimi/... instead, use --provider kimi and profile ids like kimi:primary.

#

One important gotcha: if you pin a session to a specific profile with /model ...@profileId, it stays locked there, so don’t do that if you want automatic rotation.

Docs:

If you want, paste your exact model ref and I’ll give you the exact commands for your setup.

opal birch Apr 18, 2026, 2:33 PM

#

give me example of kimi-code

dark palmBOT Apr 18, 2026, 2:34 PM

#

Sure, for kimi/kimi-code it would look like this.

Set `kimi-code` as the model

{
  agents: {
    defaults: {
      model: {
        primary: "kimi/kimi-code",
      },
      models: {
        "kimi/kimi-code": { alias: "Kimi Code" },
      },
    },
  },

#

Add two API keys for the same `kimi` provider

openclaw models auth paste-token --provider kimi --profile-id kimi:primary
openclaw models auth paste-token --provider kimi --profile-id kimi:backup

Then set the order:

openclaw models auth order set --provider kimi kimi:primary kimi:backup

#

Check it:

openclaw models status --probe

Optional: add a model fallback too

If both Kimi keys fail, you can also fall back to another model:

{
  agents: {
    defaults: {
      model: {
        primary: "kimi/kimi-code",

#

        fallbacks: ["openai/gpt-5.4-mini"],
      },
    },
  },
}

Important

Don’t try to store two KIMI_API_KEY env vars.
For multiple keys, use multiple auth profiles like kimi:primary and kimi:backup.

Docs:

If you want, I can also give you a full JSON5 config example for kimi/kimi-code + backup key.

opal birch Apr 18, 2026, 2:57 PM

#

i want to add auth with token not paste i just want to pass token into command

dark palmBOT Apr 18, 2026, 2:59 PM

#

Let me check the exact CLI shape here, because I don’t want to guess and hand you a fake flag.

#

Got it. Short answer: not for models auth paste-token.

I checked the CLI docs, and models auth paste-token supports:

--provider
--profile-id
--expires-in

It does not have a documented --token <value> flag, it prompts for the token.

What does support inline token flags

For kimi-code onboarding:

openclaw onboard --non-interactive \

#

  --auth-choice kimi-code-api-key \
  --kimi-code-api-key "$KIMI_API_KEY" \
  --accept-risk

For Moonshot Kimi:

openclaw onboard --non-interactive \
  --auth-choice moonshot-api-key \
  --moonshot-api-key "$MOONSHOT_API_KEY" \
  --accept-risk

Important limitation

#

That inline-token onboard path is good for setting up auth, but for multiple named keys on the same provider I do not see a documented CLI like:

openclaw models auth ... --token ...

So today, if you want:

kimi:primary
kimi:backup

…the supported CLI path still looks like:

openclaw models auth paste-token --provider kimi --profile-id kimi:primary
openclaw models auth paste-token --provider kimi --profile-id kimi:backup

#

and it will prompt for each token.

Docs:

If you want, I can show you the least-annoying workflow for adding 2 kimi-code keys with minimal typing.

opal birch Apr 19, 2026, 7:12 AM

#

openclaw models auth order set --provider kimi kimi:default kimi:backup this order is default first and backup second right?

dark palmBOT Apr 19, 2026, 7:13 AM

#

Yep, exactly.

openclaw models auth order set --provider kimi kimi:default kimi:backup

means:

try kimi:default first
if that profile is rate-limited / cooling down / unavailable, try kimi:backup

One small nuance: OpenClaw is session-sticky, so if kimi:default is working it tends to stay on that profile for the session instead of bouncing back and forth every request.

You can verify with:

#

openclaw models auth order get --provider kimi
openclaw models status --probe

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

opal birch Apr 21, 2026, 4:12 AM

#

Agent: main
Provider: kimi
Auth state file: ~/.openclaw/agents/main/agent/auth-state.json
Order override: kimi:default, kimi:backup this is first work from default right?

dark palmBOT Apr 21, 2026, 4:12 AM

#

Yes, that means kimi:default is first for agent main.

So the preference order is:

kimi:default
kimi:backup

Only a couple caveats:

if kimi:default is in cooldown / rate-limited / disabled, OpenClaw can skip to kimi:backup
if the session was manually pinned to another profile, that can override the normal order

But in the normal case, yep, it starts with kimi:default.

opal birch Apr 21, 2026, 4:14 AM

#

default is not rate limited backup is rate limited but my agents answer me rate limited

dark palmBOT Apr 21, 2026, 4:15 AM

#

Then it’s probably not just the order setting.

If kimi:default is healthy but you still get rate-limited, the usual causes are:

the current session is still pinned/sticky to kimi:backup
kimi:default is marked unusable/cooling down in auth state
Kimi is returning an error that OpenClaw is not classifying as failover-worthy, so it doesn’t hop to the other profile

Can you check these?

openclaw --version
openclaw models auth order get --provider kimi
openclaw models status --probe --probe-provider kimi
openclaw models status --json

#

Also try a fresh session once (/new), because session stickiness can keep using the previously selected profile.

If you paste these 3 things, I can narrow it down fast:

openclaw --version
the exact rate-limit error text
the auth.unusableProfiles part from openclaw models status --json

If kimi:default probes fine and OpenClaw still refuses to switch, I’d start suspecting a Kimi-specific failover bug.

opal birch Apr 21, 2026, 4:16 AM

#

what is --prove used for

dark palmBOT Apr 21, 2026, 4:16 AM

#

You want --probe, not --prove 🙂

openclaw models status --probe does a live check against your configured provider auth, instead of only showing what’s saved locally.

So it helps answer things like:

is kimi:default actually usable right now?
is kimi:backup rate-limited / auth-broken / expired?
which profile is failing?

Example:

openclaw models status --probe --probe-provider kimi

A couple caveats:

#

it makes real provider requests
it may consume tokens
it can trigger rate limits

So it’s great for debugging, just not something to spam.

If you want, I can show you how to read the --probe output for kimi:default vs kimi:backup.

opal birch Apr 21, 2026, 4:17 AM

#

OAuth/token status

none

Auth probes
┌──────────────────┬────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├──────────────────┼────────────────────────┼────────────┤
│ kimi/kimi-code │ kimi:backup (api_key) │ ok · 15.5s │
│ kimi/kimi-code │ kimi:default (api_key) │ ok · 26.2s │

dark palmBOT Apr 21, 2026, 4:18 AM

#

That output is actually good.

It means both auth profiles are currently usable:

kimi:backup → ok
kimi:default → ok

So this doesn’t look like missing/broken auth.

Also, OAuth/token status: none is not the problem here, that’s normal when the provider doesn’t expose extra usage-window info there.

What this tells me is the issue is more likely one of these:

session stickiness, the chat is still preferring a previously selected profile
the exact Kimi error during a real run is not being classified as failover-worthy
the probe succeeds, but the real request later hits a different runtime limit

#

Best next test

In a fresh session (/new), try forcing each profile once:

/model kimi/kimi-code@kimi:default

then test, and separately:

/model kimi/kimi-code@kimi:backup

If default works when pinned, but normal auto-routing still gives rate limit, that points pretty strongly to failover/session-routing behavior, not the keys themselves.

Also paste:

#Can i add another token in one model

Set kimi-code as the model

Add two API keys for the same kimi provider

Optional: add a model fallback too

Important

What does support inline token flags

Important limitation

Best next test

Set `kimi-code` as the model

Add two API keys for the same `kimi` provider