feat(open_ai): image content parts, response_format and token limits

[MrYuion]

Changes

Message.content is now String | Array(Content) — either plain text, or a list of typed TextContent / ImageContent parts.

Images are supplied as base64 and sent to OpenAI inline as a data URI, so the driver never hands the API a URL to fetch:

{"role": "user", "content": [
  {"type": "text", "text": "what is in this image?"},
  {"type": "image_url", "image": "iVBORw0...", "media_type": "image/png"}
]}

ImageContent also parses the data URI form it emits, so it round trips its own output across the exec boundary. A payload with no base64 data (a bare https:// URL) raises JSON::ParseException.

CreateChatCompletion gains optional response_format and max_completion_tokens, both exposed as arguments on chat.

Encoded blobs are kept out of the logs — redact_blobs strips any 256+ character run of base64 / hex from the request body before it is logged. The real payload still goes out on the wire:

{"type":"image_url","image_url":{"url":"data:image/png;base64,<binary data redacted>"}}

Backwards compatibility

Wire format and settings are unchanged for existing callers:

• CreateChatCompletion.new(model, messages) with string content serializes byte-identical to before — the new fields are nil and are skipped.
• Old settings ([{"role": "user", "content": "a string"}]) still deserialize; voice_control's custom_prompts is unaffected.
• Responses parse and re-serialize unchanged, so exec callers of chat see the same shape.

One caveat for Crystal callers: code treating Message#content as a String no longer compiles against the union. Nothing in this repo does; Message#text is the drop-in replacement.

Testing

./harness report drivers/open_ai/gpt.cr — 1 tested, 0 failures. Specs cover the image + text part request, response_format / max_completion_tokens, omission of both when unset, and the plain string path.

🤖 Generated with Claude Code

[stakach]

LGTM