#Message ordering conflict - please try again. If this persists, use /new to start a fresh session.

1 messages · Page 1 of 1 (latest)

lavish comet
#

After the reset update getting this error

brave treeBOT
#

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

acoustic lodgeBOT
#

Can you paste the exact error text (or a screenshot) and where you see it (CLI vs dashboard vs logs)? “After the reset update” can mean a few different things, so the exact message matters.

In the meantime, please run these and paste the output (feel free to redact tokens/URLs):

openclaw --version
openclaw status --all
openclaw gateway status
openclaw doctor
openclaw channels status --probe

And if it’s crashing/looping, grab the log lines around the failure:

openclaw logs --follow
lavish comet
#

Message ordering conflict - please try again. If this persists, use /new to start a fresh session.

acoustic lodgeBOT
#

That message is OpenClaw papering over a model/provider 400 that usually looks like “roles must alternate” / “incorrect role information”. In other words: the LLM endpoint rejected the conversation history format, so OpenClaw tells you to reset the session.

What to do:

  1. In the Discord chat where it happens, send /new as a standalone message (exactly /new, nothing else), then try your prompt again.
    (/reset works too.)

  2. If it keeps happening even immediately after /new, paste:

openclaw --version
openclaw models status
openclaw logs --follow

…and grab the exact log line with the 400 (the one mentioning roles/incorrect role info).

Common cause when it persists: you’re using an OpenAI-compatible/local endpoint that doesn’t fully support tool/function message formats, so it errors on the message roles. The models status + the raw 400 in logs will confirm that fast.

lavish comet
#

it keeps saying: Message ordering conflict - please try again. If this persists, use /new to start a fresh session.

#

i did /new and keeps saying this

acoustic lodgeBOT
#

If it happens even right after /new, it’s almost never “Discord message ordering” — it’s the LLM provider rejecting the request (usually a 400 like “roles must alternate” / “incorrect role information”). OpenClaw turns that into this friendly error, but the underlying issue is in the model/provider call.

To diagnose in one shot:

  1. Restart the gateway (post-update this matters):
openclaw gateway restart
  1. Reproduce the error once, then paste these (redact any tokens/URLs):
openclaw --version
openclaw models status
openclaw logs --limit 200 --plain

The logs output will show the real upstream error + which provider/model is throwing it. If you tell me what provider/model you’re on (from models status), I can point to the most likely fix (often: switch to a provider/model that properly supports tool/function-style chat payloads; some “OpenAI-compatible” endpoints break here).

#

If /new still immediately triggers the same error, that means the session reset worked — but the model/provider call is failing every time, so OpenClaw can’t even do the “fresh hello” turn.

This message is almost always hiding an upstream 400 like “roles must alternate” / “incorrect role information” coming from an OpenAI-compatible endpoint that doesn’t support OpenClaw’s tool/chat message format.

Please do this (and paste outputs; redact tokens/URLs):

  1. Restart after the update:
openclaw gateway restart
  1. Then run:
openclaw --version
openclaw models status
openclaw logs --limit 200 --plain
#

In the logs, I’m looking for the actual provider error line (often includes 400 + “role” wording) and which provider/model it’s using.

Quick sanity test while we wait for logs:

  • Try switching temporarily to a tool-reliable provider (cloud) just to confirm it’s a provider-compat issue. If that fixes it, your current endpoint is the culprit (common with some local/OpenAI-compatible servers). If you want, ask in #models for what people are currently using successfully: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes
lavish comet
#

dont see any (often includes 400 + “role” wording)

#

in the logs

#

just get message order conflict everytime

acoustic lodgeBOT
#

If you’re seeing that reply in Discord but can’t find any matching “roles must alternate / incorrect role” in logs, 99% of the time it’s because you’re looking at the wrong gateway logs (profile mismatch, remote gateway, or you have 2 gateways running and Discord is connected to the other one).

Do this in order:

  1. Find which gateway your CLI is talking to (and whether there are multiple):
openclaw gateway probe
openclaw gateway status --deep

If gateway probe shows more than one reachable gateway, paste that output (redact URLs/tokens). We need to make sure Discord + openclaw logs are looking at the same instance.

  1. Tail logs live, then reproduce once (send just “hi”)
openclaw logs --follow --plain

