LOTGEN renders on your provider accounts, not on ours. You are billed by Google, by Runway, by ElevenLabs, at whatever rate you have with them, and this software sits between you and them adding no margin to the render.
That is the reason prices in this product are in dollars and seconds rather than credits: there is no internal currency to convert, because there is no internal account. It also means the first thing a new workspace needs is a key.
A key belongs to a platform, not to a model
This is worth getting straight early, because it makes “we have no key for that” wrong more often than people expect. One credential usually pays for several of the things you see listed separately.
| One key | Pays for |
|---|---|
| Three providers in this product, not one | |
| BytePlus ARK | A video shelf and a stills shelf |
| Runway | Its video models, its stills, and its seven recipes |
Settings · Keys is organised the same way, by platform, and each provider row says which credential it is borrowing rather than leaving it a surprise.
Many keys per platform, each named and owned
A platform holds more than one key. Each has a name and an owner, one is the default, and a lot can be bound to a specific key. That is the mechanism behind client work: a lot built for a client renders on the client’s credential and lands on the client’s bill, and Usage reports it separately rather than mixing it into yours.
Create a dedicated key per platform for LOTGEN, spend-capped at the provider where the provider offers that. Do not paste a root or organisation-wide credential, not because this software would misuse it, but because a key you can revoke without consequence is worth more than one you cannot.
Where it goes
The secret is sealed under a data key of its own before it is written down, and that data key lives outside the database that holds the ciphertext. Neither half is useful on its own.
| Question | Answer |
|---|---|
| Can I read my key back? | No. No list, no detail view and no API response returns the secret, only a hint, enough to tell two keys apart |
| Where is it decrypted? | Server-side, to submit a job, and nowhere else. It is never sent to a browser |
| Does anything fall back to a LOTGEN key? | No. A render with no working key for the provider fails; it does not quietly run on somebody else’s credential |
| What if I replace it? | A replacement is sealed under a new data key and the old one is destroyed, so a backup taken before the change cannot open the credential you rotated away from |
Taking it back
Deleting a key destroys the material rather than hiding the row. There is nothing left to re-enable and nothing to un-delete; if you want that provider again you paste a key again.
Two things survive deletion, and both should: the takes already rendered on that key, and the record of what they cost. Removing a credential is not a way to remove the history of what it paid for.
Deleting the whole workspace destroys keys, purges the objects and refuses rather than half-finishing. That is a separate, larger door.
A stored key is not the same as a working one
The most common wasted render in this product.
A provider row carries two separate facts: whether a key is stored, and whether that key last failed to render, an empty prepaid balance, a rejected credential, a permission the account does not have. A key with an empty balance is stored, looks configured, and cannot render.
The failure is reported in the provider’s own words rather than translated, because the fix is almost always at the provider rather than here. Settings · Keys can ping a platform to ask it directly, which costs nothing and answers the question before a job is queued rather than after it has been.
When a key is failing, pick a different provider rather than retrying, most shots have several, and a submit against a dead credential still costs you the wait.