Fixing Cerebras 422 Error: Payload Filter Configuration in CliproxyAPI and OpenClaw

The Problem

When using Cerebras models (e.g., cerebras/gpt-120b) through CliproxyAPI, you might encounter a 422 Unprocessable Entity error:

{
  "message": "body.store: property 'body.store' is unsupported",
  "type": "invalid_request_error",
  "param": "validation_error",
  "code": "wrong_api_format"
}

This happens because Cerebras strictly validates incoming payloads and rejects any fields it doesn’t recognize — in this case, the store parameter that OpenClaw automatically includes for conversation storage.

Root Cause

CliproxyAPI, acting as a unified gateway for multiple LLM providers, includes standard OpenAI-compatible fields like store in every request. While most providers ignore unknown fields, Cerebras is strict and returns 422 for any unsupported parameter.

The Solution: Payload Filter + Prefix + Model Aliases

CliproxyAPI provides several configuration features that work together:

1. Payload Filter — Strip unsupported parameters
2. Model Prefix — Namespace models by provider
3. Model Aliases — Create shorter, memorable names

Complete Configuration Example

providers:
  - name: cerebras
    prefix: cerebras                    # Models will be prefixed as "cerebras/*"
    base-url: https://api.cerebras.ai/v1
    api-key-entries:
      - api-key: ${CEREBRAS_API_KEY}
    models:
      - name: gpt-oss-120b
        alias: gpt-120b                 # Use "cerebras/gpt-120b" or just "gpt-120b"
      - name: zai-glm-4.7
        alias: glm4.7
      - name: qwen-3-235b-a22b-instruct-2507
        alias: qwen3

# Optional payload configuration
payload:
  filter:
    # Filter rules remove specified parameters from the payload
    - models:
        - name: "cerebras/gpt-120b"     # Supports wildcards (e.g., "cerebras-*")
      protocol: "openai"                # Restricts rule to specific protocol
      params:                           # JSON paths to remove from payload
        - "store"

How It Works

Important: Filter Uses Prefixed Alias Names

When using prefix in provider config, the payload filter matches against prefix + alias (not prefix + original model name):

providers:
  - name: cerebras
    prefix: cerebras
    models:
      - name: gpt-oss-120b
        alias: gpt-120b                 # ← Filter uses this alias

# ✅ CORRECT: Use prefix + alias
payload:
  filter:
    - models:
        - name: "cerebras/gpt-120b"     # "prefix" + "alias"
      protocol: "openai"
      params:
        - "store"

# ❌ WRONG: These won't match
# - name: "cerebras/gpt-oss-120b"       # prefix + original name (wrong!)
# - name: "gpt-120b"                    # Missing prefix
# - name: "gpt-oss-120b"                # Original provider name

Why this matters: Using prefix + alias allows granular control. If you have multiple providers with the same underlying model name, you can apply filters only to specific aliases without affecting others.

The filter operates on the final resolved model identifier (prefix/alias), not the original name field from provider config.

Key Benefits

1. Provider namespacing — Clear model origin with prefix
2. Convenient aliases — Short names for daily use
3. Provider-specific handling — Different rules for different providers
4. No code changes — Pure configuration solution
5. Wildcard support — Apply to model families (e.g., cerebras-*)
6. Protocol-aware — Filter only applies to matching protocol

Verification

After applying the configuration:

# Test with Cerebras model
curl -X POST http://your-cliproxy-endpoint/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_KEY" \
  -d '{
    "model": "cerebras/gpt-120b",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

Should return 200 OK with valid response instead of 422.

Sample Response

Cerebras models return a standard OpenAI-compatible response with an additional reasoning field in the message:

{
  "id": "xxxxxxx",
  "choices": [{
    "finish_reason": "stop",
    "index": 0,
    "message": {
      "content": "Hello there! 👋 How can I help you today?",
      "reasoning": "The user just says 'Hello!' We need to respond appropriately: friendly greeting, ask how can I help. Possibly ask about what they need. Use a warm tone.",
      "role": "assistant"
    }
  }],
  "created": 1771016413,
  "model": "gpt-oss-120b",
  "usage": {
    "total_tokens": 125,
    "completion_tokens": 56,
    "prompt_tokens": 69
  }
}

Note the reasoning field — Cerebras exposes the model’s internal reasoning chain separately from the final response content. This is useful for debugging or understanding how the model arrived at its answer.

Lessons Learned

• Strict validation is becoming more common among API providers
• Gateway flexibility (payload filtering) prevents vendor lock-in issues
• Configuration over code enables faster iteration when dealing with provider quirks

References

• CliproxyAPI Documentation
• Cerebras API Reference
• gjson syntax for JSON path expressions

Published: February 14, 2026