Sending Images, Audio, Video and PDFs

The exact part shape for every media type, the size limits, and how to slice a long recording so it is not rejected.

Media is sent as content parts inside a user message, exactly as in the OpenAI schema. The provider accepts both the raw OpenAI spellings and a canonical file part, so a client written against OpenAI needs no changes.

⚠

Read this before sending large files

One request carries at most 12 media parts and a body under 40 MB. Base64 encoding adds about a third to a file's size, so a 30 MB video becomes ~40 MB on the wire. Compress and slice before you send; do not send a single huge part and expect the server to sort it out.

Images

json

{
  "role": "user",
  "content": [
    { "type": "text", "text": "What is in this image?" },
    {
      "type": "image_url",
      "image_url": { "url": "data:image/png;base64,<BASE64>" }
    }
  ]
}

Audio

Audio uses the input_audio part: data is base64 (no data-URL prefix) and format names the container.

json

{
  "role": "user",
  "content": [
    { "type": "text", "text": "Transcribe and summarise this recording." },
    {
      "type": "input_audio",
      "input_audio": { "data": "<BASE64>", "format": "mp3" }
    }
  ]
}

⚠

Never send long audio as WAV

Uncompressed mono 16 kHz WAV is about 115 MB per hour — larger than the source for anything already compressed, and guaranteed to be refused. Transcode to low-bitrate mono MP3 or AAC first. A one-hour talk at 48 kbps mono MP3 is roughly 21 MB.

Video

Video uses a video_url part. Because a real video quickly exceeds one request, the intended pattern is to compress it, cut it into ordered slices of a few megabytes, and send the slices as separate parts in playback order. The model is told to treat ordered slices as one continuous recording.

json

{
  "role": "user",
  "content": [
    { "type": "text", "text": "Summarise this clip." },
    { "type": "video_url", "video_url": { "url": "data:video/mp4;base64,<SLICE 1>" } },
    { "type": "video_url", "video_url": { "url": "data:video/mp4;base64,<SLICE 2>" } }
  ]
}

★

How to slice a video

Compress first with H.264 at a bitrate sized to the length, then cut with stream copy (-c copy) so slicing is fast and lossless. The provider's own client does exactly this: it sizes the bitrate to the duration, then cuts into near-equal ordered slices.

PDFs and other documents

json

{
  "role": "user",
  "content": [
    { "type": "text", "text": "Summarise this contract." },
    {
      "type": "file",
      "file": { "filename": "contract.pdf", "file_data": "data:application/pdf;base64,<BASE64>" }
    }
  ]
}

Limits, in one place

Limit	Value	What happens past it
Media parts per request	12	Extra parts are dropped; the response still succeeds. Trim client-side and tell your user.
Request body	40 MB	The request is refused with 413 and `type: payload_too_large`.
Messages per request	48 (most recent kept)	Older turns are dropped so a long history cannot grow unbounded.
Image / PDF raw size	2 MB inline	Compress or downscale before sending.

ℹ

Large media is sliced, not rejected

The ZYRAXON desktop and web clients compress and slice on the client before sending, so a long recording arrives as several ordered parts rather than a single refused upload. If a file is so long that even the lowest usable bitrate will not fit one turn, the leading parts are sent and the remainder is reported to the user — never dropped silently.

← Previous

The Ten ZYRAXON Models

Tool Calling