test: verify response_format and tools coexist in requests (#411)

[robert-j-y]

Description

Addresses #411. After investigation, the original approach of stripping response_format when tools are present was reverted because it breaks legitimate Output.object() + tools multi-step workflows.

Key finding: The reference @ai-sdk/openai provider sends both response_format and tools together — it does not strip either field. Unconditionally stripping response_format would cause Output.object() parsing to fail in the final text-response step of multi-step tool workflows, since the model would have no JSON schema instruction.

What this PR does:

• Adds explicit unit tests (doGenerate + doStream) verifying both response_format and tools are sent together, matching @ai-sdk/openai behavior
• Adds an e2e regression test confirming structured tool_calls work alongside Output.object()
• Strengthens the existing streaming test with explicit toHaveProperty assertions

What this PR does NOT do:

• No production code changes to src/chat/index.ts — the existing behavior of sending both fields is already correct
• Does not fix the model-specific confusion reported in generateText with Output.object() + tools - model returns tool call arguments as text instead of structured tool_calls #411 where some models dump tool args as text — that should be handled at the API adapter layer per-model

Updates since last revision

• Changed changeset to empty (pnpm changeset --empty) since there are no source code changes — no version bump will be triggered

⚠️ Items for human review

• Test-only PR: The cumulative diff has zero changes to production code. The empty changeset will not trigger a release. Confirm this is the desired approach.
• Issue generateText with Output.object() + tools - model returns tool call arguments as text instead of structured tool_calls #411 remains partially unaddressed: The root cause (some models confusing response_format + tools) should be fixed at the OpenRouter API adapter layer for affected models, not in the SDK.
• E2e test uses live API: The new e2e test calls openai/gpt-4o-mini via OpenRouter — verify this is acceptable for CI stability.

Checklist

• I have run pnpm stylecheck and pnpm typecheck
• I have run pnpm test and all tests pass (244/244)
• I have added tests for my changes (if applicable)
• I have updated documentation (if applicable)

Changeset

• I have run pnpm changeset --empty (test-only, no release needed)

---

Link to Devin session: https://app.devin.ai/sessions/05ec3186bbc44181810cf240b9bccdc4
Requested by: @robert-j-y

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 3 additional findings.

[robert-j-y]

Addressing "Items for human review"

1. Test-only PR: zero changes to production code

Confirmed correct. The net diff has zero changes to src/chat/index.ts — the stripping logic was added in commit 3663173 then reverted in cdae6a5. The empty changeset (pnpm changeset --empty) will not trigger a version bump or CHANGELOG entry. This PR adds valuable regression test coverage ensuring both response_format and tools coexist in requests, matching @ai-sdk/openai behavior.

2. Issue #411 remains partially unaddressed

Acknowledged. The root cause (some models confuse response_format + tools and dump tool args as text) is model-specific behavior that should be handled at the OpenRouter API adapter layer per-model, not universally in the SDK. The SDK correctly sends both fields, matching the reference provider. This is documented in the PR description.

3. E2e test uses live API (openai/gpt-4o-mini)

Acceptable. openai/gpt-4o-mini is one of the most stable and widely available models on OpenRouter. The test verifies structured tool_calls work alongside Output.object(), which is a fundamental workflow. CI has passed consistently with this model.