OpenAI-compatible GPT-5.5 (or 5.x model?) support issues: 400 errors, streaming tool-call parsing, and unclear diagnostics

[pineapple880066]

What happened?

When using OpenGame CLI with --auth-type openai against an OpenAI-compatible endpoint and model gpt-5.5, I ran into several compatibility issues around request defaults, streaming tool-call parsing, and error diagnostics.

The main blockers were:

1. Initial requests failed with a generic 400 openai_error.
2. The default OpenAI-compatible provider injected sampling params such as topP: 0.95, which may be incompatible with some GPT-5.x/tool-call requests.
3. Streaming tool-call chunks from the provider did not always keep metadata and argument chunks on the same index, causing tool-call parsing to fail.
4. Some responses consumed tokens but returned content: null with no usable text/tool call, resulting in Model stream ended with empty response text.
5. Local debugging was confusing because editing packages/core/src/... does not affect dist/cli.js until the CLI is rebuilt.
6. There are also some secondary local environment issues, such as url.parse() warnings and Rollup native optional dependency failures on macOS arm64 + Node 24.

What did you expect to happen?

Expected behavior
When using OpenAI-compatible GPT-5.x models:

1.The default provider should avoid sending potentially incompatible sampling params unless explicitly configured.
2.400 errors should expose enough diagnostic details to identify the unsupported field or response shape.
3.Streaming tool-call parsing should tolerate metadata and arguments arriving on different indexes.
4.content: null responses with token usage should produce actionable diagnostics or trigger retry/fallback.
5.Common local generated-project build failures should have clearer docs or automatic recovery.

Client information

Client Information

Environment：
OpenGame / qwen_code_version: 0.6.0
CLI entry: OpenGame/dist/cli.js
Node.js: v24.14.0
Platform: macOS arm64
Auth mode: --auth-type openai
Model: gpt-5.5
Endpoint type: OpenAI-compatible
Tools enabled: classify_game_type, generate_gdd, generate_game_assets, generate_tilemap, etc.

Login information

OPENAI_API_KEY=...
OPENAI_BASE_URL=https://www.packyapi.com/v1
OPENAI_MODEL=gpt-5.5

Anything else we need to know?

Issue 1: Generic 400 openai_error is hard to diagnose
The initial request failed with:

[API Error: 400 openai_error]
The OpenAI-compatible request log also only showed:

{
"error": {
"message": "400 openai_error"
}
}
Impact
It is difficult to tell whether the failure is caused by unsupported sampling parameters, unsupported tools schema, model capability mismatch, streaming incompatibility, or a provider-side proxy error.

Suggestion
When --openai-logging is enabled, please preserve more raw response details for 400 responses:

HTTP status
response body
request id if present
provider error fields if present
request fields that may be incompatible
Issue 2: Default OpenAI-compatible provider injects topP: 0.95
The default provider currently sets default generation config similar to:

getDefaultGenerationConfig(): GenerateContentConfig {
return {
topP: 0.95,
};
}
Local workaround:

getDefaultGenerationConfig(): GenerateContentConfig {
return {};
}
Impact
Some OpenAI-compatible GPT-5.x endpoints may reject extra sampling parameters, especially when tools and streaming are involved.

Suggestion
For the generic OpenAI-compatible provider:

Do not inject topP/top_p by default.
Only pass sampling params when the user explicitly configures them.
Or gate defaults by provider/model capability.
Issue 3: Source changes require rebuilding dist/cli.js
While debugging, changing files under:

packages/core/src/...
did not affect the CLI behavior because the actual command was running:

dist/cli.js
Suggestion
Please document that local source changes require rebuilding/bundling the CLI before testing dist/cli.js.

A dev-mode command that runs directly from source would also reduce confusion.

Issue 4: Model stream ended with empty response text
After rebuilding with the local provider workaround, the API request no longer failed immediately with 400, but the CLI later returned:

[API Error: Model stream ended with empty response text.]
The usage showed tokens were consumed:

{
"input_tokens": 25214,
"output_tokens": 293,
"total_tokens": 25507
}
The response shape included:

{
"message": {
"role": "assistant",
"content": null,
"refusal": null
},
"finish_reason": "stop"
}
Impact
The model/provider consumed completion tokens, but OpenGame treated the response as an empty stream without enough diagnostic context.

Suggestion
For content: null with no tool_calls:

Print a clearer error message.
Include the raw choice structure in debug logs.
Consider one automatic retry.
Consider falling back to a non-streaming request for diagnostics.
Issue 5: Streaming tool-call parser assumes continuation chunks keep the same index
The most important compatibility issue was streaming tool-call parsing.

