Azure GPT-Image-2 vs OpenAI GPT-Image-2: Which API Route Should You Deploy?

Azure GPT-Image-2 and OpenAI direct gpt-image-2 are not two unrelated image models. They are two ways to operate the OpenAI model family, with different endpoints, credentials, deployment controls, billing owners, quotas, and support paths.

Choose Azure OpenAI when an Azure subscription, Microsoft billing and support, Microsoft Entra ID, Azure resource governance, or a specific Azure deployment geography is a requirement. Choose OpenAI direct when you want the shortest path to the OpenAI API, OpenAI's own pricing and usage tiers, and direct output controls such as WebP.

Do not choose from one sample image or a copied per-image price. First identify the contract your production system must satisfy, then test the exact account, region, deployment, and request shape you will ship.

The route decision in one table

If one row is mandatory, it usually decides the route. When none is mandatory, OpenAI direct is the simpler baseline. Azure becomes valuable when its operational owner—not the model name—solves a real enterprise constraint.

One model family does not mean one production contract

Microsoft's current Azure image-generation guide lists GPT-Image-2 as generally available. OpenAI's GPT Image 2 model page identifies the direct model as gpt-image-2 and currently lists snapshot gpt-image-2-2026-04-21.

That establishes the model identity on both platforms. It does not establish byte-identical outputs or contract parity. A request still passes through a platform-specific endpoint, authentication layer, quota system, content-safety configuration, release process, logging surface, and billing account. Treat those differences as production inputs, not administrative details.

The shared model controls are still substantial. Both current guides document text and image input, generations and edits, quality choices, flexible GPT-Image-2 dimensions, and base64 output. The published size contract allows both edges to be multiples of 16, a maximum edge of 3,840 pixels, an aspect ratio no greater than 3:1, and a total pixel count from 655,360 to 8,294,400.

But even a shared parameter needs route verification. OpenAI direct currently documents auto as a quality option and supports WebP. Azure documents low, medium, and high, says its default is high, and lists PNG/JPEG only. If your asset pipeline requires WebP, include conversion in the Azure architecture instead of assuming parameter parity.

Compare the request you will actually run

The easiest migration error is to change only the base URL. Azure also needs a deployed model and uses that deployment name in the request. OpenAI direct uses the model ID.

An Azure generation request on the current documented v1-style surface has this shape:

bash
curl "https://YOUR-RESOURCE.openai.azure.com/openai/v1/images/generations?api-version=preview" \
  -H "api-key: $AZURE_OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR-GPT-IMAGE-2-DEPLOYMENT",
    "prompt": "A white desk lamp on a neutral studio background",
    "size": "1536x1024",
    "quality": "medium",
    "output_format": "png"
  }'

The direct OpenAI request has a different owner and model selector:

bash
curl "https://api.openai.com/v1/images/generations" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2",
    "prompt": "A white desk lamp on a neutral studio background",
    "size": "1536x1024",
    "quality": "medium",
    "output_format": "webp"
  }'

Copy the live documentation when you implement. Azure's generation and edit examples do not use one timeless URL pattern: the current generation guide shows a v1 route with api-version=preview, while the edit section documents a deployment path and an explicit API version. A model being generally available does not make every surrounding API path versionless.

For both routes, decode the returned b64_json, store the file, preserve the request ID, and record the route owner. A base64 response is not a durable asset until your application writes it to controlled storage and attaches retention and access rules.

Price the owner, not the model label

OpenAI publishes a direct token contract. On August 5, 2026, the OpenAI pricing page lists standard GPT-Image-2 image input, cached image input, and image output at $8, $2, and $30 per one million tokens; text input and cached text input are $5 and $1.25 per one million tokens. Its image cost calculator currently estimates a 1024×1024 output at $0.006 low, $0.053 medium, or $0.211 high before applicable input costs.

Those are OpenAI-direct figures, not Azure prices. Azure's Azure OpenAI pricing page identifies GPT-Image-2 as token-priced, but the amount you should use belongs to the selected currency, agreement, region, deployment type, and current Azure pricing view. Do not paste the OpenAI direct table into an Azure business case.

Use one cost worksheet per route:

text
request cost = text input + reference-image input + generated-image output

accepted-output cost =
  (all billed requests + storage/egress + required conversion + repair work)
  / outputs accepted for production

The second line matters. Azure may fit an existing enterprise agreement and reduce operational friction even when a public unit price looks higher. OpenAI direct may avoid Azure deployment and format-conversion work even when the raw generation price is similar. Neither conclusion is universal.

Quota and availability must be checked in the live account

Azure's public documentation currently gives two different default-limit descriptions for GPT-Image-2: the image guide says 5 images per minute per deployment, while the general quotas and limits reference lists 9 requests per minute. That conflict is itself the useful fact: do not design capacity from a copied default.

Open the Azure quota view for the exact subscription, region, model, and deployment type. Then run a bounded concurrency test and record successful requests, throttles, latency, and the returned limit headers or portal values. For OpenAI direct, inspect the current project tier and the model's current rate-limit table. Free-tier support and paid-tier limits are explicit on the model page and can change with account tier.

Availability needs the same treatment. Microsoft says availability varies by region and cloud. OpenAI offers its own project and data-control options to eligible customers. “Azure has regions” and “OpenAI supports data residency” are starting points, not proof that your desired image endpoint, organization, and data path satisfy a legal or security requirement.

Run a migration proof before moving production traffic

Use a small, auditable proof rather than a visual beauty contest:

1. Lock identity. Record provider, resource or project, requested model/deployment, returned model metadata where available, endpoint, API version, and region.
2. Lock the input. Use the same prompt, licensed reference image, size, quality, and number of outputs. Document controls that cannot be matched.
3. Verify the response contract. Decode base64, confirm actual dimensions and MIME type, store the image, and preserve the request ID.
4. Verify the hard requirement. Test Entra ID or project-key rotation, private network path, WebP conversion, regional routing, or whichever condition caused the evaluation.
5. Measure limits. Run only the concurrency needed for your planned workload; record throttles and retry headers rather than assuming a default.
6. Reconcile cost. Compare the Azure cost view with the Azure request log, and the OpenAI usage view with OpenAI request IDs. Keep failed attempts and edit-input tokens in the denominator.
7. Prove rollback. Keep the old route available until the new route passes identity, storage, moderation, latency, cost, and output checks.

A visual difference in one output does not prove the platform changed the model. Random generation, unpinned aliases, moderation behavior, unmatched parameters, and different request paths can all change the result. If visual parity matters, compare multiple outputs under matched conditions and report the route settings with the result.

Choose the route that owns your hardest constraint

Use Azure OpenAI when Microsoft-owned procurement, Azure resource governance, Entra identity, Azure monitoring, or a verified Azure deployment location is the reason the workload can ship. Accept the additional resource, deployment, quota, API-version, and format work as part of that choice.

Use OpenAI direct when the official OpenAI API is allowed and operational simplicity is the main requirement. You get the direct model identity, current OpenAI pricing and tier controls, and the broader documented output-format choice. You still need project isolation, key rotation, spend limits, storage, moderation handling, and a verified data-control policy.

Do not migrate merely because both routes contain the text gpt-image-2. Migrate when the target route satisfies a requirement the current route cannot, and when the proof sheet shows that the target can deliver your real request safely and predictably.

For the direct implementation details, continue with the GPT-Image-2 API guide. For Azure, keep the Microsoft image-generation guide, model availability documentation, and your own subscription's quota and pricing views open while deploying.

The next action is simple: write down the one requirement that would reject either route, then run one low-cost request in the exact account and region you intend to operate.