[liangmouse]

Summary

Use the review's explicit, verified-model mapping option (not automatic retry):

JoyCode model	none	minimal
GPT-6 Astra	map to low	map to low
GPT-6.1 Sol	map to low	map to low
GPT-6 Sol	preserve (accepted)	map to low
GPT-5.6 Sol	preserve (accepted)	map to low

Only Responses requests are changed. Valid and omitted efforts, other reasoning fields, unknown models, and other protocols are preserved. Version 0.2.2.

Evidence

On 2026-10-30 I fetched the account's live joycode_modelList: these are all four Responses models currently present (the catalogue has changed since 0.2.0). Sent a real raw gateway probe for each model with both none and minimal.

Contrary to the Codex catalogue, JoyCode GPT-6 Sol and GPT-5.6 Sol accept none and completed with OK. Their passthrough tests are retained for this measured reason, not an assumption.

Full upstream rejection evidence

All probes returned HTTP 200; these are the complete error objects returned inside the JoyCode envelope for the six rejected combinations. The envelope has code 400, message 模型服务调用失败, status FAILED_RESPONSE, and a JSON-encoded cause:

GPT-6.1 Sol / none

{
  "error": {
    "message": "Unsupported value: 'none' is not supported with the 'gpt-6.1-sol-2026-09-29' model. Supported values are: 'low', 'medium', 'high', 'xhigh', and 'max'.",
    "type": "invalid_request_error",
    "param": "reasoning.effort",
    "code": "unsupported_value"
  }
}

GPT-6.1 Sol / minimal

{
  "error": {
    "message": "Unsupported value: 'minimal' is not supported with the 'gpt-6.1-sol-2026-09-29' model. Supported values are: 'low', 'medium', 'high', 'xhigh', and 'max'.",
    "type": "invalid_request_error",
    "param": "reasoning.effort",
    "code": "unsupported_value"
  }
}

GPT-6 Sol / minimal

{
  "error": {
    "message": "Unsupported value: 'minimal' is not supported with the 'gpt-6-sol-2026-09-22' model. Supported values are: 'none', 'low', 'medium', 'high', 'xhigh', and 'max'.",
    "type": "invalid_request_error",
    "param": "reasoning.effort",
    "code": "unsupported_value"
  }
}

GPT-6 Astra / none

{
  "error": {
    "message": "Unsupported value: 'none' is not supported with the 'gpt-6-astra-2026-09-03' model. Supported values are: 'low', 'medium', 'high', 'xhigh', and 'max'.",
    "type": "invalid_request_error",
    "param": "reasoning.effort",
    "code": "unsupported_value"
  }
}

GPT-6 Astra / minimal

{
  "error": {
    "message": "Unsupported value: 'minimal' is not supported with the 'gpt-6-astra-2026-09-03' model. Supported values are: 'low', 'medium', 'high', 'xhigh', and 'max'.",
    "type": "invalid_request_error",
    "param": "reasoning.effort",
    "code": "unsupported_value"
  }
}

GPT-5.6 Sol / minimal

{
  "error": {
    "message": "Unsupported value: 'minimal' is not supported with the 'gpt-5.6-sol-2026-07-09' model. Supported values are: 'none', 'low', 'medium', 'high', 'xhigh', and 'max'.",
    "type": "invalid_request_error",
    "param": "reasoning.effort",
    "code": "unsupported_value"
  }
}

Patched real streaming requests

All eight combinations were then sent through the patched plugin. Every request returned OK and response.completed:

Model	Effort requested	Duration
GPT-6.1 Sol	none	4.689s
GPT-6.1 Sol	minimal	3.740s
GPT-6 Sol	none	2.135s
GPT-6 Sol	minimal	1.468s
GPT-6 Astra	none	3.290s
GPT-6 Astra	minimal	1.318s
GPT-5.6 Sol	none	1.760s
GPT-5.6 Sol	minimal	1.753s