Observed chunk pattern:

index 0: tool call metadata, contains id/name
index 1: later arguments chunks, without id/name
The current parser appears to assume that continuation chunks for the same tool call continue using the same index.

When arguments arrive on a later index without metadata, they can be treated as a separate incomplete tool call, so the full tool call is never reconstructed correctly.

Local workaround
In:

packages/core/src/core/openaiContentGenerator/streamingToolCallParser.ts
Route no-id/no-name continuation chunks to an existing incomplete tool call when the current index has no existing buffer:

const existingIncompleteIndex = this.findExistingIncompleteIndex();

if (existingIncompleteIndex !== undefined) {
actualIndex = existingIncompleteIndex;
}
Regression test idea:

parser.addChunk(0, '', 'call_1', 'classify_game_type');

const chunks = [
'{"',
'game_description',
'":"',
'浏览器里的贪吃蛇游戏',
'"}',
];

for (const chunk of chunks) {
parser.addChunk(1, chunk);
}
Expected parsed result:

{
id: 'call_1',
name: 'classify_game_type',
args: { game_description: '浏览器里的贪吃蛇游戏' },
index: 0,
}
Suggestion
Please make the streaming tool-call parser more tolerant of OpenAI-compatible providers where:

metadata and arguments chunks may use different indexes
continuation chunks may not include id/name
arguments may be split across multiple chunks in non-standard ways
Issue 6: url.parse() deprecation warning
Every CLI run prints:

[DEP0169] DeprecationWarning: url.parse() behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead.
Impact
This is not blocking, but it adds noise when debugging API connection issues.

Suggestion
Replace url.parse() usage with the WHATWG URL API.

Issue 7: Generated Vite project can fail on macOS arm64 + Node 24 due to Rollup native optional dependency
This is not directly a GPT-5.x API issue, but it happened during the first successful generated game build.

Error:

Error: Cannot find module @rollup/rollup-darwin-arm64
npm has a bug related to optional dependencies

ERR_DLOPEN_FAILED
code signature ... not valid for use in process
Node.js v24.14.0
Local workaround:

npm install -D rollup@npm:@rollup/wasm-node@^4.61.1
After this, npm run build passed.

Suggestion
If OpenGame generates Vite projects, it could:

document this macOS arm64 / Node 24 workaround
or let the agent automatically try @rollup/wasm-node when native Rollup loading fails

Local patches used to continue testing
I used local patches in these files:

packages/core/src/core/openaiContentGenerator/provider/default.ts
packages/core/src/core/openaiContentGenerator/streamingToolCallParser.ts
packages/core/src/core/openaiContentGenerator/streamingToolCallParser.test.ts
Main changes:

Do not inject { topP: 0.95 } by default for generic OpenAI-compatible providers.
Route no-id/no-name streaming argument chunks to an existing incomplete tool call when appropriate.
Add a regression test for metadata and argument chunks using different indexes.

[HerShin5]

This is a good repro because it separates several issues that often get conflated as "OpenAI-compatible endpoint is flaky".

A few implementation/test details that seem worth splitting out:

• For the generic OpenAI-compatible provider, avoid injecting default sampling parameters (topP/top_p, temperature, etc.) unless the user explicitly configures them. Some newer tool-capable endpoints are strict about unsupported fields, and a default can turn into a hard-to-diagnose 400.
• Preserve a redacted 400 diagnostic when --openai-logging is enabled: HTTP status, upstream request id if present, provider error body, model, base URL host/path, and the high-level request feature flags (stream=true, tools=N, sampling_params_present=[...]). That is usually enough to identify whether the failure is schema, sampling, model, or proxy related without leaking prompts/keys.
• For streaming tool calls, I would add parser fixtures for at least these shapes:
  1. metadata chunk and argument chunks on the same index;
  2. metadata on index=0, argument continuation on a later index with no id/name;
  3. split JSON arguments across many chunks;
  4. terminal chunk with content:null, tool_calls absent, and token usage present.
• For the content:null + token usage case, a fallback non-streaming diagnostic retry is useful, but it should be opt-in or one-shot so it does not accidentally double spend tokens in normal gameplay generation.

Disclosure: I'm associated with/evaluating KiroForge. The way I would test this class of bug is to keep two OpenAI-compatible targets in CI/smoke tests: one direct provider and one gateway endpoint such as https://kiroforge.cloud/v1. The goal is not to special-case a gateway, but to prove OpenGame's generic provider keeps the wire body minimal, reconstructs streamed tool calls robustly, and produces actionable diagnostics when an upstream OpenAI-compatible endpoint is strict.