AI SDK v5 Image Parts much slower response time than v4 experimental_attachments

[rngyn]

I recently upgraded from v4 to v5 and it unfortunately really impacted the performance of my application. My application relies heavily on image analysis and prompts may include upwards to 20 images. In v4, these images were attached as part of "experimental_attachments" and response time was fairly acceptable. The first chunk arrival and render was good.

However since upgrading to v5 and using image parts in messages to include the images, the same images could delay the response time by upwards to 15x! This has severely impacted the performance of my application.

Was there a fundamental architectural change between experimental_attachments and image parts? It looks like experimental_attachments was separate from the messages, and therefore was out-of-band, possibly unblocking and lazily used for the LLM and could respond quickly. However now that images are part of the messages, it seems to be a first-class citizen now and blocking?

Can someone explain this to me, and a possible work around? Do I have to implement a tool for dynamic image fetching now?

Thank you.

[rngyn]

Is this a difference in Completions API vs Responses API?

[ahuaiqom]

Hi @rngyn 👋

Why v5 feels slower:
In AI SDK v5, image parts are “first-class”. The SDK typically fetches each image URL and attaches the bytes (or base64) before it calls the model. With 10–20 images that adds upfront download time and blocks the request.
In v4, experimental_attachments were largely out-of-band (URL references) so the model/provider could fetch lazily or in parallel—hence the faster first token.

**Practical workarounds

1. Send provider-fetchable URLs (don’t inline bytes)**

• Host images on a fast CDN.

• Pass URL parts (not data URLs/blobs) for providers that accept image_url so the provider fetches directly.

• Avoid huge originals—use WebP/JPEG, resize to the model’s useful resolution.

2. Prefetch & cache outside the call

• Warm the CDN and/or precompute smaller derivatives.

• If you must inline bytes (some providers require it), download in parallel before the model call and reuse a cache:

ts
const urls = [...]; // 20 images
const blobs = await Promise.all(urls.map(u => fetch(u, { cache: 'force-cache' }).then(r => r.blob())));
const parts = blobs.map(b => ({ type: "image", image: b })); // then call the model

3. Reduce the count/detail

• Send fewer frames/pages.

• Use thumbnails or low/detail equivalents when the task allows.

4. Stream the response

• Even if images must be fetched first, using the SDK’s streaming APIs improves perceived latency once the model starts generating.

About Completions vs Responses

This isn’t mainly an API difference; it’s about where images are resolved:

If the provider accepts URLs and fetches server-side, first-byte can be faster (no local downloads).

If the SDK has to attach bytes, v5 will download all images up front (one reason for the 10–15× slowdown you saw).

TL;DR

Make images URL-based + CDN when possible; if bytes are required, prefetch in parallel and shrink them. v5’s “image parts” are blocking because the SDK resolves assets before sending the request.

[github-actions[bot]]

This discussion was automatically locked because it has not been updated in over 30 days. If you still have questions about this topic, please ask us at community.vercel.com/ai-sdk