improvement(providers): tighten Gemini and vLLM agent-attachment ceilings#5095
Conversation
…ings A live-doc audit of the merged large-file feature found two ceilings that were higher than the provider actually accepts: - Gemini: 100MB -> 50MB. Gemini hard-caps PDFs at 50MB, so a 50-100MB PDF passed our gate, got uploaded + polled, then failed at generateContent. 50MB respects the documented limit and is more memory-safe. - vLLM: 50MB -> 25MB. vLLM's default image-fetch timeout is 5s; a 50MB remote fetch routinely exceeds it. 25MB aligns with that reality and matches Baseten (the other vLLM-backed provider).
PR SummaryLow Risk Overview Google (Gemini) drops from 100MB to 50MB ( vLLM drops from 50MB to 25MB ( Reviewed by Cursor Bugbot for commit 98008a9. Configure here. |
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
|
@cursor review |
|
@greptile review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 98008a9. Configure here.
Summary
Follow-up to the provider large-file attachment feature (#5092). A live-doc audit of each provider surfaced two ceilings set higher than the provider actually accepts:
generateContent— wasted work and a confusing late error. 50MB respects the documented limit and is more memory-safe.VLLM_IMAGE_FETCH_TIMEOUTis 5s; a 50MB remote-URL fetch routinely exceeds it. 25MB aligns with that reality and matches Baseten (the other vLLM-backed provider).Every other provider's strategy and limit was validated as correct against live docs in the same audit; these were the only two worth tightening. The
/modelsprovider pages read these values dynamically, so they update automatically.Type of Change
Testing
NODE_OPTIONS='--max-old-space-size=8192' bunx tsc --noEmitcleanproviders/attachments.test.ts+providers/vllm/index.test.tspassChecklist