dg / ai-access / 31492215055

93%

master: 93%

Build Type

push

github

Committed by dg

Commit Message

images: a batch of pictures is an ordinary batch

An image request became an object, one final class per provider, holding the
prompt, the references and the provider's own options. The live call and the
batched one build the very same payload from it, which is the whole reason it
exists; `generateImage()` remains the only way to ask for a picture now and takes
every option the provider has as a named argument, so there is no second, wordier
route to the same thing.

Queueing one is `addImageRequest()` on `OpenAI\Batch` and `Gemini\Batch`. Not
`addImage()`: `Media` is what this library calls input, pictures go into a
conversation that way, so a method of that name will one day mean attaching one,
and the two would read as opposites. And not on the shared `Batch\Batch`
interface either, because Claude cannot draw and should not have to say it can;
extra capability belongs on the concrete class, the same door Claude's own
per-request models would use.

The result needs no new type. `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, and asking for several is simply several parts in one message.
`Message::getMedia()` is the counterpart of `getText()`.

What may share a job is the provider's rule and only OpenAI has one: it declares a
single endpoint for the whole job, so pictures cannot ride with chats and
generating cannot ride with editing, which `submit()` enforces as one rule over
the urls the requests map to. One model per job holds for both providers, and is
measured rather than read: a mixed-model batch is accepted, then killed whole
during validation with `mismatched_model`, so the second model is refused where it
is added. Gemini has no endpoint rule at all, and a job carrying a text request
and an image request answered both, so the library allows it.

References travel as base64 data URLs in a JSON body rather than as multipart,
which a JSONL l... (continued)

Coverage Stats

170 of 173 new or added lines in 12 files covered. (98.27%)

19 existing lines in 4 files now uncovered.

2164 of 2323 relevant lines covered (93.16%)

0.93 hits per line