Anthropic buildMessageParam silently drops image-URL, PDF, and hosted-file inputs

[PratikDhanave (PratikDhanave)]

Problem

buildMessageParam in provider/anthropicprovider/agent.go only handled base64 image DataContent. Every other multimodal content type fell through the content switch and was silently dropped before the request reached the Anthropic Messages API:

• *message.URIContent (including image URLs) — no case at all
• non-image *message.DataContent (application/pdf) — the single if TopLevelMediaType() == "image" skipped it
• *message.HostedFileContent — no case at all

This diverges from the OpenAI chat provider (provider/openaiprovider/chat.go), which maps URIContent, DataContent, and HostedFileContent, and from the .NET/Python multimodal content mapping where a user message's image/PDF parts are always forwarded. A caller attaching a PDF or an image URL to an Anthropic run got a request with those parts missing and no error.

Change

Extend the content switch in buildMessageParam:

• base64 application/pdf DataContent -> anthropic.NewDocumentBlock(Base64PDFSourceParam{Data})
• image URIContent -> anthropic.NewImageBlock(URLImageSourceParam{URL})
• application/pdf URIContent -> anthropic.NewDocumentBlock(URLPDFSourceParam{URL})

The base64-image path is unchanged. HostedFileContent is left with an explanatory comment rather than a silent skip: the stable Messages API (anthropic.MessageNewParams) in anthropic-sdk-go v1.58.1 exposes no file-id image/document source — only the Beta API has BetaFileImageSourceParam/BetaFileDocumentSourceParam — so a hosted file reference cannot be forwarded here yet.

This brings Anthropic multimodal input handling in line with the OpenAI provider and the cross-SDK (.NET/Python) semantics of forwarding image and document parts on user messages.

Testing

Added TestBuildMessageParam_ImageURLAndPDFAreForwarded to the canonical agent_test.go, using the existing httptest-server harness. It runs a message carrying an image URIContent and an application/pdf DataContent, captures the outgoing request body, and asserts it contains an image block with a url source and a document block with a base64 application/pdf source. The test fails before the fix (both blocks absent) and passes after.

go build ./..., go vet ./provider/anthropicprovider/..., and go test ./provider/anthropicprovider/... all pass.

[Copilot]

Pull request overview

This PR fixes Anthropic provider multimodal input handling so image URLs and PDF inputs are forwarded to the Anthropic Messages API instead of being dropped during request construction.

Changes:

• Extend buildMessageParam to map URIContent images and PDFs, plus base64 application/pdf DataContent, into Anthropic image/document content blocks.
• Add a regression test that asserts outgoing requests include both an image-url block and a base64-PDF document block.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
provider/anthropicprovider/agent.go	Adds URI/image and PDF (base64 + URL) content block mapping in buildMessageParam; documents HostedFile limitation.
provider/anthropicprovider/agent_test.go	Adds a regression test validating image URL + base64 PDF are present in the outgoing Anthropic request body.

Comments suppressed due to low confidence (1)

provider/anthropicprovider/agent.go:500

• Same as above for URIContent: checking MediaType with exact equality will miss valid values that include parameters (e.g. "application/pdf; ..."), causing the PDF URL to be silently dropped.

			case c.MediaType == "application/pdf":

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[PratikDhanave (PratikDhanave)]

Good catch — fixed in 90f1ec2: both PDF checks now go through a new isPDFMediaType helper that parses the media type with mime.ParseMediaType and compares the base type to "application/pdf" case-insensitively, so parameterized values like "application/PDF; charset=binary" are recognized instead of dropped. Added a test covering the parameterized case.

[PratikDhanave (PratikDhanave)]

Good catch — fixed in 90f1ec2: buildMessageParam now returns an explicit error for HostedFileContent (naming the offending file id and pointing callers to DataContent/URIContent) instead of silently dropping it behind a comment. Added a test asserting the request fails rather than being sent.

[github-actions]

Parity Review — PR #615

Scope: provider/anthropicprovider/agent.go — internal buildMessageParam function. No exported Go APIs were changed. The public-api-change label is not warranted.

Cross-SDK comparison

Content type	Go (before)	Go (after this PR)	Python (_chat_client.py)	.NET
DataContent image (base64)	✅ forwarded as image/base64 block	✅ unchanged	✅ forwarded	delegates to SDK
DataContent application/pdf	❌ silently dropped	✅ forwarded as document/base64 block	⚠️ debug-logged and ignored	delegates to SDK
URIContent image URL	❌ silently dropped	✅ forwarded as image/url block	✅ forwarded	delegates to SDK
URIContent application/pdf URL	❌ silently dropped	✅ forwarded as document/url block	⚠️ debug-logged and ignored	delegates to SDK
HostedFileContent	❌ silently dropped	✅ explicit error returned	❌ no case (silent drop)	delegates to SDK

Assessment

This PR is a correctness fix, not a feature addition. Silently dropping multimodal content without an error is a bug in all SDKs, and Go is patching its own instance of that bug.

Two minor divergences exist relative to Python upstream:

1. PDF document forwarding — Go now forwards application/pdf DataContent and URIContent as Anthropic document blocks. Python currently logs and ignores these. Go is ahead of Python here, but in a clearly correct direction aligned with Anthropic Messages API capabilities. No upstream feature gate governs this; it is a provider-level implementation choice.

2. HostedFileContent error vs. silent drop — Go returns an explicit error (anthropic: hosted file references ... are not supported); Python has no case and silently drops. The explicit error is safer for callers and does not break parity — it improves observability.

Neither divergence represents a semantic regression or a missed feature gate. The PR description's claim that this matches Python semantics is slightly imprecise for PDF forwarding (Python ignores PDF today), but the Go behavior is correct.

Result: ✅ Parity approved. The PR fixes a bug in Go's multimodal content mapping and leaves Go in a correct and slightly more capable state than Python's current implementation. No cross-repo consistency issues require action. The parity-approved label remains appropriate.

Generated by Go API Consistency Review Agent · sonnet46 · 28 AIC · ⌖ 5.84 AIC · ⊞ 6K · ◷