Conversation
… capability
The supportsMediaInToolResult gate returned true unconditionally for
@ai-sdk/anthropic / @ai-sdk/openai npm packages, keeping image/PDF
attachments inside tool results even when the model has attachment:
false (e.g. GLM-5.2 on Synthetic). On the next turn, replaying history
re-sent that media in the tool result and the provider rejected the
whole request with a 400 ("does not appear to support image inputs").
Now returns false when the model lacks attachment capability, routing
media to a user message where unsupportedParts() degrades it to a
graceful text note instead of failing the request.
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Issue for this PR
Closes #41162
Type of change
What does this PR do?
supportsMediaInToolResultinmessage-v2.tsreturnedtrueunconditionally for@ai-sdk/anthropicand@ai-sdk/openainpm packages. For models withattachment: false(no vision — e.g. GLM-5.2 served through an Anthropic-compatible endpoint), image/PDF attachments from tool results stayed inside the tool result and were re-sent on every subsequent turn as part of history replay. The provider then rejected the entire request with a 400 (e.g.Model ... does not appear to support image inputs.), killing the response instead of degrading gracefully.The fix makes
supportsMediaInToolResultreturnfalsewhenmodel.capabilities.attachmentis false. Media then routes to the user-message path whereunsupportedParts()degrades it to a graceful text note ("ERROR: Cannot read image ... Inform the user.") and the model replies normally — matching the behavior of the openai-compatible path.How did you verify your code works?
@ai-sdk/openai,attachment: false).extracts tool-result media for anthropic models without attachment capability— anthropic npm +attachment: false→ media extracted out of tool result into a user message.message-v2.test.tssuite: 40 pass / 0 fail.bun run typecheckclean.Screenshots / recordings
N/A (no UI change)
Checklist