Verify credits after a failed OfflineCreator generation

Confirm a terminal failure before replacing the generation

Keep the original generation ID and read its current status. A provider job that reaches `failed` is the refund case described by OfflineCreator Studio: the product page says Studio reserves the displayed model cost when a job starts and automatically returns those credits when the provider job fails. A client timeout, closed connection, or interrupted wait is not by itself proof that the provider job failed. Reconnect and query the same ID instead of immediately creating a second paid job.

When the status response is terminal `failed`, read the current balance with MCP `get_credits` or the equivalent authenticated API or CLI balance command. Do not cancel the failed record, submit it again, or assume that the balance changed merely because the local client printed an error. The verification boundary is two account reads around one known generation: the balance after reservation, then the balance after the backend has recorded the terminal failure.

Use the generation record and balance as a paired check

First call `get_generation` with the original UUID, or let `wait_generation` return that same record. Continue only when the returned state is `failed`; `queued`, `processing`, and a timed-out wait still describe a nonterminal or inconclusive observation. Next call `get_credits`. Record the failed generation's displayed credit cost and compare the new balance with the balance captured after the job was accepted. The expected reversal is the reserved cost once, not an extra credit award.

If you did not capture a pre-failure balance, avoid claiming an exact refund from one balance snapshot. Preserve the failed ID, its model and credit cost, and the current balance, then escalate with a sanitized trace when the observations do not reconcile. The published `get_credits` response reports the current balance rather than a transaction history, so that single value cannot identify which event produced it.

Terminal evidence

The original generation reports `failed`A timeout or transport error does not establish the provider outcome.

Balance evidence

A fresh `get_credits` resultCompare it with a captured post-reservation balance when one is available.

Safe next action

Retry once only after the reversal is verifiedKeep the replacement separate from the failed generation ID.

Use the reader-verifiable failure and credit path

The public, reader-verifiable path has three observations. The Studio product page says the displayed model cost is reserved when a job starts and automatically returned when the provider job fails. The published MCP package exposes `get_generation` and `wait_generation` for the job outcome. It separately exposes `get_credits` for the current balance. Together, those sources support checking the same generation's terminal state and then checking account credit state.

They do not expose the underlying credit-ledger transaction, a refund-entry identifier, or an MCP ledger-history tool. Earlier research found proprietary source URLs for an exact transaction path, but those URLs return 404 to public readers and are rejected as support for rendered claims. This draft therefore does not assert row locking, uniqueness constraints, transaction ordering, or a guaranteed one-row implementation. If paired status and balance observations do not reconcile, preserve the gap for support rather than presenting private implementation detail as verified evidence.

Generation observation

The original ID reaches `failed`Use the published status tools; do not infer terminal failure from a local timeout.

Credit observation

A fresh current-balance readCompare it with a captured post-reservation balance and displayed model cost.

Evidence limit

No public ledger-history toolEscalate unresolved attribution instead of inventing an internal transaction record.

Separate provider failure from an inconclusive client error

The public MCP client polls the generation endpoint until it sees `completed` or `failed`. If its wait limit expires, it performs one latest status read and returns `timedOut: true`; that response is not converted into a failed provider job. Likewise, a network interruption can stop the local wait without changing the server-side generation. In both cases, retain the UUID and resume with `get_generation` rather than starting over.

A failed generation response is different: it is a terminal server record and can be paired with a fresh credit read. Preserve the structured response instead of reducing every client error to “generation failed.” The distinction prevents a replacement job from starting while the original may still be processing, and it keeps an inconclusive client interruption separate from the provider-failure case documented by the product page.

Work through a refund check without double spending

Suppose the account shows 100 credits, an 8-credit model is accepted, and the immediate post-reservation balance is 92. If the same generation later reports `failed`, a fresh balance of 100 is consistent with one 8-credit reversal. This is an arithmetic example using a cost currently displayed on the Studio product page, not a promise that every account starts at 100 or that model costs remain fixed.

Now consider a less complete trace: the client loses its connection after submission and the only balance you can see is 92. Do not label that a missing refund yet. Query the original generation. If it has not reached `failed`, continue a bounded status workflow. If it says `failed` and a fresh balance still does not equal the captured post-reservation balance plus the displayed cost, stop before a replacement. Capture the two timestamps, failed ID, model, cost, and redacted balance responses for support.

Choose the next guide from the observed state

Stay on this page when the original generation has reached terminal `failed` and the question is whether its reserved credits returned. Use the stuck-processing guide when the record remains queued or processing after a bounded wait. Use the cancellation guide when the record is still reserved and has not been submitted to the provider; the published package documents `cancel_generation` for that state. Return to the troubleshooting directory when the client cannot retrieve either status or balance.

Keep this page limited to failed-job credit reversal

This page owns one question: after OfflineCreator reserved credits for a generation and that same generation reached terminal provider failure, did the reserved amount return to the account balance? It does not cover cash refunds, subscription cancellation, top-up disputes, rate limits, insufficient credits before submission, or cancellation of a reserved image-input job. It also does not treat a local timeout as a provider failure.

Verified behavior is limited to the current first-party product page and published MCP package surfaces. Those public materials establish automatic failed-job returns, status reads, waits, and current-balance reads. Their documented tool list has no ledger-history tool, and neither reviewed public source publishes a universal refund-completion deadline. Revalidate the product sources monthly, and preserve an unresolved timing or attribution question as a support gap rather than inventing a transaction detail or service-level promise.