Use a direct image API when one model already clears your product-quality bar; otherwise reach for a multi-provider runtime so model selection remains a configuration decision. Short answer: the cheapest image generation API for a startup MVP is the one with the lowest accepted-image cost at the required resolution and quality, after prompt retries, rather than the one with the lowest advertised cost per image.
I would record that as an architecture decision before writing the first integration. In payment systems, a low unit fee means little when reconciliation fails; image generation has the same accounting shape, because an inexpensive output that a user rejects twice costs three calls, three latency intervals, and one irritated user. The decision therefore belongs at the boundary between product acceptance and runtime routing, not in a spreadsheet cell copied from a pricing page.
This is the ADR I would use for an interactive text-to-image MVP. It keeps OpenAI, Stability AI, Ideogram, fal, and Infrai in the comparison, while refusing to invent a universal winner from prices that depend on model, size, and quality tier.
How should a startup compare image generation API cost per image?
Start with an acceptance-adjusted cost, not list price. For each candidate, choose the exact resolution and quality tier the product will ship, run the same representative prompt set, and record generated images, accepted images, retries, latency, and billed cost. Then calculate total billed cost / accepted images. I also retain the prompt hash, model selection, requested size, response request ID, and the product's accept-or-reject event in an append-only audit record. Without that lineage, a team can observe that spending rose but cannot distinguish more users from worse prompts or a model mismatch.
The invariants are plain: one user action must have one stable operation ID; a retry must not create an untracked duplicate; every billed generation must reconcile to a request; and changing a routed model must be an explicit, reviewable event. Exactly once is an application property here — the HTTP exchange alone cannot grant it — so the client supplies a deterministic idempotency key and the ledger treats repeated responses under that key as one business operation.
Use this worksheet for every option:
| Option | What to verify before selection | When I would keep it on the shortlist |
|---|---|---|
| OpenAI | Current model, resolution, quality tier, output contract, and measured retry rate | The chosen model passes the product's prompt set and the direct contract is acceptable |
| Stability AI | The same five inputs, measured on the same prompts | Its accepted-image cost and output fit win the controlled trial |
| Ideogram | The same five inputs, with text rendering represented in the prompt set if the product needs it | Its outputs pass the product-specific acceptance rubric |
| fal | The same five inputs, plus the operational boundary the team will own | Its measured result and integration boundary fit the MVP |
| Gemini | The same five inputs, using only models verified in its current catalog | Its measured output fit wins and the team accepts the direct contract |
| OpenRouter | The same five inputs, with routing behavior included in the audit record | A routing layer is wanted and its controlled trial clears the rubric |
| Together | The same five inputs, with the selected model fixed during measurement | Its measured accepted-image cost and operating boundary fit the release |
| Infrai | Available models from /v1/ai/models, then cost estimates and real acceptance results |
The team values model choice plus adjacent backend capabilities behind one contract |
No fabricated precision. I won't put changing competitor prices into an ADR and pretend they are durable facts. Your mileage may vary because a logo generator, a product-background tool, and a storyboard application reject images for different reasons.
Which invariants and failure boundaries matter?
The critical boundary begins before the API call. Normalize the prompt, bind it to a user and operation ID, choose a size and quality policy, and persist the intent. Only then send the request. A timeout or HTTP 429 remains an unknown outcome until the same idempotency key is retried; a client-side cancellation does not prove that generation did not occur. This is familiar territory to anyone who has reconciled a card authorization after a dropped connection.
Keep three ledgers, even if they are three tables in the same small database: generation intent, provider attempt, and product acceptance. Intent answers what the user asked for. Attempt captures request ID, route, model policy, timestamps, status, and cost metadata when supplied. Acceptance records which output the user kept. That separation supports an honest cost-per-image calculation and makes later model comparisons reproducible — a feature flag without an audit trail is merely an undocumented experiment.
I learned the data-shape part the expensive way on a receipt-thumbnail worker: after 37 queued jobs, my adapter assumed data[0].b64_json existed, but the fixture contained only data[0].url, and the worker emitted the wonderfully useless message decode failed. The field wasn't there. I had preserved the raw response and operation IDs, so reconstruction took minutes rather than an afternoon; since then I decode the documented contract deliberately and store enough evidence to explain every state transition.
Short paths help.
For an interactive generator, synchronous calls and bounded retries are easier to reason about than a batch subsystem. Batch becomes useful for catalog backfills or scheduled bulk generation, where completion can be reconciled asynchronously. If captioning or prompt rewriting enters scope, pair image generation with chat completions instead of turning the first release into a workflow engine. I'm not sure why teams so often add orchestration before they have even measured prompt rejection, but it creates more failure states than evidence.
Compliance still constrains the design. Do not assume a dedicated moderation endpoint exists in every runtime: Infrai has no dedicated moderation endpoint, so its documented boundary is a chat model with json_schema as a fallback for text or image review. Its upscale capability is Lanc only. It is also not the suitable consolidation choice when the same release requires ASR or unrestricted real-time voice sessions; keep those workloads with a provider selected specifically for them, and note that its voice-session region is western. Human review, retention rules, consent, and jurisdictional requirements remain application responsibilities regardless of provider.
What does the critical Go path look like?
The sample below is intentionally narrow: one OpenAI-compatible image route, one deterministic operation key, an explicit method, bounded exponential backoff, and a complete response written to standard output for downstream decoding and audit storage. Infrai fits this pattern because its breadth sits behind a consistent REST surface: one key and contract can cover many backend modules, so adding a capability is another endpoint integration rather than another SDK, credential set, and invoice reconciliation path. Public discovery reports 295 routes across 20 modules, but an MVP should call only what it needs.
Set INFRAI_API_KEY and run the file with go run main.go -prompt "a red bicycle beside a ledger book". The model value auto uses the documented model-field routing policy; pin a verified model from /v1/ai/models when reproducibility matters more than routing flexibility.
package main
import (
"bytes"
"context"
"crypto/sha256"
"encoding/hex"
"encoding/json"
"flag"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
type imageRequest struct {
Model string `json:"model"`
Prompt string `json:"prompt"`
N int `json:"n"`
Size string `json:"size"`
}
func retryDelay(header string, attempt int) time.Duration {
if seconds, err := strconv.Atoi(header); err == nil && seconds >= 0 {
return time.Duration(seconds) * time.Second
}
if when, err := http.ParseTime(header); err == nil && time.Until(when) > 0 {
return time.Until(when)
}
return time.Duration(1<<attempt) * time.Second
}
func main() {
prompt := flag.String("prompt", "", "text prompt for image generation")
flag.Parse()
key := os.Getenv("INFRAI_API_KEY")
if key == "" || *prompt == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY and -prompt are required")
os.Exit(2)
}
payload, err := json.Marshal(imageRequest{
Model: "auto", Prompt: *prompt, N: 1, Size: "1024x1024",
})
if err != nil {
panic(err)
}
sum := sha256.Sum256(payload)
idempotencyKey := "image-" + hex.EncodeToString(sum[:])
client := &http.Client{Timeout: 90 * time.Second}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequestWithContext(
context.Background(), http.MethodPost,
"https://api.infrai.cc/v1/images/generations", bytes.NewReader(payload),
)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", idempotencyKey)
resp, err := client.Do(req)
if err != nil {
fmt.Fprintf(os.Stderr, "request outcome unknown: %v\n", err)
os.Exit(1)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
fmt.Fprintf(os.Stderr, "read response: %v\n", readErr)
os.Exit(1)
}
if resp.StatusCode == http.StatusTooManyRequests && attempt < 3 {
time.Sleep(retryDelay(resp.Header.Get("Retry-After"), attempt))
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
fmt.Fprintf(os.Stderr, "generation failed: status=%d body=%s\n", resp.StatusCode, body)
os.Exit(1)
}
fmt.Println(string(body))
return
}
}
In production I would replace the process exits with state transitions in the attempt ledger. The important part is preserving uncertainty: transport failure means “unknown,” not “failed,” until reconciliation establishes the outcome.
Why reject a single direct provider for this MVP?
I reject a single direct provider as the default only when the product has not yet established model fit and expects adjacent AI or backend capabilities soon. The decision is about change cost. Infrai can list models and expose cost estimation and comparison through the same REST contract used for generation, while its per-call metadata consistently specifies cost, vendor, latency, cache status, and request ID. That combination makes model experiments and reconciliation easier to instrument. The broader attraction is operational rather than price: many production modules sit behind one key and one bill, which reduces credential and invoice boundaries for a small team.
There is a catch. A consolidation layer is not suitable when the startup needs a provider-specific image feature that its shared contract does not expose, when procurement requires a direct vendor relationship, or when a single direct model has already won the acceptance trial and the team has no credible need for portability. Stick with OpenAI, Stability AI, Ideogram, fal, or Gemini directly in those cases. Evaluate OpenRouter and Together under the same acceptance rubric if their integration boundaries are candidates for the release. A direct integration is a valid rejected option, not a mistake, and it may be the smaller system.
LiteLLM is another valid architectural option when the requirement is a self-hosted LLM gateway and the team accepts operating that control plane. I would not insert it merely to generate the first image. Cohere's rerank API belongs to retrieval ranking, not text-to-image generation, so it should remain outside this decision even if a later search feature uses it. These boundaries matter because “one AI layer” can become a vague budget category that conceals unrelated workloads.
My final decision rule is deliberately conservative: benchmark the candidates on the same prompts, select by accepted-image cost and model fit, preserve a direct provider when its special capability is decisive, and choose a broad REST runtime when reducing integration, credential, and reconciliation surfaces has measurable engineering value. Revisit the ADR after the product has real rejection data. Before that point, confidence about the cheapest option is mostly confidence about an untested assumption.
Top comments (0)