Budget 250 product shots: read each Sume model's price in code
A short Python script reads the pricing line from Sume's per-model endpoints route and prints the cost of 250 product shots. Reference rules and a worked table.

To price 250 product shots on Sume, read pricing from GET /v1/images/models/{model_id}/endpoints for each candidate and multiply by 250. The script below does that for three rows. It prints the default tier, so tiered rows such as Nano Banana 2.1 need the resolution multiplier added by hand.
The script
The endpoints record holds a pricing array with cost_usd per billable line, as the Image API docs show. The model id contains a slash, which is part of the path.
import os, requests
H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
IDS = ["google/nano-banana-2.1", "google/imagen-4-fast", "openai/gpt-image-2.5"]
SHOTS = 250
for mid in IDS:
url = f"https://api.sume.com/v1/images/models/{mid}/endpoints"
j = requests.get(url, headers=H, timeout=30).json()
for ep in j["endpoints"]:
for line in ep["pricing"]:
if line["billable"] == "output_image":
print(mid, line["cost_usd"], "->", round(line["cost_usd"] * SHOTS, 2))What to expect
The numbers below come from the Sume pricing tables, not from running the script, and the live route is the source of truth. A row priced by tokens, like GPT Image 2.5, may not return a flat per-image line, so read its docs before you budget.
| Model id | Per image | Arithmetic | 250 shots | Edits a photo |
|---|---|---|---|---|
| google/imagen-4-fast | $0.025 | 250 x 0.025 | $6.25 | No |
| google/nano-banana-2.1 (1K) | $0.10 | 250 x 0.10 | $25.00 | Yes, up to 10 |
| google/nano-banana-2.1 (0.5K) | $0.075 | 250 x 0.075 | $18.75 | Yes, up to 10 |
Add what the price line omits
A product shot usually needs a reference photo, so Imagen's low price is not comparable. Filter on input_references.max first, then compare cost. The earlier post on cheapest models that take a reference lists the rows.
Filtering the catalog first
Do the filters before the prices. First drop rows without the references you need, then rows without the ratio, then rows without the resolution. Only then sort by price. A cheap row that cannot do the job is not a choice.
For Nano Banana 2.1 the default price line is the 1K tier. At 0.5K the 250 shots cost 250 x $0.075 = $18.75, and at 4K they cost 250 x $0.20 = $50.00. Add those multipliers in your script from the resolution you request.
Print the date with the totals and keep the output. The catalog can change, and a saved quote shows what you expected to pay on the day you planned the run.
Limits of the script
It prints the first output_image line it finds per endpoint, and it assumes the response shape in the Image API docs. If a row returns a different shape, for example a token-priced row without a flat line, the script prints nothing for that row, which is the signal to read that row's docs. It does not add input-token charges for reference images, and it does not apply tier multipliers.
Treat it as a first pass. For a real budget, run one real request per candidate and read usage.cost from the response.
If you want a stricter budget, add a ceiling. Compute the worst case before you start, stop when the running total passes it, and print the count of items left. For 250 shots on Nano Banana 2.1 at 1K the ceiling is $25.00. A script that reads usage.cost from each response and sums it can enforce that without guessing, because cost is the amount Sume bills to your wallet for that call.
Sources
Related posts
More in Developers
- Build IMAGE_REF tags in Python for up to 10 Omni references
A Python helper turns a list of up to 10 image URLs into an Omni Flash prompt with matching IMAGE_REF tags, 0-based, in list order. Runs as written.
- Bulk run item completed is not success: check before you publish
A Sume Format bulk child can be completed without being a success. Read each result and use per-child webhooks; no queue webhook exists.
- Bun 1.4.2 fixes an AsyncLocalStorage leak: per-request Sume keys
Bun 1.4.2 fixes an AsyncLocalStorage leak from 1.4.1. Carry a per-request Sume Idempotency-Key in the store, and check your Bun version first.
- bun test for a Sume webhook verifier: five cases to run on Bun 1.4.2
Five bun:test cases for a Sume webhook verifier: fresh, tampered, stale, rotation and an empty secret, plus a pin to Bun 1.4.2 or later. Run on Bun 1.4.0.
Written by Sume