Jev Day images: TypeSafe-Danger-Zone-Images and the assets map

The images header and both model versions

Almeida writes that the Jev people already run was an image model the whole time, with images disabled because models tend to be less intelligent on other modalities. The header is TypeSafe-Danger-Zone-Images: true. The Images docs say a request that contains an image or a Box question without that header returns 400.

Jev 1.13 and Jev 1.14 both accept images once the header is set. Box questions need Jev 1.14. The models table still lists Input as Text. The blog says image support is composable through a find-and-replace in assets, and that models, including Jev, perform worse on multimodality than on pure text. Breaking questions into simpler pieces helps, in TypeSafe’s wording.

Sources:[148] Diogo Almeida[155] TypeSafe AI[34] TypeSafe AI[153] TypeSafe AI

Where an image can go

Each image is listed once in the request’s assets map. Its key is a reference string. You write that reference in state, in a question’s instructions, or in criteria, as a whole value or inside a longer string. Every asset must be referenced, or the API returns 400. Object keys are not replaced, so a Choice option name stays text; the picture goes in the option’s description.

The file is uploaded once. Each place the reference appears adds another copy of the image to what the model reads, and each copy counts toward the expanded-request limit. When several questions use the same picture, the docs say to put it in state once and refer to it by path. The Python and JavaScript SDKs create references for you. Python passes extra_headers={"TypeSafe-Danger-Zone-Images": "true"}. JavaScript passes { headers: { "TypeSafe-Danger-Zone-Images": "true" } } into systemOne.

Sources:[155] TypeSafe AI[153] TypeSafe AI

Formats, sizes, and billing

Formats are PNG or JPEG still images. Animated PNGs are rejected. Each file can be 16 MiB. Width and height must each be 256 to 1568 pixels, and the pixel area must fall between 78,400 and 2,458,624. A 256×256 image is too small. The request body limit is 32 MiB, including JSON, base64, and multipart framing. The API does not resize an image to fit; a rejected image fails the whole request.

The API strips EXIF, color profiles, and comments, and does not apply EXIF orientation, so a photo that looks upright in a viewer can reach the model sideways unless you rotate the pixels first. Multipart is the documented default over HTTP, because base64 makes each image about a third larger and that extra size counts toward the 32 MiB body limit. Image tokens are input tokens at the same per-token price as text. The Images page does not publish a formula for counting those tokens.

Sources:[155] TypeSafe AI

Dreamer-ready, and the older text-extraction path

The Images page labels images and Box as dreamer-ready: below TypeSafe’s production bar, meant for prototypes, with request format, answers, and limits able to change between releases. Accuracy will change as the models update. The blog says TypeSafe will not vouch for these headers on production use cases.

Workflows that turn a screenshot into OCR text, a filename, or a named color before the Jev call still run with the header off. Those reports stay on the Jev and images page. Native image input is the Jev Day path documented here.

Sources:[155] TypeSafe AI[153] TypeSafe AI

Questions