fix(responses): accept reasoning effort none

[ankrovv]

Problem

SMG rejects reasoning.effort:"none" during Responses request parsing, before vLLM receives it.

Reproducer

curl -i -sS "$BASE_URL/v1/responses" \
  -H 'content-type: application/json' \
  -d '{
    "model": "vllm-model",
    "input": "Reply exactly OK",
    "reasoning": {"effort": "none"},
    "store": false
  }'

Before: HTTP 400, unknown variant 'none'. Direct vLLM accepts the same request for non-Harmony models.

Fix

• Accept and serialize none in the Responses protocol.
• Preserve it through HTTP and regular gRPC forwarding.
• Reject it explicitly for Harmony models, which only support low/medium/high.

Tests

Protocol round-trip, HTTP serialization, regular gRPC conversion, Harmony new/continuation rejection, and /v1/responses endpoint tests pass. Focused clippy passes. The local all-features clippy run requires system OpenCV/pkg-config; CI covers that configuration.

Summary by CodeRabbit

• New Features

  • Added support for the "none" reasoning effort option in the Responses API.
  • Requests using "none" now preserve the setting across serialization and conversion to chat requests.
  • The /v1/responses endpoint accepts requests with reasoning.effort: "none".

• Bug Fixes

  • Added clear validation when "none" cannot be represented by Harmony conversations.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: d15ba5d2-28b5-48f3-ba29-00ddd4bdd8ae

📥 Commits

Reviewing files that changed from the base of the PR and between cdcb3f8 and 3984adb.

📒 Files selected for processing (6)

• crates/protocols/src/responses.rs
• crates/protocols/tests/responses.rs
• model_gateway/src/routers/grpc/harmony/builder.rs
• model_gateway/src/routers/grpc/regular/responses/conversions.rs
• model_gateway/src/routers/openai/responses/route.rs
• model_gateway/tests/api/api_endpoints_test.rs

---

📝 Walkthrough

Walkthrough

The Responses protocol adds ReasoningEffort::None and canonical string conversion. Responses-to-chat conversion and endpoint handling preserve "none", while Harmony explicitly rejects the unsupported value across new and continued conversations.

Changes

Reasoning effort none support

Layer / File(s)	Summary
Protocol contract crates/protocols/src/responses.rs, crates/protocols/tests/responses.rs	Adds ReasoningEffort::None, its canonical string mapping, and a JSON roundtrip test.
Responses propagation and endpoint validation model_gateway/src/routers/grpc/regular/responses/conversions.rs, model_gateway/src/routers/openai/responses/route.rs, model_gateway/tests/api/api_endpoints_test.rs	Preserves "none" during Responses-to-chat conversion and verifies router serialization and /v1/responses acceptance.
Harmony conversion and rejection model_gateway/src/routers/grpc/harmony/builder.rs	Uses shared system-message construction, maps supported effort values, and rejects None for both conversation modes.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant ResponsesRouter
  participant responses_to_chat
  participant ChatCompletionRequest
  Client->>ResponsesRouter: POST /v1/responses with effort "none"
  ResponsesRouter->>responses_to_chat: Convert ResponsesRequest
  responses_to_chat->>ChatCompletionRequest: Set reasoning_effort to "none"
  ChatCompletionRequest-->>ResponsesRouter: Converted request
  ResponsesRouter-->>Client: OK response

Loading

Possibly related PRs

• lightseekorg/smg#1876: Adds related handling that turns "none" and "minimal" reasoning effort into disabled thinking.
• lightseekorg/smg#1882: Resolves "none" reasoning effort to disabled thinking in the gRPC/chat pipeline.

Suggested reviewers: catherinesue, key4ng, claude, slin1237

Poem

I’m a rabbit hopping through the wire,
Carrying "none" without a fire.
Routes preserve the tiny hue,
Harmony says, “Not for me to do!”
Tests nod twice, the contracts gleam—
A tidy burrow for reasoning’s stream.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and accurately summarizes the main change: adding support for reasoning effort "none" in Responses.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

⚔️ Resolve merge conflicts

• Resolve merge conflict in branch fix/responses-reasoning-effort-none

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gemini-code-assist]

Code Review

This pull request introduces support for the None variant in ReasoningEffort for responses. It implements serialization and deserialization logic, maps it correctly in regular chat conversions, and ensures that Harmony requests explicitly reject this option since Harmony models do not support it. Comprehensive unit and integration tests have been added to verify these behaviors. I have no further feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[mergify]

Hi @ankrovv, this PR has merge conflicts that must be resolved before it can be merged. Please rebase your branch:

git fetch origin main
git rebase origin/main
# resolve any conflicts, then:
git push --force-with-lease

[github-actions]

This pull request has been automatically marked as stale because it has not had any activity within 14 days. It will be automatically closed if no further activity occurs within 16 days. Leave a comment if you feel this pull request should remain open. Thank you!