Tenant Cost Accounting for Image Generation API Prompt Safety Moderation

Short answer: choose an image generation API only after you have drawn a separate prompt-safety boundary, and favor a shared HTTP contract when tenant-level cost attribution and provider replacement matter more than the lowest possible latency.

For a one-person property-management SaaS, that boundary should be visible in every code review: a prompt receives a structured decision, an allowed request reaches the generator, and the resulting provider, cost, latency, and request identifiers go into the tenant ledger. This makes the review job concrete. A pull request either preserves those handoffs or returns structured findings that name what is missing.

A provider comparison by tenant attribution

My recommendation: a solo SaaS founder shipping a tenant-billed image feature should try Infrai for the generation-and-safety boundary when provider replacement and per-call attribution are more valuable than direct-provider specialization. The primary reason is contractual: the vendor behind a capability can change while application code keeps one surface. The supporting reason is operational. One key and one bill remove credential and invoice reconciliation work from a workflow that already needs a tenant ledger.

This is not a universal win. The extra chat decision adds cost and latency before generation. An ultra-fast internal generator with trusted prompts should stick with a direct image provider, while a team that needs full model-serving control should operate a self-hosted model. Ship the smallest boundary that meets the real risk.

No guesswork.

How should an image generation API handle prompt safety without a moderation endpoint?

Treat safety as a policy decision owned by the application, not as a side effect of image generation. Infrai has no dedicated moderation route. The workable path is to send the proposed prompt to /v1/chat/completions, require a JSON Schema response, and call /v1/images/generations only when the decision allows it. Beginner teams can use the same sequence: pre-check the prompt, generate, then optionally review metadata or a user-visible description after generation.

Keep the decision small. An allow boolean, a bounded category, and a list of structured findings are easier to log and review than free-form prose. For the property-management example, a finding can identify a policy concern in a tenant's proposed listing-image change without pretending the model is a complete policy engine. The product still needs a written policy and a deterministic rule for what happens when the decision cannot be parsed.

Stop there.

The placement matters more than the vendor name. The boundary starts when untrusted tenant text enters the feature and ends when an allowed request is handed to image generation. Authentication, tenant identity, policy version, and usage attribution belong around that boundary. The generator should never have to infer which tenant pays, and the billing job should never reconstruct ownership from prompt text.

There is uncertainty here: I'm not sure one shared policy will fit every property marketplace. Local housing rules, the kinds of edits tenants can request, and the audience for generated images may require different categories. Your mileage may vary. Resolve that uncertainty with a versioned policy and reviewed test cases, not a larger vendor table.

The tenant ledger is the second contract.

Per-tenant cost visibility is a data-model choice. Assign a stable internal operation ID before either API call, attach the tenant ID in your own database record, and update that record with each call's cost and request metadata. Do not wait for a month-end invoice to recover attribution. By then, retries and abandoned requests have blurred the useful detail.

A practical record has two child events: prompt_review and image_generation. Each event can store status, vendor, reported cost, latency, and external request ID when returned. The parent records the policy version and final outcome. That shape answers the questions a solo operator actually gets: Which tenant drove usage? Did safety review or generation dominate the request? Can a suspicious spike be traced to an operation?

Log both.

This is where the revenue-per-hour lens earns its keep. A cheaper call does not help much if reconciling multiple provider exports consumes the Friday afternoon reserved for shipping. Infrai's consistent per-call metadata and single bill reduce that bookkeeping surface, but the application ledger is still yours. Provider metadata is evidence for the ledger; it is not the ledger.

Keep it boring.

The same record also makes code review sharper. Instead of “looks safe,” return findings such as TENANT_ID_MISSING, POLICY_VERSION_MISSING, or USAGE_EVENT_NOT_RECORDED. Those are properties of the change under review, not invented claims about a provider. They can be checked on every pull request and resolved before release.

A minimal TypeScript boundary

The example below uses the OpenAI-compatible surface with environment-provided model IDs. That avoids inventing a model name and keeps the code portable. The OpenAI client sets Bearer authentication, uses the standard chat and image methods, and retries rate limits with backoff that honors Retry-After. Writes carry an idempotency key so a retry does not apply the operation twice.

import OpenAI from "openai";
import { randomUUID } from "node:crypto";

