[Compatibility] Camel DeepSeek V4 Flash misses structured tool call on the first tool round

[idguyst]

Client or integration

Codex App

Provider or upstream service

Camel Stream (stream.camelai.com), model deepseek-v4-flash

Endpoint or capability

Custom-provider /v1/responses model routing and first-tool-round tool-selection behavior.

The provider-wide adapter remains openai-chat, while only deepseek-v4-flash is routed through openai-responses.

Remaining problem

This issue now tracks only whether Camel deepseek-v4-flash emits code-mode-style text/markup instead of a structured tool call on the first tool round when tool_choice: "auto" is used.

The second problem from the original report, loss of the unified exec custom-to-function input description, was fixed in #1763 and merged into dev. The exec JavaScript input contract is therefore no longer part of this issue's implementation scope.

Expected behavior

• On the first tool round for stream.camelai.com + deepseek-v4-flash, the model should produce a structured tool call when it chooses to use a tool declared in the request.
• Requests using an explicit tool_choice must preserve their current semantics.
• Continuation turns containing tool results must preserve their current semantics.
• Other hosts, models, and providers must remain unaffected.

Evidence required before implementation

The following evidence is required against current dev:

1. A redacted raw upstream response from the first tool round showing the actual text/markup shape returned instead of a structured tool call.
2. Confirmation that tool_choice: "auto" was used with the same request/tool catalog.
3. The result of a control request using an explicit tool choice.
4. Control evidence showing that a continuation turn after tool output still behaves normally.

Without this evidence, we should not add a host/model hardcode that forces first-round tool_choice: "required" only for stream.camelai.com + deepseek-v4-flash. There is no public upstream contract for that behavior, so a provider-specific policy change requires reproducible current evidence.

Minimal redacted reproduction

{
  "adapter": "openai-chat",
  "baseUrl": "https://stream.camelai.com/v1",
  "defaultModel": "deepseek-v4-flash",
  "modelAdapters": {
    "deepseek-v4-flash": "openai-responses"
  },
  "responsesPath": null
}

1. On current dev, send a first request that includes tools.
2. Record the upstream request's tool_choice and tool catalog.
3. Capture the raw upstream response in redacted form.
4. Run an explicit-tool-choice control under the same conditions.
5. Run a continuation control that includes tool output.

Already fixed / out of scope

• Unified exec custom-to-function JavaScript input guidance: fixed by fix(responses): preserve unified exec input contract #1763 and merged into dev.
• Do not reimplement the bare-shell exec input problem in this issue.
• General custom-tool conversion changes are out of scope unless new evidence shows a separate regression.

Related

• fix(responses): preserve unified exec input contract #1763: merged shared exec input-contract repair.
• [Bug] DeepSeek V4 Flash Responses route stalls after tool calls #875, DeepSeek V4 Flash Responses tool calls stall in Codex App after upgrade from 2.8.0 to 2.10.0 #946: related compatibility context.

Checks

• I searched existing provider and compatibility issues.
• The request and response must be redacted.
• Current-dev raw first-response evidence for the remaining Camel-specific behavior is still required.

[coderabbitai]

🔗 Related PRs

#1361 - fix(responses): restore DeepSeek streaming and routed code-mode tools [merged]
#1479 - fix(deepseek): preserve parallel reasoning replay [open]
#1499 - fix(deepseek): keep parallel reasoning replay on continuation [open]
#1531 - fix(openai-chat): refuse to emit an unnamed streamed tool call [merged]
#1763 - fix(responses): preserve unified exec input contract [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Maintainer decision respected

A maintainer has reopened this issue. The automated closure has been deactivated.

[Ingwannu]

Confirmed one real general compatibility defect, but not enough evidence to adopt the proposed host/model hardcode as-is.

The confirmed defect is the custom-to-function conversion for exec: current dev replaces the original freeform contract with the generic description Raw input for this client-executed custom tool. That loses the fact that the input is JavaScript evaluated by unified exec, with shell commands invoked through tools.exec_command(...) and output returned through text(...). A model can therefore reasonably emit a bare shell command that the JavaScript evaluator rejects. This should be fixed at the shared exec conversion boundary with focused regressions.

The separate proposal to force tool_choice: required only for stream.camelai.com + deepseek-v4-flash on the first tool round is not ready to land yet. There is no public upstream contract for that behavior, and a hostname/model special case changes tool-selection semantics for every user of that route. Before adopting it, we need a redacted raw first-response capture showing the malformed text/markup shape on current dev, plus confirmation that a normal explicit tool choice and continuation turn remain unchanged.

I will treat the shared exec input-contract repair independently so that confirmed behavior does not wait on the provider-specific policy decision.

[Ingwannu]

The confirmed shared exec conversion defect is implemented in #1763.

The patch restores the JavaScript contract only for the converted unified exec tool, including the required tools.exec_command(...) and text(...) usage, while leaving all other custom-tool descriptions unchanged.

Validation on current dev:

• custom-tool compatibility plus adjacent Responses passthrough suites: 70 passed
• typecheck passed
• privacy scan passed
• diff check passed

This PR intentionally does not implement the proposed Camel-specific first-turn tool_choice: required override. The issue should remain open for that separate provider-specific reproduction unless the shared contract repair alone resolves it.

[lidge-jun]

The shared half of this is now on dev as ea06086 (squash of #1763).

Routed custom tools are rewritten into function tools for upstreams that do not speak the custom-tool shape, and that rewrite described every tool's input as "Raw input for this client-executed custom tool" — which told a routed model that unified exec takes a bare shell command. Codex then executed the returned string as JavaScript. exec now carries its real contract in the converted schema, and every other custom tool keeps the generic description.

Verified on the remote validation host: 89 pass / 0 fail across tests/custom-tool-compat.test.ts, tests/openai-responses-passthrough.test.ts, tests/responses-custom-tool-repair.test.ts.

Keeping this open. That fix teaches a model that already chose exec how to format its input; it does not address the reported first-turn behavior where Camel deepseek-v4-flash emits code-mode text instead of a structured tool call while tool_choice is "auto". That part needs raw-response evidence against current dev before we decide whether a provider-specific first-turn policy is warranted.