dg / ai-access / 31430808519

93%

push

github

images: a batch of pictures is an ordinary batch

An image request is now an object, exactly as a chat is: createImageRequest()
builds it, setOptions() configures it in the provider's own vocabulary, and
generateImage() stays as sugar over it. That is what makes batching possible
without a second way of shaping the same payload, because the batch submits the
very shape a live call sends.

The result needs no new type either. Media was already a chat part, so a drawn
answer is a Message of Role::Model whose parts are the pictures: getMessages()
keeps working untouched, per-item errors stay where they were, and asking for
several pictures is simply several parts in one message. Message::getMedia() is
the counterpart of getText(). Batching images is a service interface of its own
rather than a method on Batch\Batch, because no provider lets one job mix
pictures and chats, and Claude would otherwise have to declare a capability it
does not have.

OpenAI declares one endpoint for a whole job, so requests with references and
requests without them cannot share a batch, and BatchResponse picks its parser
from that endpoint. References travel as base64 data URLs in a JSON body rather
than as multipart, which a JSONL line cannot carry; the live edits call uses the
same JSON form now, because two transports for one payload would drift apart. A
reference already uploaded through the Files API can be pointed at by id
instead, which keeps a repeated image out of every line. The mime type is read
from the answer rather than guessed from the request, and a 200 carrying no
picture is reported as an error rather than as an empty message.

Gemini has no image endpoint at all, so an image batch is an ordinary
batchGenerateContent job with responseModalities in each request. Its newer
Interactions API is the recommended path for pictures but has no batch, which is
why generateContent stays. Consequently the response parser keeps inlineData
parts as Media instead of droppi... (continued)

196 of 201 new or added lines in 14 files covered. (97.51%)

2142 of 2309 relevant lines covered (92.77%)

0.93 hits per line