Overview
GoModel exposes the OpenAI-compatible image generation endpoint. Clients and
SDKs that already call OpenAI’s /v1/images/generations can point at GoModel
unchanged.
Requests route by model through the same registry used for chat and
embeddings, so model selection, provider hints, virtual models, per-key model
access rules (user paths), budgets,
and rate limits all apply. Image generation is served by
OpenAI and the OpenAI-compatible providers that implement the endpoint
(Azure OpenAI, OpenRouter, xAI). A provider without image
support returns a clear model "…" does not support image generation error
rather than mis-routing, and image-only models are hidden from /v1/models for
such providers.
Supported endpoints
Generate an image
model and prompt are required. Every other field — n, size, quality,
style, response_format, background, output_format, output_compression,
moderation, user, and any future parameter — is forwarded to the provider
unchanged, so model-specific options work without a gateway update. The
provider decides which values it accepts and returns its own error otherwise.
The response is the OpenAI images envelope. data[] entries carry either a
hosted url (DALL·E, response_format: "url") or inline b64_json
(gpt-image-1 always returns base64). GoModel adds a provider field naming the
provider type that served the request; everything else is passed through,
including the usage block and echoed output parameters gpt-image-1 reports.
Use a provider/model selector (for example "model": "openai/dall-e-3") or
the "provider" hint when the same model ID is configured on several
providers, exactly as with chat.
Cost tracking
Image calls are recorded in usage tracking under the
/v1/images/generations endpoint:
- Token-billed models (
gpt-image-1 and similar) report usage in the
response; GoModel stores the input/output token counts and prices them with the
model’s input_per_mtok / output_per_mtok rates.
- Per-image models (DALL·E,
grok-2-image) report no tokens. GoModel records
the number of returned images (images in the raw usage data) and prices it
with the model’s per_image rate.
Set per_image through a pricing override
or in config.yaml when the model catalog has no price for an image model:
Limitations
The images endpoint is a thin, model-routed pass to the provider and does not
run through the full inference orchestrator. Compared with /v1/chat/completions:
- No failover, guardrails, or response cache — these stages are skipped.
Requests are still authorized, budget-checked, rate-limited, metered, and
written to the audit log.
- No streaming —
stream: true is rejected with a 400 because streamed
image generation is delivered as server-sent events, which this endpoint does
not relay. Omit stream (or set it to false) to receive the complete JSON
response.
- Edits and variations (
/v1/images/edits, /v1/images/variations) are not
exposed. Use the passthrough API
(/p/{provider}/v1/images/...) to reach them on a specific provider.
- OpenAI request shape in, OpenAI-compatible providers out — providers whose
native image API differs from OpenAI’s (for example Gemini Imagen) are not
translated behind this endpoint; use passthrough for those.
Audit logging
Image requests appear in the audit log like any other model interaction. When
LOGGING_LOG_BODIES is enabled the JSON request and response are captured;
responses larger than the 1 MB capture limit (typical for b64_json output)
are stored truncated and flagged response_body_too_big_to_handle.
