# MiniMax H3-Image API: Pricing, Size Errors and Safe Retries

H3-Image supports generation and editing, but its size settings and batch responses need careful handling before you put it behind a product.

By Paras Madan | 2026-11-11


MiniMax H3-Image is available for image generation and editing through MiniMax's API. The useful integration question is how to request the right dimensions, calculate a realistic cost and avoid paying twice when a request times out. Those details matter more than a successful demo request.

MiniMax's [November 11 announcement](https://www.minimax.io/blog/minimax-h3-image) also releases model weights and promotes native high-resolution generation. This guide covers the hosted API from its documentation, not a hands-on quality or latency test. Claims about speed should remain separate from the error handling your application needs.

## H3-Image pricing is token-based

The [official pricing page](https://platform.minimax.io/docs/pricing/overview) bills text input, image input and image output separately. Standard H3-Image costs $2.30, $1.50 and $3.80 per million tokens respectively. Highspeed keeps the text rate but doubles the image rates to $3 and $7.60.

MiniMax illustrates standard text-to-image costs of $0.02179 for 1024 × 1024 and $0.02333 for 2048 × 2048. Its 4096 × 4096 example is normally $0.06879, temporarily $0.03439. These are estimates, not fixed per-image prices: prompt enhancement contributes text tokens.

The promotion halves total request cost when the delivered image contains at least 16,600,000 pixels. It ends November 17, 2026 at 16:00 UTC, exclusive. Budget against the normal rate if the feature will remain live afterward.

For a founder building a social-asset generator, the practical comparison is cost per accepted asset. A cheaper request that needs several revisions can lose its advantage. Log billed usage alongside whether the customer kept the result; otherwise your cost dashboard measures generation activity without telling you whether it produced anything useful.

## Fix size errors before changing the prompt

The [generation guide](https://platform.minimax.io/docs/guides/image-generation) offers two mutually exclusive size controls: exact dimensions, or aspect ratio plus target area. Combining them returns HTTP 400. Its “2K” setting means approximately 2048² pixels, not a 2048-pixel longest edge; 16:9 produces 2720 × 1536.

Start with an explicit request shape. This illustrative JSON is for POST https://api.minimax.io/v1/images/generations; it has not been executed here.

```json
{
  "model": "MiniMax-H3-Image",
  "prompt": "A clean editorial illustration of a small robot sorting paper invoices, blue and cream palette, no text",
  "size": "2720x1536",
  "n": 1,
  "response_format": "url"
}
```

Keep the sizing decision in one place in your application. If a customer changes the export preset, replace the previous size configuration rather than adding more fields. This avoids a common integration mistake: a valid square default survives underneath a new widescreen selection, leaving the server with contradictory instructions.

Disabling prompt enhancement requires explicit dimensions or a fixed ratio. Edits always use enhancement. Neither masks nor transparent output are supported. A PNG export therefore should not become a “transparent logo” promise in your interface.

## HTTP 200 does not mean every image succeeded

A batch returns HTTP 200 when at least one image succeeds. Inspect each entry in `data` for `error`, and reconcile with `usage.generated_images`. A green request-level status alone cannot tell your application how many usable assets it received.

Suppose a user requests four variations and only three succeed. Preserve those three, show the remaining slot as failed and let the user decide whether to generate another. Repeating the entire batch discards useful work and makes the bill harder to understand. Your database should distinguish the customer’s job from each generation attempt, so one failed slot does not reset the whole job.

## Turn off blind automatic retries

MiniMax's SDK example sets `max_retries=0` because generation is not idempotent: repeating a request can create another image and another charge. A timeout is an uncertain result, not proof that generation never started.

That uncertainty needs a visible product state. Mark the attempt as unresolved, retain its timing and request details, and avoid automatically launching the same job again. A user-initiated retry should explain that the earlier attempt may still complete. This is less convenient than hiding the failure, but much easier to defend than unexplained duplicate charges.

## Hosted API settings are not local inference settings

The [open-weight model card](https://huggingface.co/MiniMaxAI/MiniMax-H3-Image) documents a separate inference stack with six sampling steps and guidance scale 1. It lists 68.65 GB of model files plus an external text encoder. Those download sizes are not a VRAM requirement, and they do not establish that a particular workstation can serve it reliably.

Start with the hosted path if your immediate question is whether customers want the workflow. Consider self-hosting when you can evaluate hardware, licensing and operating cost separately. Mixing local parameters into hosted requests, or treating downloadable weights as free production infrastructure, creates work before it answers the product question.

The integration is ready when an interrupted or partly failed request leaves the customer with an understandable result and an explainable bill. That is a better launch threshold than producing one impressive image.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders explain product decisions and engineering work in content developers actually want to read.

[Book a 30-minute call](https://cal.com/paras-madan/30min).