Estimating Credit Cost Before You Dispatch a Batch

Budget anxiety around AI generation rarely shows up as "I decided not to generate anything." It shows up quieter than that: three hook variants instead of the real spread of eight or ten a proper test needs, one aspect-ratio pass instead of the two worth comparing, because guessing at what the ambitious version costs feels riskier than a smaller batch that doesn't actually give you enough to find a winner. The fix isn't willpower. It's pricing the job before you start, against the same number that would actually get charged.

Two different questions, two different tools

Versely's agent has two tools built for this, and they solve two different failure modes rather than the same one twice.

estimate_cost answers "what would this cost." It's a planning tool, used before anything is committed, and asking it costs nothing. It takes a list of planned items — image, video, music, speech, or sound effect — each with optional model, count, and duration fields, and returns credits itemized per item plus a total, alongside the current account balance. Critically, it runs on the same pricing logic as a real charge, not a separate, softer approximation that could drift from what actually gets billed.

check_credits answers a narrower question: "do I have enough, yes or no." It's a pre-flight gate meant specifically for the start of an expensive multi-step workflow — it takes a description of the planned operation and an estimated credit figure, and returns the current balance alongside it. Its entire job is catching an insufficient-balance failure before step one runs, not discovering it at step six of a ten-step job with the first five steps' credits already spent.

Under-generation and partial failure are different problems with different fixes. estimate_cost fixes the first by replacing a guess with a real number before a batch gets sized down out of caution. check_credits fixes the second by gating a big job's start against actual balance instead of finding out mid-run.

Why count and duration matter more than they look

The optional fields on an estimate_cost item — how many, and how many seconds — aren't there for completeness. Credits don't price every content type the same way: an image is generally a flat per-generation charge, while video and speech scale with length, so an estimate that doesn't know how many seconds of video or how many images are actually planned isn't really an estimate — it's a guess wearing a number. Passing the real count and duration is what turns the returned figure into something worth planning a batch size against, rather than a number that quietly undercounts a 20-second video by pricing it like a 5-second one.

The under-generation problem

This is the quieter of the two failure modes, and the more common one. Nobody frames it as skipping a generation — they frame it as being "reasonable" about batch size, which in practice means testing with fewer variants than the format actually needs to find a real winner. Pricing the full, ambitious version first removes the reason for that shrinkage. Either the real number turns out comfortably affordable and the smaller batch was unnecessary caution all along, or the cost is genuinely tight — and now there's an actual figure to make a real tradeoff against, instead of a vague feeling doing the deciding for you.

The partial-failure problem

The other failure mode runs in the opposite direction: an ambitious multi-step job — a hook pack, a multi-scene draft — starts, runs several steps successfully, spending credits at each one, and then fails partway through on an insufficient balance. What's left is a half-finished asset set and already-spent credits, with nothing usable to show for either. check_credits is built to sit in front of exactly that kind of run, checking the estimated total against the actual balance before the first step spends anything — so an insufficient-balance outcome is a same-second answer at the planning stage, not an interrupted job partway through.

This is a pattern across the whole surface, not just these two tools

estimate_cost and check_credits are the general-purpose versions of something that shows up throughout Versely's agent capabilities individually — most defined capabilities carry their own cost note describing how that specific action is priced before it runs, rather than leaving cost as a surprise discovered after the fact. A slideshow edit that doesn't touch generation is flagged as free before you ask; a template run states its estimated cost before you launch it. The two tools this piece is about are for the case those per-capability notes don't cover on their own: a custom multi-item batch spanning several content types and models at once, where nothing built into a single capability already knows the total.

A Versely walkthrough

A concrete version of the whole sequence, run directly in Versely's agent chat:

Prompt: "Before you generate anything — I want 12 product hero shots and a 20-second video to go with them. What will that cost, and do I have enough credits?"

The agent calls estimate_cost with an items list — twelve images at the chosen model, one 20-second video at the chosen model — and returns credits itemized per item plus a total and the current balance, all in the same turn, before any generation has actually happened or any credits have moved. For a batch that's genuinely large, or that feeds into a longer multi-step workflow, a follow-up check_credits pass against that same total is the belt-and-suspenders step right before dispatch — check my credits before generating covers how that specific capability surfaces directly in the agent.

It's worth being clear that this isn't a separate, friendlier estimate living apart from what actually gets billed — it's the identical arithmetic. Versely's pricing page and worked breakdowns like what a finished 30-second ad costs run on the same underlying logic estimate_cost is querying mid-conversation, so a number returned before you generate anything is the same number you'd see on the receipt after. For the general shape of running many generations as one coordinated job rather than one at a time, Versely's batch generation glossary entry is the place to start.

Price the ambitious version of the batch first. Most of the time it turns out to be affordable, and the version you almost shipped instead — smaller, safer-feeling, and quietly not enough to actually find a winner — was never really the cautious choice to begin with.

FAQ

Does asking for an estimate cost any credits?

No. estimate_cost is a pricing lookup, not a generation — it returns numbers without producing any image, video, music, or audio output, so checking a plan's cost before deciding on it is free to do as many times as needed.

What's the difference between estimating once and checking credits separately?

estimate_cost prices a specific planned batch — these items, this model, this count and duration. check_credits is a simpler yes-or-no balance check against an estimated figure, meant to sit right before an expensive multi-step workflow actually starts running. In practice they're often used together: estimate first to get the real number, then gate the run's start against that number if the job is large enough that a mid-run failure would be costly.

Should I estimate every single generation, even a one-off image?

Not necessary — the value is highest for batches and multi-step workflows, where the total is easy to misjudge and a wrong guess either shrinks the batch unnecessarily or risks a partial failure. A single quick generation rarely needs this step; a twelve-image batch feeding a multi-scene video almost always benefits from it.