> For the complete documentation index, see [llms.txt](https://help.auray.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.auray.ai/when-a-render-fails.md). # When a render fails Every generator here takes the credits before it starts, and gives them back when it produces nothing. The first half is what you notice. The second half is the one worth reading, because a failed render that quietly kept your credits is the kind of failure nobody ever spots. ## What happens when you press Generate The price is printed on the button that spends it — **Generate · 12 credits** — and the credits are gone the moment you press it. Five things happen, in this order. {% stepper %} {% step %} ### Your plan is read from your account Not from the window in front of you. A desktop that is confused about your plan cannot buy something your account does not allow. {% endstep %} {% step %} ### This month's credits are granted, if they have not been already Before your balance is checked, never after. The other way round tells someone they are broke on the first day of the month while the credits sit waiting to be handed over. They arrive the first time you open one of these apps in a given month, rather than at a set moment. {% endstep %} {% step %} ### You are charged {% endstep %} {% step %} ### The job is written down The record is the charge's durable home. If everything after this point goes wrong, this row is what a late answer from the GPU can still attach itself to, and what a refund can be reversed against. {% endstep %} {% step %} ### The GPU is asked to start {% endstep %} {% endstepper %} Charging before the dispatch rather than after is the whole point of the order. Reversed, anyone willing to close their laptop at the right moment renders for free. {% hint style="info" %} The balance in the menu bar comes back from the same request that spent it, so it drops the instant you press the button. Left alone it re-reads itself once a minute — which is how long a refund can take to show up in the corner after it has already been made. {% endhint %} ## A failed render is refunded | What happened | What comes back | | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | A clip, a song or an image failed | All of it. | | A storyboard failed at scene eleven | All of it. | | A 3D model failed part way through | Everything except the stages that finished. Those files stay in your library — they are what you kept. | | Some images were withheld by the content filter | The credits for the images you did not receive. | | You stopped an image render | All of it. | | You stopped a song or a video | The part that had not been rendered yet. | | You stopped a 3D model | Everything after the stage that finished, less the cost of starting the machine if it had started. | A failure is ours. Nobody can make a GPU die on demand, so a render that produced nothing is reversed in full and there is no judgement in it. Stopping something yourself is different, and the difference is not meanness. A full refund for a cancellation means consuming ninety per cent of the render and paying nothing, over and over. Images are the exception — they render in seconds, so there is no meaningful progress to bill for, and every stopped image job is returned whole. Several things are watching each job: the service's own callback, this app's polling while you have it open, and a sweep that runs every five minutes. Whichever notices first settles the money, and the ledger ignores the rest. Nothing is refunded twice, and nothing is missed. {% hint style="info" %} You can close the window, or the whole browser. The job carries on without you and settles on the server. Open the app again and the result — or the refund — is already there. {% endhint %} ## The one case where your credits stay taken If the service never answers — a timeout rather than a refusal — the charge is deliberately left standing for a while. "We do not know what happened" is not the same as "nothing happened", and the render may well be underway. Refunding there would pay for work that is about to arrive. Music says both halves of that out loud: *"The service did not answer. If the song appears, you were charged for it; if not, the credits come back."* If nothing ever appears, a background sweep reverses it. A charge that never reached a GPU at all is returned after fifteen minutes. Past that, an image job is given thirty minutes and a clip or a model two hours — nothing legitimate is still alive at those ages — and then the row is closed out with a line saying where the money went: *"That request never reached the service. The credits were returned."* ## What "queued" means Queued means it worked. You have been charged, the job exists, and it is waiting for a GPU. Photos words it exactly: **Waiting for a free GPU…** The progress bar under a queued job sits just above zero rather than at it. That is on purpose. A bar at nothing reads as nothing happening, when the queue is precisely where the time is going. For the same reason it stops just short of the end rather than filling and then waiting. There is a queue because everyone shares one set of machines. Across the whole platform, the desktop can hold five image jobs, nine songs, three 3D models and seven video renders at once. Video's eight containers are four for **Fast** and four for **Pro**, and they are not interchangeable — different cards, different weights loaded at start — so an idle Fast container cannot take a Pro job. Your plan limits how many you can have going at the same time as well, and when you reach it the app says so instead of quietly queueing another: *"You already have a song generating."* ## The first render after a quiet spell Seven minutes with nothing on screen, and it is not a hang. The GPUs shut down completely when nobody is using them. Starting one again means loading the model's weights before a single frame exists — 134 GB of them for video, which takes four to five minutes on its own. The render that follows it then runs at four to five times its warm speed, because the compiler and the warm-up canvases run inside it. Measured end to end, the first clip lands about seven minutes after you ask for it. Both Video and Music say so under the progress bar while you wait. The other three are shorter versions of the same thing. The one cold song anybody has measured took 48 seconds to get going, and that figure includes its time in the queue. A fully cold 3D model with textures is about six minutes end to end. A cold image took 44.5 seconds, of which only 8 was the actual render — the rest was weights loading. Once a machine is warm the numbers change completely: a five-second clip is about 25 seconds at Pro quality and 17 at Fast. Length costs more than proportionally — about the 1.63 power of it — so a fifteen-second clip is nearer six times a five-second one rather than three. {% hint style="info" %} Photos, Music and 3D quote an estimate that already includes a cold start, so their bars are scaled for the slow case and a warm render finishes early. Video's estimate is not: it comes from the render service and is a warm figure, so a cold clip runs well past it and the bar sits near the end waiting. Neither means anything is wrong, and neither changes what you pay. The cold start costs you nothing extra. The price on the button is the whole price, and it is decided by your settings rather than by how long the render took. {% endhint %} ## When a render is refused for safety Two of the models screen what you ask for before any GPU is allocated, and one screens what came out afterwards. That is a condition of their licences rather than a house rule — the image model's licence requires filtering on input **and** output, in those words — so it applies on every plan, Ultimate included. A refusal is a decision about the words you sent. What you will see: * **That request cannot be processed.** * **Intimate imagery of a named real person cannot be generated. Describe the subject instead.** * **Prompts that imitate a real artist's voice are not allowed. Your credits were returned.** * **That prompt was rejected. Your credits were returned.** * **One image was withheld by the content filter. That credit came back.** The last of those is the after-the-fact case: the render ran, some images came back, and the ones the filter held are the ones you were refunded for. The rest of the job is charged, because the container really did run. {% hint style="warning" %} Photos does not mention the money when it refuses a prompt, and it should. **Your credits are returned** — the refusal lands before a GPU is allocated and the charge is reversed in the same breath. Music's two lines say so; the Photos lines do not, and that is a gap in the wording rather than in the refund. {% endhint %} **What to do is rewrite the description.** Sending the identical words again is the one move that cannot help. Most refusals are a pattern catching something it was not aimed at, and naming a real person is the commonest trigger — describing the subject instead of naming them usually goes through. There is no appeal button, and this page is not going to invent one. The **Report** button in each app points the other way: it is for telling us that something which *was* generated is wrong. ## Refunds are credits, not money Everything on this page returns credits to your balance. Nothing touches a card in either direction. On this deployment nothing could. Checkout and cancellation are real, but Stripe is running in test mode — only test cards are accepted and no money is charged at all. The subscription pane says the same thing rather than leaving it to be discovered after paying. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.auray.ai/when-a-render-fails.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.