Skip to main content
Code: embeddings_input_too_many_items HTTP status: 400 Type: invalid_request

When it fires

The input content-parts array on POST /v1/embeddings is over one of the pre-fetch safety caps: The platform applies these caps before fetching any media or calling the model — the request fails fast at the DTO boundary so you don’t pay for over-budget calls. The 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:
For a use case that really does want one combined vector from many parts — e.g., embedding a long mixed-media document — trim to the 16-part / 8-image cap by combining text fragments into fewer, longer 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

No credits are charged for a request rejected at the DTO boundary.