While that’s running, send one message in Discord and wait. Then copy/paste the new log lines that appear (even if they don’t mention “role” — paste whatever error shows up).

#
  1. Also paste:
openclaw --version
openclaw models status

If you truly can’t use the CLI, open the Control UI → Logs tab (the URL is shown in openclaw gateway status) and copy the error from there.

Docs for where logs live / how to view them: https://docs.openclaw.ai/logging

#

Nice — paste the exact log lines around it.

Specifically, copy ~20 lines before and after the first error that appears when you trigger it (send “hi” in Discord), so we can see:

  • which provider/model was called
  • the real upstream error text (HTTP status + message)

If you want a quick way to extract just the relevant bits, run one of these and paste the output:

openclaw logs --limit 300 --plain | grep -i -E "role|alternate|incorrect|400|bad request|provider|model|error"

or (if you already have the live tail running) just paste what shows up right after you send a message.

Also include:

# 
openclaw --version
openclaw models status

Once I see the exact upstream error line, I can tell you whether this is:

  • an OpenAI-compatible endpoint that doesn’t support tool/function chat roles (common), or
  • a gateway/profile mismatch, or
  • something else entirely.
#

If every message immediately turns into “Message ordering conflict…”, that’s not a “try /new again” situation — it means the gateway is consistently failing the model call, and Discord is only showing you the sanitized fallback.

The reason you don’t “see the 400/role wording” is usually one of these:

  1. you’re tailing logs from the wrong gateway instance/profile, or
  2. you’re not capturing the log line that contains the real upstream error.

1) First: confirm you’re looking at the right gateway

Run and paste:

openclaw gateway probe
openclaw gateway status --deep

If you see more than one gateway reachable, Discord might be connected to a different one than the CLI is logging.

#

2) Then: capture the exact failing line

Run:

openclaw logs --limit 500 --plain

…and paste the chunk that appears right after you send a message in Discord (doesn’t have to include “role” — paste whatever error line(s) show up).

3) Also paste model/provider + version (this usually reveals the culprit)

openclaw --version
openclaw models status

Once I see (a) which gateway you’re on and (b) which provider/model is active, I can tell you the fix. Most often it’s an OpenAI-compatible/local endpoint that doesn’t support OpenClaw’s tool/chat message format, but we should confirm from logs before guessing.

lavish comet
#

on logs i see

-4f3b-8ec3-42523d6929b2 durationMs=735 aborted=false
2026-02-14T08:43:08.773Z debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=744 active=0 queued=0
2026-02-14T08:43:08.775Z debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:slack-opus:main🧵1770968039.730799 durationMs=750 active=0 queued=0
2026-02-14T08:43:10.250Z info gateway/channels/slack {"subsystem":"gateway/channels/slack"} delivered reply to user:U094BTPTCET

then the bot replies Message ordering conflict - please try again. If this persists, use /new to start a fresh session.

acoustic lodgeBOT
#

Those lines you pasted are just the “task finished” + “Slack delivered reply” lines. They don’t include the actual failure that caused OpenClaw to generate the “Message ordering conflict…” text.

Also: your snippet is clearly from Slack (gateway/channels/slack, user:U…, lane session:agent:slack-opus:…). So we should debug the Slack→model run, not Discord.

Grab the real error (it will be a few lines before “delivered reply”)

Please run one of these and paste the output:

Option A (easiest): show more log history around the event

openclaw logs --limit 2000 --plain

Then copy/paste the block around the timestamp (a bit before 08:43:08).

Option B (more targeted): filter for the hidden “role_ordering” / upstream error

openclaw logs --limit 2000 --json | grep -i -E "role_ordering|roles must alternate|incorrect role|400|bad request|openrouter|anthropic|openai|model"
#

Also paste these (they usually make the root cause obvious)

openclaw --version
openclaw models status

What I’m looking for is the upstream provider error line (HTTP 400 etc) and which provider/model the slack-opus agent is actually using. Once you paste that, I can tell you the concrete fix (most commonly: the configured endpoint is “OpenAI-compatible” but rejects tool/chat role sequences).

lavish comet
#

2026.2.13

