Activity

1. JeffPsymot

   closed this as completedon Sep 14, 2026
2. github-actions

   assigned

   jlongster

   on Sep 14, 2026
3. JeffPsymot

   reopened this on Sep 14, 2026
4. github-actions commented on Sep 14, 2026

   

   github-actionsBot

   on Sep 14, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • /file/content?path=xxx.pdf http api Cannot read PDF file #37011: PDF file cannot be read via the HTTP API
   • pdf: multiple PDF reads accumulate images exceeding provider limit, causing unrecoverable error #48781: Multiple PDF reads accumulate images exceeding provider limits, causing errors

   If your issue is distinct from these, please add more context about the specific error path.
5. JeffPsymot commented on Sep 14, 2026

   

   JeffPsymot

   on Sep 14, 2026

   Author

   More actions

   Open Code version 1.18.30
   System : Linux Mint
6. jlinazasoro commented on Sep 15, 2026

   

   jlinazasoro

   on Sep 15, 2026

   More actions

   I reproduced this, and I believe the diagnosis in the description points at the wrong variable. It isn't about the PDF containing an image — it's the transport opencode uses.

   Both PDFs you attached contain zero embedded images (pdfimages -list returns 0 rows for each), and both still fail. Holding everything else constant and changing only the transport:

   Your attachment	file_data (what opencode sends)	file_id (upload first)
   PDF Failed to parse.pdf (Quartz/macOS, 0 images)	400 1210	200 — "Es un currículum vitae (CV) en francés…"
   PDF Failed to parse - Libre office created.pdf (LibreOffice 24.2, 0 images)	400 1210	200 — reads "Test d'un pdf produit par…"

   Same bytes, same API key, same model, same minute.

   Why. Z.AI's OpenAPI for POST /paas/v4/chat/completions (VisionMultimodalContentItem → File) documents three members of file, and attaches the supported-format list — "Supports formats such as pdf, txt, word, jsonl, xlsx, pptx" — only to file_url. file_id is documented as GLM-5.3-Flash-only. file_data declares no format list at all.

   @ai-sdk/openai-compatible hardcodes application/pdf → file_data:

   if (part.mediaType === "application/pdf") {
     return { type: "file", file: {
       filename: part.filename ?? "document.pdf",
       file_data: `data:application/pdf;base64,${convert(part.data)}` }}
   }

   That is the one PDF route Z.AI rejects. Upload endpoint is POST /paas/v4/files, multipart, purpose=user_data — note purpose=agent also returns 1210, so the purpose matters.

   Full transport matrix, spec citations, controls ruling out thinking / max_tokens / account / network, and a minimal key-free repro are in #49237. Same root cause as #48868, which shows this is not zai-specific: the identical file_data mapping also breaks the opencode-go / zen gateway, there with a 422.

   Two follow-ups on your report:

   • "one pdf is correctly accepted by GLM API via OpenCode" — I could not get any PDF to succeed over file_data, including a 615-byte one I generated with no images. If you still have that file, it would be genuinely useful to know whether it went through file_data or took another path. That's the one observation my model doesn't explain.
   • Your "poisoned session" observation is correct and structural. The attachment is stored in state.attachments on the tool part and replayed on every later turn, so a single rejected PDF keeps failing the session until it's removed from the DB. [Bug] 422 "messages.N.user.content.str: Input should be a valid string" when replaying a session containing a PDF tool result on OpenAI-compatible providers (opencode-go / zen gateway) #48868 documents the same behaviour on a different provider.

   Worth noting the diagnosis in the description was attributed to "GLM analysis" — asking the model to explain its own API error. That's how the image hypothesis got in; the attachments disprove it.
7. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
8. thdxr

   closed this as not plannedon Oct 11, 2026