embeddings_input_too_many_items
HTTP status: 400
Type: invalid_request
When it fires
Theinput content-parts array on POST /v1/embeddings is over one of the pre-fetch safety caps:
| Limit | Cap |
|---|---|
| Total content parts per request (text + image_url combined) | 16 |
image_url parts per request | 8 |
video_url parts per request | 0 — rejected with embeddings_video_unsupported as of 2026-05-24 |
error.message echoes which cap was hit and the actual count you sent.
How to fix it
Split the work into multiple requests. Embeddings are independent — vectors from separate requests land in your index the same way; there is no fan-out mode that combines more than 16 parts into a single embedding. For a typical RAG-for-images workflow that wants one vector per image + caption, split by image:text parts (the 1M-character per-text-part cap is generous enough for most concatenations).
Why a cap exists
A multimodal embedding fans out into one model call that fetches every URL, tokenizes every part, and produces one vector. Removing the cap would let a single request consume arbitrary upstream budget — the platform sets a deterministic ceiling so a single misformed request can’t blow up a job. The same caps drive the cost projection in/v1/embeddings/estimate, so estimates are bounded.
Example response
Related
- Multimodal — the input shape and the full caps table.
embeddings_video_unsupported— video input is no longer accepted (2026-05-24).- Embeddings overview
- Errors