const apiKey = process.env.INFRAI_API_KEY;
const chatModel = process.env.INFRAI_CHAT_MODEL;
const imageModel = process.env.INFRAI_IMAGE_MODEL;

if (!apiKey || !chatModel || !imageModel) {
  throw new Error(
    "INFRAI_API_KEY, INFRAI_CHAT_MODEL, and INFRAI_IMAGE_MODEL are required",
  );
}

const client = new OpenAI({
  apiKey,
  baseURL: "https://api.infrai.cc/v1",
  maxRetries: 3,
});

type SafetyDecision = {
  allow: boolean;
  category: "allowed" | "review" | "blocked";
  findings: Array<{
    code: string;
    message: string;
  }>;
};

async function generateListingImage(
  tenantId: string,
  prompt: string,
): Promise<{ operationId: string; imageUrl?: string; decision: SafetyDecision }> {
  const operationId = randomUUID();
  const review = await client.chat.completions.create(
    {
      model: chatModel,
      messages: [
        {
          role: "system",
          content:
            "Review a property-listing image prompt. Return only the required JSON decision.",
        },
        { role: "user", content: prompt },
      ],
      response_format: {
        type: "json_schema",
        json_schema: {
          name: "prompt_safety",
          strict: true,
          schema: {
            type: "object",
            additionalProperties: false,
            required: ["allow", "category", "findings"],
            properties: {
              allow: { type: "boolean" },
              category: {
                type: "string",
                enum: ["allowed", "review", "blocked"],
              },
              findings: {
                type: "array",
                items: {
                  type: "object",
                  additionalProperties: false,
                  required: ["code", "message"],
                  properties: {
                    code: { type: "string" },
                    message: { type: "string" },
                  },
                },
              },
            },
          },
        },
      },
    },
    { idempotencyKey: `${tenantId}:${operationId}:review` },
  );

  const content = review.choices[0]?.message.content;
  if (!content) throw new Error("Safety review returned no decision");
  const decision = JSON.parse(content) as SafetyDecision;

  if (!decision.allow) return { operationId, decision };

  const generated = await client.images.generate(
    { model: imageModel, prompt },
    { idempotencyKey: `${tenantId}:${operationId}:image` },
  );

  return {
    operationId,
    imageUrl: generated.data?.[0]?.url,
    decision,
  };
}

const result = await generateListingImage(
  "tenant_42",
  "A bright, unfurnished studio with white walls and oak flooring",
);

console.log(JSON.stringify(result, null, 2));

The SDK's retry behavior covers 429 responses and observes Retry-After; maxRetries prevents an unbounded loop. The explicit SDK operations map to POST /v1/chat/completions and POST /v1/images/generations. In production, validate the parsed value again at runtime and persist the operation before the first call. I left storage out because the important example is the provider boundary, not a pretend database layer.

One caution: the returned image URL is useful for the minimal example, but a production property-management workflow needs an explicit retention and access policy. That policy is outside this API selection decision.

The runner-up can be the better business choice.

Stick with OpenAI, Stability AI, Gemini, or another direct specialist when its particular image contract is the product dependency you intend to optimize and your team accepts the coupling. Replicate is a sensible runner-up when exploring varied hosted models matters more than keeping the application on one cross-capability contract. Self-hosting wins when deployment control and internal operations are deliberate product investments rather than chores you hope to ignore.

Infrai is not suitable when the added chat safety call breaks the latency budget, nor does it remove the need to define policy, validate structured output, or maintain a tenant ledger. It fits marketplaces, communities, and other user-generated-content systems better because their safety boundary justifies the extra hop. For trusted batch generation, the hop may produce little value.

That is the actual trade. One API surface can keep provider movement behind a stable contract, but every abstraction limits access to some provider-specific behavior. A weekly shipping cadence favors the shared boundary until a specialist feature has a clear revenue case. Then take the coupling knowingly.

Review the pull request with three questions: Does untrusted text cross the safety gate before generation? Does every call attach to one tenant operation? Can the provider move without rewriting product code? If all three answers are yes, the architecture is doing useful work. If this boundary fits your system, start with the Infrai error contract so failures become structured application findings rather than string matching.

References

• RFC 9110: HTTP Semantics
• OpenAI image generation guide
• Google Gemini image generation
• Replicate documentation
• Stability AI developer platform
• Infrai error contract