How Fenfire meters AI honestly
· How it works
Reserved before, settled after, recorded at actual cost. What it takes to make sure you are never charged for a generation you did not get.
AI features cost real money to run, and most tools handle that by hiding it. You get a number that goes down, no explanation of what made it go down, and a quiet hope that you will not audit it too closely.
We took the other route. Here is exactly how metering works in Fenfire, including the parts that were inconvenient to build.
Reserved before, settled after. Every generation reserves credits up front and then settles against what was actually produced.
That ordering matters. Reserving first means you cannot start a job you cannot afford and discover it halfway through. Settling after means that if the provider returns three images when you asked for four, you are charged for three. The reservation is a hold, not a charge, and the difference is released.
You are never charged twice for the same click. Start a batch, close your laptop, reload the tab, come back on a different machine: the job keeps running and the results find their way back to you.
Under the hood, every submission carries an idempotency key generated in your browser before the request leaves. The browser keeps a durable receipt scoped to that brand. A lock that allows one submission at a time blocks a duplicate submit across tabs. And a reopened tab attaches again to the job already running instead of quietly starting a second one.
The point of all that machinery is one sentence: a bad network moment cannot cost you money.
Four variations means four generations. When you ask for up to four variations, you get four genuinely separate generations: one job fanning out into several real provider calls, not one image returned four times with the saturation nudged.
So four variations are metered as four. We say that plainly rather than burying it, because the alternative is a pricing page that implies variations are free and a credit balance that disagrees.
The record stores what it actually cost. Every generation writes down its estimated cost and its actual provider cost, along with the model, the quality setting, how long it took, and how it ended.
That is not an average smoothed into a plan tier. It is the real number. HD costs more than standard, and the interface tells you that before you spend it, not after you have.
Publishing is recorded on the real outcome. The same discipline runs through publishing. Organic publishing is unlimited from Starter up, subject to a fair use limit. Where a post is metered, which means Creator's 60 publishing actions a month or, once the X add-on opens, an X post drawing X units, the count follows what actually happened at the platform.
A post is marked published only after the network returns a confirmed post ID. If it fails, it retries a bounded number of times and then says plainly that it did not go out. There is no green checkmark over a post that never existed, and nothing is counted for a post that never published. Every social write is idempotent, so a retry cannot post twice and cannot charge twice.
The commercial rules, stated once. Included image credits reset on monthly allowance windows, and so do Creator publishing actions and X units. They do not roll over or compound, including when you pay annually.
Purchased credit packs sit in a separate balance, are consumed only after your included credits are used, and do not expire while your account is retained.
Video generation is billed per clip, outside every subscription and every image credit allowance. Your image credits stay untouched by video.
Credits, like everything else, are scoped to a brand. An agency running eleven clients gets eleven sealed balances.
The question to ask any vendor: "What did that image actually cost?"
If the answer is a tier name rather than a number, you are being told what you were budgeted, not what you spent. We can answer it in code, on request. Bring the hard version of it to a demo.
See the plans: https://socialbee.hyve-os.com/pricing