🦞 OpenClaw 2026.2.13 (9475791)
Your task has been queued; your dignity has been deprecated.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : kimi-coding/kimi-for-coding
Fallbacks (2) : moonshot/kimi-k2.5, anthropic/claude-opus-4-6
Image model : -
Image fallbacks (0): -
Aliases (3) : Kimi Code -> kimi-coding/kimi-for-coding, Kimi 2.5 -> moonshot/kimi-k2.5, 4.6 -> anthropic/claude-opus-4-6
Configured models (3): kimi-coding/kimi-for-coding, moonshot/kimi-k2.5, anthropic/claude-opus-4-6

#

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (4): anthropic (1), google (1), moonshot (1), openai-codex (1)

  • anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | anthropic:default=token:sk-ant-o...ed3ScQAA
  • google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | google:manual=token:AIzaSyAF...bN48R100
  • kimi-code effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | kimi-code:default=sk-kimi-...uUqowFnt | models.json=sk-kimi-...aef9tNYw | source=models.json: ~/.openclaw/agents/main/agent/models.json
  • kimi-coding effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | kimi-code:default=sk-kimi-...uUqowFnt | models.json=sk-kimi-...aef9tNYw | source=models.json: ~/.openclaw/agents/main/agent/models.json
  • moonshot effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=1, api_key=1) | moonshot:manual=token:# Option...provider [cooldown 40m], moonshot:default=sk-ghxFM...ogxSQBRY | env=sk-kimi-...aef9tNYw | source=env: MOONSHOT_API_KEY | models.json=sk-kimi-...aef9tNYw | source=models.json: ~/.openclaw/agents/main/agent/models.json
#
  • openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:default=OAuth

OAuth/token status

  • anthropic
    • anthropic:default static
  • google
    • google:manual static
  • moonshot
    • moonshot:manual static
  • openai-codex usage: 168h 100% left ⏱6d 23h
acoustic lodgeBOT
#

Yep — that models status output is the smoking gun.

You’re currently running with:

  • Default: kimi-coding/kimi-for-coding

…and OpenClaw’s “Message ordering conflict…” is almost always the upstream model complaining about chat message role structure (tool messages / system messages etc). Some OpenAI-compatible endpoints (and a few specific models) are strict/broken here and will fail every single turn, so /new can’t recover.

Quick fix (recommended): switch your primary model to Opus

Since you already have Opus 4.6 configured as a fallback, make it the primary:

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

Then try again in chat (and /new once just to be safe).

#

If you don’t have Anthropic credentials

Try switching the primary to your other fallback instead:

openclaw models set moonshot/kimi-k2.5
openclaw gateway restart

One more important check (because your logs showed Slack agent slack-opus)

If the problem is happening in Slack and you have a dedicated agent, run:

openclaw models status --agent slack-opus

Paste that output too — it’ll tell us which model that agent is actually using (it might still be pinned to the Kimi coding model, even if you change the main agent).

#

If switching the primary model fixes it, we’ve confirmed it’s a model/provider compatibility issue, not your session history.

#

That auth output is actually good news: you do have a working Anthropic token (anthropic:default=token:sk-ant-...).

Right now your Default model is:

  • kimi-coding/kimi-for-coding

…and that’s the kind of provider/model combo that can throw the “roles must alternate / incorrect role info” class of errors (OpenClaw surfaces it as Message ordering conflict…) on every single turn.

Fix: switch your default model away from Kimi (to Opus 4.6)

Run:

openclaw models set anthropic/claude-opus-4-6
openclaw gateway restart
openclaw models status
#

(or since you already have an alias, you can do openclaw models set 4.6)

Then in chat do:

  1. /new (standalone)
  2. send a simple “hi”

One important clarification

Earlier your log snippet showed Slack delivery (gateway/channels/slack). Are you seeing the error in Slack, Discord, or both?

  • If it’s Slack only and you’re using a separate agent (you had agent:slack-opus in the log), paste:
    openclaw models status --agent slack-opus
    because that agent might still be pinned to the Kimi coding model even if you change the main default.

If after switching to anthropic/claude-opus-4-6 it stops, we’ve confirmed the root cause is the Kimi model/provider rejecting the message format.

lavish comet
#

i switched models then ran /new it says:

New session started · model: anthropic/claude-opus-4-6 (default: moonshot/kimi-k2.5)
[1:59 PM]Message ordering conflict - please try again. If this persists, use /new to start a fresh session.

