#Grok-4.3 does not work

1 messages · Page 1 of 1 (latest)

strong mulch
#

Grok-4.3 fails

16:12:37 - run_agent - INFO - OpenAI client created (codex_stream_request, shared=False) thread=Thread-3 (_call):135716438795968 provider=xai-oauth base_url=https://api.x.ai/v1 model=grok-4.3
16:12:39 - run_agent - DEBUG - Responses stream prelude rejected (attempt 1/2); retrying. thread=Thread-3 (_call):135716438795968 provider=xai-oauth base_url=https://api.x.ai/v1 model=grok-4.3
16:12:41 - run_agent - DEBUG - Responses stream rejected before response.created; falling back to create(stream=True). thread=Thread-3 (_call):135716438795968 provider=xai-oauth base_url=https://api.x.ai/v1 model=grok-4.3 err=Expected to have received response.created before error
16:12:42 - run_agent - INFO - OpenAI client closed (request_complete, shared=False, tcp_force_closed=0) thread=Thread-3 (_call):135716438795968 provider=xai-oauth base_url=https://api.x.ai/v1 model=grok-4.3
16:12:42 - run_agent - DEBUG [20260516_161236_791b8c] - Error classified: reason=unknown status=None retryable=True compress=False rotate=False fallback=False
16:12:42 - run_agent - WARNING [20260516_161236_791b8c] - API call failed (attempt 1/3) error_type=RuntimeError thread=Thread-2 (run_agent):135716447188672 provider=xai-oauth base_url=https://api.x.ai/v1 model=grok-4.3 summary=Responses create(stream=True) fallback did not emit a terminal response.
⚠️ API call failed (attempt 1/3): RuntimeError

note: this is not the 403 error we had for a while for Premium+ subscribers trying to use SuperGrok Oauth... this is something else. Also happens with Grok-4.20 model

rotund lake
#

<@&1214801236323467284> cannot find x auth in hermes setup model

strong mulch
#

~/dev/hermes$ hermes auth list
openai-codex (2 credentials):
#1 openai-codex-oauth-1 oauth device_code ←
#2 device_code oauth device_code

xai-oauth (1 credentials):
#1 xai-oauth-oauth-1 oauth xai_pkce ←

strong mulch
#

clean config and reinstall has fixed it. I suspect the config goes wrong somewhere...

knotty galleon
#

nice

strong mulch
#

can the problem be with MCP servers?

#

Grok-4.3 works when I remove all MCP servers from the config. It fails when I have one or more.

#

x.ai has some server-side MCP setup in their API... probably has to be handled differently

#

I've logged it as a new thread with a more apt title

upbeat ocean
#

no need for a new thread for that. especially with no logs in the new thread. we can track that here since it's likely the same issue. I'll take a look at these logs and close the other thread and we can go from there. while I'm doing that, please tell me which mcp servers you have that are causing the issue.

#

The generic Grok stream error from your logs is now covered by this merged PR:

https://github.com/NousResearch/hermes-agent/pull/27184

Your failing run was on 0.14.0 [dffb602f], before that fix. The PR does not necessarily mean “Grok + your MCP tools will now work,” but it fixes the part where Hermes swallowed xAI’s real type=error stream event and replaced it with:

Responses create(stream=True) fallback did not emit a terminal response

Please update first:

hermes update

Then retry once with the same MCP config enabled.

One detail on the MCP theory: Hermes is not sending xAI a server-side MCP config here. Hermes registers your MCP servers locally as tools, then sends those to Grok as Responses function tool schemas. In the failing log, Hermes registered 10 MCP tools from oom-research-hub and wolfram before the Grok call failed.

If it still fails after updating, please continue with one fresh debug share captured immediately after a single failed hi / hello prompt. After #27184, the log should show xAI’s actual rejection message instead of only the generic response.created error.

If you want to isolate it faster, test with only one MCP server enabled at a time:

oom-research-hub only

then:

wolfram only

That should tell us whether one specific MCP-derived tool schema is triggering the xAI rejection, or whether Grok is rejecting the MCP tool set more generally.

upbeat ocean
strong mulch
#

'Error: Invalid arguments passed to the model'

upbeat ocean
#

Thanks, this is enough to narrow the next step.

The update worked in the sense that Hermes is no longer hiding xAI’s real error behind the old response.created stream message. The current error is now:

Invalid arguments passed to the model.

Since the same model works with MCP removed, and fails with Wolfram MCP enabled on a simple Hello. Who are you?, the useful artifact is not another normal debug share. The normal logs do not include the full tool schema payload xAI is rejecting.

Please run one focused repro with request dumping enabled:

HERMES_DUMP_REQUESTS=1 hermes

Then send one simple prompt like:

hello

After it fails, Hermes should write a file like:

~/.hermes/logs/request_dump_<session>_*.json

Please review it before sharing because it can include prompt/context. The specific part we need is the request body.tools array from the failing xAI request.

That should tell us whether Grok is rejecting the Wolfram MCP tool schema itself, the Responses function-tool wrapper Hermes builds for MCP tools, or a specific JSON Schema shape inside one of those tools.

stoic rapids
#

Hello just shipped a fix! hermes-xai-oauth-wsl

upbeat ocean
strong mulch
#

thanks for looking into this.

Specific problems visible in the dump:

Malformed tool schema structure (the big one):
Each tool object is flat like this:

{
  "type": "function",
  "name": "mcp_Wolfram_...",
  "description": "...",
  "strict": false,
  "parameters": { ... }
}

xAI expects the standard OpenAI-compatible nested format:

{
  "type": "function",
  "function": {
    "name": "...",
    "description": "...",
    "parameters": { ... },
    "strict": false   // or inside function
  }
}

The flattened version triggers immediate validation failure on xAI's side.
Wolfram MCP tools add extra invalid JSON Schema features, most notably:
"pattern": "(?ms).*" (Perl-style regex flags with multiline/dotall) inside the parameters schema.
This pattern (and potentially other advanced schema keywords from MCP registration) is not accepted by Grok's tool validator.

upbeat ocean
#

Thanks, that request dump is the useful bit.

This now matches the open PR here:

https://github.com/NousResearch/hermes-agent/pull/27219
cc @knotty galleon or @tall heart (review?)

One clarification: the flat {"type":"function","name":...,"parameters":...} shape is expected on Hermes' Responses API path, so I would not treat that part by itself as malformed.

The part that looks relevant is the MCP schema content. Wolfram is carrying JSON Schema keywords like pattern through after Hermes converts MCP tools into Responses-format function tools, and xAI rejects those with Invalid arguments passed to the model.

PR #27219 extends the schema sanitizer to Responses-format tools and strips pattern / format for xAI-compatible requests. Until that lands, the practical workaround is to disable MCP tools for Grok/xAI or use a provider that accepts those MCP schemas.

knotty galleon