GPT Image 2 through this gateway: calling it and pricing it

The call: one endpoint, bearer auth

gpt-image-2 answers on POST /v1/images/generations with Authorization: Bearer $TOKEN_SHARE_KEY — the standard OpenAI-compatible image shape, so an existing client usually needs only a base URL and a key.

The catalog describes it as an image generation and editing model with flexible sizes and high-fidelity image inputs. Its capability list is image and nothing else: no text, no tools, no thinking. It generates and edits pictures, and it is not a model you hold a conversation with.

Because it has no token context in the catalog sense, there is no context window or max-output figure to plan against. What you plan against instead is the usage the gateway reports back, which is also what you are billed on.

export TOKEN_SHARE_KEY="<your-pool-api-key>"

curl -sS https://token-share.app/v1/images/generations \
  -H "Authorization: Bearer $TOKEN_SHARE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2",
    "prompt": "A cute baby sea otter",
    "size": "1024x1024",
    "quality": "high",
    "response_format": "b64_json"
  }' > out.json

# Save the picture.
jq -r '.data[0].b64_json' out.json | base64 --decode > otter.png

# Price it: consumer rates are 0.1x of $5/M input and $30/M output.
jq -r '.usage | "in=\(.input_tokens) out=\(.output_tokens)"' out.json
jq '.usage | (.input_tokens / 1000000 * 0.50) + (.output_tokens / 1000000 * 3.00)' out.json

What it costs, and why nobody can quote you a per-image price

The multiplier is 0.1×, applied to official rates of $5 per million input tokens and $30 per million output. You are charged $0.50/M and $3.00/M. Cached input, where it applies, is priced separately from fresh input.

What that turns into per picture depends on the request. The catalog is explicit that billing runs on the tokens the gateway reports, so cost scales with resolution and quality — a 1024×1024 at standard quality and a large image at high quality are not the same bill, and the difference is not a fixed ratio you can carry between settings.

The consequence for planning is simple: measure, do not assume. Generate one image at the exact size and quality your product uses, read the usage object, and multiply. That measured figure is valid for that setting and no other.

Against the per-image alternatives

The other two image ids here are billed by the picture, both at 0.2×: grok-imagine-image is $0.002 per image (0.2× of $0.01), grok-imagine-image-quality is $0.008 (0.2× of $0.04). gpt-image-2 is the only one of the three at 0.1×, and the only one whose cost you cannot state before the call.

That is a genuine trade between two kinds of certainty. A per-image price lets you budget by multiplication and never be surprised by a parameter change. A token-billed price can land lower or higher depending on what you ask for, and it moves when your product's image settings move.

Which is better is a question about your workload, not about the models. A fixed daily count at a fixed size favours arithmetic you can do in advance; a mix of sizes, edits and quality levels is where measuring a representative sample is the only honest way to forecast. Run both on the same twenty prompts and compare the invoice line, not the marketing.

Operating it in production

Log the usage object on every generation. It is the only record of what a request actually cost, and once your image settings are a product decision rather than a constant, a stored per-request token count is what lets you attribute a monthly bill to a feature.

Set your image parameters explicitly rather than relying on defaults. A default that changes upstream is a silent price change on a token-billed model, and the first place it shows up is the invoice.

If you also generate video, note that it is a different id with a different route and a different unit: grok-imagine-video-1.5 is 0.2× charged per video second on /openai/v1/videos. Nothing about the image endpoint carries over.

Common questions