dg / ai-access / 31435588554

93%

Build Type

push

github

Committed by dg

Commit Message

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: getResults()
keeps working untouched, a failed request still arrives as a failure, 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 ... (continued)

Coverage Stats

185 of 189 new or added lines in 14 files covered. (97.88%)

43 existing lines in 9 files now uncovered.

2173 of 2343 relevant lines covered (92.74%)

0.93 hits per line