Skip to content

Image generation

Myra AI Workspace can generate an image from a text description and edit an image the user uploaded. Both are exposed to the model as a single generate_image tool: when a user asks the assistant to create, draw, or illustrate something — or to change, recolor, or restyle an image they just attached — the model calls the tool, the gateway renders the image with a self-hosted, EU-hosted model, and the result is shown inline in the chat.

  • Text-to-image: a prompt produces a new image.
  • Image-to-image (editing): an uploaded image plus a prompt produces an edited image (for example "make the car red", "turn this into a watercolor"). The edit preserves the source image's dimensions.

Both directions run entirely on EU-hosted infrastructure (no third-party image provider) — including the uploaded source image, which is sent only to the same EU-hosted model as text prompts — satisfying EU data-residency requirements.

How it works

  1. The gateway advertises a generate_image tool to the model when the gateway has image generation enabled and the client signals support with the x-aig-image-gen request header (the web chat always sends it; accepted values and the rejection rules are in the inference API reference). With image generation disabled on the gateway the tool is withheld from the model regardless of the header, so the model cannot call it.
  2. When the model calls generate_image with a prompt (and an optional size), the gateway sends the prompt to the EU-hosted image model and receives a PNG. When the model sets edit_uploaded_image: true, the gateway instead takes the image the user attached to their latest message, sends it together with the prompt to the model's edit endpoint, and receives the edited PNG.
  3. The image is stored and linked to the assistant message that produced it; the tool returns only a short status string to the model (the raw image is never placed in the model context).
  4. The client renders the image inline in the assistant's reply and offers a full-resolution view.

Image-to-image (editing) requires the user to attach an image to the same message that asks for the edit. The model decides to edit from the user's request — it does not need to see the image. A non-vision model receives the attached image as a text description and is told the system still holds the original, so it can call generate_image with edit_uploaded_image: true; the gateway then forwards the original attached image (not the description) to the EU-hosted image model for the edit.

Enabling it

Gateways created via self-service signup enable image generation by default (using flux.2-dev, the self-hosted EU model), so a fresh self-serve gateway is ready to generate images with no extra setup. You can turn it off — or change the image model — per gateway from the admin UI: Gateways → select the gateway → Edit → Image Generation → untick/tick "Enable image generation" (change the model only if a different image model is deployed) → Save. The gateway overview shows an Image Gen status card reading on or off. Config changes are picked up within about a minute (gateway configuration is cached briefly).

Once enabled, the /easy chat surface supports it automatically — no client changes are required. The model decides when to call the tool based on the user's request (ask it to create, draw, or generate an image); it is not invoked for ordinary questions. Only a tool-capable model on the gateway will invoke it — a model that does not support tool calls will describe the image in words instead of generating one.

Image generation is not available to scheduled or automated agent runs.

Tool contract

The model-facing tool accepts:

Field Type Required Notes
prompt string yes For a new image: the description. For an edit: the change to apply. Up to 4000 characters (longer is rejected). Must be non-empty. An edit with an empty prompt is rejected (no image is produced) — it usually means the request was a question about the image, not an edit; the model is told to answer in text or state the specific change.
size string no Output size for a new image: one of 256x256, 512x512, 1024x1024 (default), 1024x1792, 1792x1024. Any other value falls back to the default. Ignored when editing (the edit keeps the source image's dimensions).
edit_uploaded_image boolean no When true, edit the image attached to the user's latest message instead of generating a new one. Accepts the boolean true, the number 1, or the strings "true"/"1"; any other value (including false) means text-to-image.

Validation and limits (all enforced server-side):

  • A request is rejected only when it has neither a saved conversation nor a live-delivery channel. A turn that can deliver live (as the chat UI always can) still receives the image even for an unsaved conversation — it is delivered but stored nowhere (see Data lifecycle below).
  • At most 4 images per turn are produced (across both generation and editing); further calls in the same turn are rejected.
  • Editing — the uploaded source image (untrusted, client-supplied) is accepted only when it is present in the user's latest message as a base64 data: image URL, decodes successfully, is at most 12 MB, and is a PNG or JPEG (verified by the file's magic bytes, not the client-declared MIME type). Remote (http(s)) image URLs are ignored — the gateway never fetches them. If the latest message has no such image, the tool tells the model to ask the user to attach one. The content type sent upstream is derived from the detected magic bytes.
  • The image returned by the model is accepted only if it is a valid PNG and at most 12 MB; anything else is rejected and nothing is stored.
  • The stored image's content type is always image/png (never taken from the upstream response).

When generation or editing fails, the tool returns an error message to the model rather than an image, and the assistant continues the turn. Editing distinguishes an invalid/unsupported uploaded image (the model is told the image could not be edited) from a temporarily unavailable service (a transient upstream failure).

Retrieving a generated image

Each assistant message that produced images carries an images array of { id, mime_type, size }. The bytes are fetched by id:

GET /admin/v1/conversations/<conversation-id>/images/<image-id>

The response is JSON { id, mime_type, size, data } where data is base64-encoded PNG bytes. Access is scoped to the caller's own conversation and to images belonging to that conversation; a mismatched image id returns 404.

Data lifecycle

Generated images are stored with their conversation and are deleted when the conversation (or the owning account) is deleted, including under a GDPR Art. 17 erasure. Images generated during a turn that is never persisted (for example, the user navigates away mid-stream) are swept by a periodic reaper. An image delivered live in a private (ghost) conversation is never stored in the first place — there is nothing to reap, and it is gone when the conversation is left.