Use NanoGPT Image Models in OpenAI-Compatible Clients
Many apps and developer tools already know how to generate an image through an OpenAI-style API. The hard part is usually getting the client and the image service to agree on routes, request fields, model names, and response formats.
NanoGPT now provides OpenAI-compatible image routes so those clients can use NanoGPT's image catalog without needing a separate integration for every model.
For most compatible clients, the setup comes down to three changes:
- Use NanoGPT's API base URL.
- Add a NanoGPT API key.
- Choose a supported NanoGPT image model.
Those three changes are often enough for an existing script, automation, or image client to start generating through NanoGPT.
What OpenAI-compatible means here
Here, OpenAI-compatible refers to the API structure that OpenAI-style clients expect. Individual image models still have different features.
The main OpenAI-style image routes are:
POST /api/v1/images/generationsfor creating imagesPOST /api/v1/images/editsfor editing images
NanoGPT also provides GET /api/v1/images/models as a discovery endpoint for listing available image models and their capabilities.
There is also POST /api/v1/images as a shorter generation route and /api/v1/images/edit as an edit alias.
Clients still need to support a custom API base URL and custom model names. If an app is locked to one service or only allows a fixed list of models, changing the API key alone will not be enough.
A small Python example
If you already use the OpenAI Python SDK, the important change is the base URL:
import base64
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["NANOGPT_API_KEY"],
base_url="https://nano-gpt.com/api/v1",
)
result = client.images.generate(
model=os.environ.get("NANOGPT_IMAGE_MODEL", "gpt-image-1"),
prompt="A quiet reading room inside a glass greenhouse, editorial photography",
)
image = result.data[0]
with open("image.png", "wb") as file:
file.write(base64.b64decode(image.b64_json))
The same idea applies to other OpenAI-compatible clients: set the base URL to https://nano-gpt.com/api/v1, provide your NanoGPT key, and select an image model the client can send as a custom model ID.
Do not put a NanoGPT API key directly into shared code, committed files, browser JavaScript, or mobile apps. Use an environment variable, a server-side proxy, or the client's secure credential settings.
Image editing works through standard client flows
OpenAI-style clients commonly send image edits as a multipart upload: an image file, a prompt, and a model name. NanoGPT accepts that format through the image edit route.
For example, a client can upload an existing product photo and ask for a background change, or send an illustration and ask for a different color palette.
Standard OpenAI clients usually send one reference image and an optional mask. Some NanoGPT models support several reference images, but the client or SDK must also support multi-image uploads. Otherwise, use a custom request for that workflow.
For custom integrations, NanoGPT also accepts JSON image-edit requests for images stored as URLs or data URLs. Only send images you are allowed to process, avoid putting secrets in fetchable URLs, and remember that a logged data URL can contain the full image.
Not every image model supports editing. Some are text-to-image only, while others support image-to-image changes, inpainting, or multiple references. Check the model information before building a workflow around a specific capability.
Discover image models without maintaining your own list
Image catalogs change quickly. New models arrive, prices change, and supported sizes differ.
The live image-model endpoint helps clients and integrations avoid relying on an old hard-coded list:
curl https://nano-gpt.com/api/v1/images/models
The detailed response can include:
- Model ID and display name
- Whether the model supports image editing
- Supported resolutions
- Maximum output images
- Input-image limits and constraints
- Available rendering speeds
- Current public pricing
Each listed model also links to its own endpoint metadata. That gives more detail about the parameters, capabilities, and pricing available for that model.
This is useful for a client that wants to populate a model picker, hide unsupported controls, or estimate cost before sending a request.
Different models still need different settings
Compatibility removes a lot of integration work, but it does not make every model behave the same way. Supported resolutions, output counts, rendering speeds, edit features, reference-image limits, and prices can all differ. Image generation is also non-streaming: the client waits for the completed result rather than receiving the image piece by piece.
By default, responses contain base64 image data in b64_json. Send response_format: "url" to request a hosted image URL instead. A reusable client should still be prepared to handle either.
When something fails, first check that:
- The client is using the NanoGPT base URL.
- The API key is valid and has enough balance or subscription access.
- The model ID comes from the current image-model list.
- The chosen model supports the requested operation and settings.
- The client is actually calling an image endpoint, not only a chat endpoint.
An app can describe itself as OpenAI-compatible while supporting only chat completions. NanoGPT's image compatibility routes cannot add an image interface to a client that never makes image requests.
Why this is useful
The main benefit is choosing models without a complete rewrite.
You can keep a familiar SDK or client while changing the image model behind it. A small automation can try a faster model for drafts and a higher-quality model for final output. An internal tool can read the live catalog instead of shipping a new release whenever a model is added.
Model differences are still there — the API gives clients a standard way to discover them and send the right request.
Create an API key on the NanoGPT API page, browse image models on the Media page, or inspect the live image-model API.