acoustic lodgeBOT
#

That /new line is telling us something important:

model: anthropic/claude-opus-4-6 (default: moonshot/kimi-k2.5)

So you started the session on Opus, but your global default is still Kimi. If Opus errors even briefly (auth/rate limit/network), OpenClaw can fall back and you’re right back in “message ordering conflict” land.

Let’s isolate it cleanly:

1) Verify Anthropic actually works (live probe)

openclaw models status --probe-provider anthropic --plain

If this fails, paste the output.

2) Make Opus the real default + temporarily remove fallbacks (debug)

# 
openclaw models set anthropic/claude-opus-4-6
openclaw models fallbacks clear
openclaw gateway restart

3) Stop anything in-flight, then test with ONE message

In chat:

  1. send /stop (standalone)
  2. send /new (standalone)
  3. send hi and wait (don’t send multiple messages quickly)

4) If it still happens: we need the exact error line from logs

Run:

openclaw logs --follow --plain
#

Then reproduce once and paste the first error block that appears (20–50 lines around it).

Once we have either (a) the probe result or (b) the actual error line, we can tell whether this is Anthropic auth/connectivity vs a session/message-format bug vs a fallback still being used.

ocean badge
lavish comet
#

I think it was your post iirc

acoustic lodgeBOT
#

Yep — I found your other thread fix, and it matches the “Kimi K2.5 thinking” failure mode.

When Kimi “thinking/reasoning” is enabled, OpenClaw’s OpenAI-compat layer can start emitting a developer role message; Moonshot/Kimi rejects that role, and OpenClaw surfaces it as “Message ordering conflict…”.

Fix (recommended): tell OpenClaw not to use the developer role for Moonshot/Kimi

  1. (Optional but smart) backup your config first.
  2. Set compat flag + restart:
openclaw config set models.providers.moonshot.models[0].compat '{"supportsDeveloperRole": false}' --json
openclaw gateway restart

Then try /new again.

Alternative (more blunt): disable reasoning for that model

# 
openclaw config set models.providers.moonshot.models[0].reasoning false --json
openclaw gateway restart

If your Moonshot model isn’t at index [0], paste:

openclaw config get models.providers.moonshot.models

and I’ll point to the exact path to edit.

#

Nice — glad you got it fixed.

Do you remember which change actually did it (so we can make the thread useful for the next person)? e.g.

  • switching default away from Kimi, or
  • setting compat.supportsDeveloperRole=false on the Moonshot/Kimi model, or
  • disabling reasoning/thinking.

Also: if this is solved now, please right-click the message that fixed it → Apps → ✅ Mark Solution so Answer Overflow can index it.

small pawn
#

Hi group, can someone help we out pls - I've installed OpenClaw on DGX Spark with TRT LLM with nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4. when I ask general questions it answers, but when I ask to check some of the files in the system it shows constantly this ERROR:
"run error: Message ordering conflict - please try again. If this persists, use /new to start a fresh session. "

I have tried new sessions. from time to time it manages to read one file, but then it shows the same error again.

the log files look like this:
"HTTP 400: "[{'type': 'string_type', 'loc': ('body', 'messages', 8, 'ChatCompletionDeveloperMessageParam', 'content', 'str'), 'msg': 'Input should be a valid

string', 'input': None}, {'type': 'iterable_type', 'loc': ('body', 'messages', 8, 'ChatCompletionDeveloperMessageParam', 'content',

'generator[ChatCompletionContentPartTextParam]'), 'msg': 'Input should be iterable', 'input': None}, {'type': 'literal_error', 'loc': ('body', 'messages', 8,

'ChatCompletionDeveloperMessageParam', 'role'), 'msg': "Input should be 'developer'", 'input': 'assistant', 'ctx': {'expected': "'developer'"}}, {'type':

'extra_forbidden', 'loc': ('body', 'messages', 8, 'ChatCompletionDeveloperMessageParam', 'reasoning_content'), 'msg': 'Extra inputs are not permitted', 'input':

Any ideas how to solve it? I would really appriciate some help! Thank you in advance!

                                          "
#

@acoustic lodge could you pls have a look?

small pawn
#

I fixed it, tx anyway..