Regression and scope

node --test packages/joycode/*.test.mjs: 64/64 pass. bun scripts/check.mjs joycode and git diff --check pass. A disposable copy with the original Astra-only mapping makes five new tests fail (35 pass / 5 fail), confirming the added coverage.

Tests cover every mapped combination, both real none-accepting models, unknown models, and preservation of other fields/protocols/valid efforts.

The probes use synthetic short prompts, not private conversation history. Original long-conversation compaction has not been rerun.

Merge Danger

Door: two-way

Blast Radius: Responses

Only the six verified model/effort combinations change. low can add reasoning usage; every mapped value was rejected by the backend. Future catalogue additions require verification and a table update; automatic rejection-driven retry is not implemented in this patch, keeping it bounded and avoiding error-stream buffering/replay changes.

[yetone]

Thanks. I checked out 0e9ea94 and ran it on macOS (Bun 1.4.2, Node 22) with a sandbox HOME: bun test and node --test in packages/joycode both pass 54/54, the whole repo's bun test passes (3546 pass, 8 skip, 0 fail), and bun scripts/check.mjs is clean. I also put the mapping back to none by hand, and the Astra test goes red, so the test does cover the fix. The level is right as well: Codex's own model catalogue lists low, medium, high, xhigh, max, ultra for gpt-6-astra, with no none or minimal.

I have to hold it for one thing, though: the fix only covers one model, and the test locks the other models into the bug.

1. Other JoyCode Responses models probably refuse none too (packages/joycode/index.mjs:778, packages/joycode/chat.test.mjs:229). In the same Codex catalogue, gpt-5.6-sol, gpt-5.6-terra, gpt-6-sol and gpt-6-luna all start at low too, with no none. The 0.2.0 CHANGELOG says your account's joycode_modelList has 4 openai-response models. But the other model none case requires GPT-5.6 Sol's none to go upstream unchanged, so a compaction on Sol would probably fail exactly the way Astra did. Could you send the same none probe to each openai-response model on your account and post what comes back? Then do one of these:

   • map none to low for every model that refuses it, and turn the Sol case into a mapping test if Sol refuses too; or, better,
   • when the upstream error says the effort value is unsupported (unsupported_value on reasoning.effort for none/minimal), retry once with low. Then a model added to JoyCode's catalogue later is covered without a release. If you take this route, keep a test where a model that accepts none is sent none unchanged.

2. minimal is missing from Astra's list too (index.mjs:778). Please handle it the same way as none, and add a test.

3. Please put the upstream's full error text in the PR body. Right now it only quotes Unsupported value: 'none'. If the error also lists the supported values, that is the direct evidence that low is the lowest.

Ping me when it's updated and I'll run it again.

[liangmouse]

@yetone Updated in 3b654be, using your verified-model mapping option. I probed all four current JoyCode Responses models with both none and minimal. Importantly, GPT-6 Sol and GPT-5.6 Sol actually accept none (both returned OK); their passthrough coverage is retained based on that evidence. GPT-6 Astra and GPT-6.1 Sol reject both values; all four reject minimal. The patch now maps all six rejected combinations to low and leaves accepted none unchanged. Full upstream errors, supported values, and the probe matrix are in the PR body. All eight combinations then completed through the patched plugin with OK and response.completed (1.3–4.7s). Node tests: 64/64; plugin check and diff check pass. Replacing the table with the original Astra-only behavior in a disposable copy makes five added tests fail. No automatic retries or error-stream buffering changes are introduced; future catalogue additions still need verification. Please take another look. The original long-conversation compaction has not been rerun.

[yetone]

Thanks @liangmouse, this answers all three review points. Merged at 3b654be: 64/64 on both bun and node, and swapping the none-capable models turns their tests red. JoyCode isn't on npm yet, so 0.2.2 ships from the dist branch (the tgz is there now). We have no JoyCode account, so the live behaviour rests on your probes.