#22194: fix(agent) Moonshot/Kimi kimi-k2.5 returns ROLE_UNSPECIFIED
agents
size: XS
Cluster:
Moonshot Provider Enhancements
## Summary
See issue #21060
https://github.com/openclaw/openclaw/issues/21060
Problem:
- Moonshot AI (Kimi) API returns 400 error with "ROLE_UNSPECIFIED" when OpenClaw sends messages with "role": "developer".
- The error occurs because Moonshot's API only accepts "system", "user", or "assistant" roles, but OpenClaw was sending "developer" role for OpenAI-compatible models.
Why it matters:
- Users cannot interact with Moonshot AI models through OpenClaw
- The error breaks the user experience and prevents access to Moonshot's capabilities
- Moonshot AI is a popular provider in the OpenClaw ecosystem, so this affects many users
What changed:
- Added Moonshot AI detection in normalizeModelCompat() function in /src/agents/model-compat.ts
- Moonshot models now get supportsDeveloperRole: false setting, which tells the pi-ai SDK to convert "developer" role messages to "system" before sending to the API
- Added test coverage for Moonshot role mapping in /src/agents/model-compat.e2e.test.ts
What did NOT change (scope boundary):
- No changes to existing z.ai model handling - it continues to work exactly as before
- No changes to OpenAI, Anthropic, or other providers - they are unaffected
- No changes to the core messaging logic - only the role mapping compatibility layer
- No changes to API endpoints, authentication, or core provider configuration
The fix only affects Moonshot models using the OpenAI completions API
The fix follows the existing pattern used for z.ai models and ensures Moonshot AI receives compatible role values while maintaining backward compatibility for all other providers.
## Change Type (select all)
- [x] Bug fix
- [ ] Feature
- [ ] Refactor
- [ ] Docs
- [ ] Security hardening
- [ ] Chore/infra
## Scope (select all touched areas)
- [x] Gateway / orchestration
- [ ] Skills / tool execution
- [ ] Auth / tokens
- [ ] Memory / storage
- [ ] Integrations
- [ ] API / contracts
- [ ] UI / DX
- [ ] CI/CD / infra
## Linked Issue/PR
- Closes #21060
- Related #
## User-visible / Behavior Changes
- Users can now successfully use Moonshot AI (Kimi) models without encountering 400 errors
- Fixed a bug where Moonshot models would fail with a ROLE_UNSPECIFIED error; system instructions are now correctly handled by the API
- No configuration changes are required for existing Moonshot setups
## Security Impact (required)
- New permissions/capabilities? (`No`)
- Secrets/tokens handling changed? (`No`)
- New/changed network calls? (`No`)
- Command/tool execution surface changed? (`No`)
- Data access scope changed? (`No`)
- If any `Yes`, explain risk + mitigation:
## Repro + Verification
### Environment
- OS: Ubuntu 24.04.4
- Runtime/container: Docker version 29.2.1, build a5c7197
- Model/provider: Moonshot
### Steps
1. Configure Moonshot API
2. Talk to chatbot
### Expected
- Normal response
### Actual
- Message ordering conflict - please try again. If this persists, use /new to start a fresh session.
## Evidence
Attach at least one:
- [x] issue #21060
## Human Verification (required)
What you personally verified (not just CI), and how:
- Verified scenarios: reproduce in my env. Then fix it.
- Edge cases checked: Try different model and all work.
## Compatibility / Migration
- Backward compatible? (`Yes`)
- Config/env changes? (`No`)
- Migration needed? (`No`)
-
## Failure Recovery (if this breaks)
- How to disable/revert this change quickly: Revert the change
- Files/config to restore: No
- Known bad symptoms reviewers should watch for: No
## Risks and Mitigations
List only real risks for this PR. Add/remove entries as needed. If none, write `None`.
- Risk: None
- Mitigation: None
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
This PR fixes a bug where Moonshot AI (Kimi) API returns 400 error with `ROLE_UNSPECIFIED` when OpenClaw sends messages with `role: "developer"`. The fix adds Moonshot detection to `normalizeModelCompat()` function, setting `supportsDeveloperRole: false` for Moonshot models. This causes the pi-ai SDK to convert `"developer"` role messages to `"system"` before sending to the API.
The implementation follows the exact same pattern previously used for z.ai models and includes matching test coverage. The fix is minimal, well-scoped, and backward compatible with all other providers.
<h3>Confidence Score: 5/5</h3>
- This PR is safe to merge with minimal risk
- The change follows an established pattern (z.ai fix), is minimal and well-tested, and only affects Moonshot models. The implementation is straightforward and the test coverage mirrors the existing z.ai tests.
- No files require special attention
<sub>Last reviewed commit: e9d633a</sub>
<!-- greptile_other_comments_section -->
<sub>(2/5) Greptile learns from your feedback when you react with thumbs up/down!</sub>
<!-- /greptile_comment -->
Most Similar PRs
#14187: fix: add Moonshot AI to non-standard provider detection
by shad0wca7 · 2026-02-11
90.7%
#19281: fix: set supportsDeveloperRole false as default for moonshot provider
by MisterGuy420 · 2026-02-17
87.9%
#21911: Enable `reasoning: true` for Kimi models
by ighostych · 2026-02-20
86.9%
#5947: Feature/kimi reasoning support
by zzjj7000 · 2026-02-01
78.1%
#9024: Fix/Moonshot Provider Issue with kimi-k2-thinking Model Role Mappin...
by fotorpics · 2026-02-04
77.8%
#6454: fix: enable reasoning flag for Kimi K2.5 in Moonshot provider (#6451)
by coupclawbot · 2026-02-01
77.6%
#6015: CLI: clarify Moonshot AI/Kimi auth option labels based on user feed...
by xxr3376 · 2026-02-01
77.3%
#4459: fix: enable image input for Kimi K2.5 and refresh stale config mode...
by manikv12 · 2026-01-30
77.3%
#19451: fix(errors): surface provider hint for role-ordering failures
by rafaelipuente · 2026-02-17
77.1%
#21088: fix: sessions_sspawn model override ignored for sub-agents
by Slats24 · 2026-02-19
76.0%