hermes - 💡(How to fix) Fix [Bug] Cerebras models (gpt-oss-120b, zai-glm-4.7) fail on second turn with reasoning_content unsupported error [1 pull requests]

Bug Description

When using Cerebras as a custom provider with either gpt-oss-120b or zai-glm-4.7, the first message works correctly but the second message always fails with HTTP 400.

Error

HTTP 400: messages.2.assistant.reasoning_content: property 'messages.2.assistant.reasoning_content' is unsupported type: invalid_request_error param: validation_validation code: wrong_api_format

Root Cause

Cerebras models generate reasoning_content in their responses (turn 1), but Cerebras API rejects that field when it is included back in the message history (turn 2). This is the opposite behavior from DeepSeek, which requires reasoning_content to be passed back.

The fix in PR #33795 (re-pad reasoning_content on cross-provider fallback) handles the case where providers require the field, but does not handle the case where providers reject it. Cerebras needs the reasoning_content field to be stripped from history before sending.

Steps to Reproduce

1. Configure Hermes with Cerebras as custom provider: base_url: https://api.cerebras.ai/v1
2. Set model to gpt-oss-120b or zai-glm-4.7
3. Send any first message → works fine
4. Send any second message → HTTP 400 error

Environment

• Hermes version: v2026.5.28
• OS: Windows 11
• Provider: Cerebras (https://api.cerebras.ai/v1 )
• Models affected: gpt-oss-120b (Production), zai-glm-4.7 (Preview)

Expected Behavior

Hermes should detect that Cerebras rejects reasoning_content in history and strip it before sending subsequent turns, similar to how it handles other provider-specific field incompatibilities.

Suggested Fix

Add Cerebras to a list of providers that require reasoning_content to be dropped from message history, or detect the wrong_api_format error on reasoning_content and automatically retry stripping the field.