HISTORICAL DIG · JUL—AUG 2026
What does one accepted shot actually cost?
The same “five-second video” can be billed differently by route, version, audio, timing, and failure rules. A unit price hides rejected attempts, discarded output, and human rework.
AI SHORT-DRAMA MOTHER WORKFLOW · NODE 05
Relation to the current subject
Node 04 passes one route; node 05 decides whether it deserves post-production.
Freeze sample cash, active-labor, and attempt caps before no more than three representative shots enter one ledger. A successful download cannot hide failures, discarded output, or rework, and sunk spend cannot silently expand the next retry budget.
Record state at the time
- AI short drama
- Generation cost
- Deep record
- Developing
- Historical E2 · maker billing methods and one retry case rechecked · no BitShovel bill
R8 CURRENT JUDGMENT
Judgment at the time
Accept first, then divide by accepted seconds; without accepted seconds, unit cost does not exist.
Open full rationale and return rules
Node 05 is not a provider-price comparison. Node 04 must first deliver one exact route, a frozen input, and a hard acceptance rule. Before any calls, set a sample cash cap, active-labor cap, two-attempt maximum per shot, and accepted-shot target for no more than three representative shots. Record an estimate before confirmation and the actual charge after the receipt. Keep shared-subscription allocation separate from incremental use: prepaid is not free, and one shot should not carry the whole plan. Count hands-on setup, review, repair, edit, and audio work as labor; track queue and external waiting separately. Only duration that passes the node-02 acceptance rule becomes accepted seconds. If accepted seconds are zero, cost per accepted second is undefined—not zero—while the spend remains visible and the route stops. A pass sends only accepted assets and the cost receipt to node 06; it proves no episode economics, demand, revenue, profit, or repeatability.
- Who it was for
- People who leave node 04 with one exact route and need a small frozen-shot sample to decide whether it should enter post-production
- Why it mattered then
Open note
Cost drift often comes from a chain of small retries without a stop line, not one large price. Writing cash, labor, and attempt caps first—and keeping failures on the same ledger—lets the route stop before sunk cost invites another try.
- Where the judgment stops
Open note
This is an unrun, unfrozen accepted-shot costing method—not a price list, buying guide, bill, savings claim, efficiency benchmark, or return analysis. The visual's `u` is a fixed fictional unit. BitShovel has not called a provider, generated or accepted a shot, paid, recorded real labor, completed an episode, released it, or earned revenue.
BEFORE OPENING THE COST LEDGER
Fit check
If route, input, or acceptance still moves, return upstream instead of changing the question inside the ledger.
This record may help
- Node 04 passed one exact route with an openable frozen input, version, call boundary, and shot acceptance rule.
- Cash, labor, attempts, and representative-shot count can be capped before any call.
Do not use it yet when
- The route, input, version, or acceptance rule is still moving; return to node 04, 03, or 02.
- No actual-charge receipt is available, or the shared ledger would require real account, billing identity, keys, or unreleased material.
- You need an industry average, lowest price, episode profit, or demand proof—this node has none of those results.
HISTORICAL TRIAL · UNRUN, UNFROZEN 90-MINUTE ACTIVE-LABOR CAP
Historical trial
No more than three representative shots, two tries each; separate estimate, actual, labor, and waiting.
- Time needed
- A 90-minute active-labor cap for no more than three representative shots; generation, queue, and external review waits are separate; this round remains unrun
- Likely cost
- Freeze the sample cash cap, two-attempt ceiling per shot, and zero first-release revenue assumption before calls; reopen official pricing on the day of use
- Permission boundary
- The shared ledger keeps only fictional shot IDs, version hashes, and required figures; keys, accounts, billing identity, invoices, and unreleased material remain in authorized systems
- 01
First step
Open this step
Receive one route and the same frozen shot packet from node 04, then choose no more than three representative shots. Before calls, cap cash, active labor, attempts per shot, and accepted-shot target. For every attempt record estimate, actual charge, active labor, waiting, failure reason, and acceptance. Only then count accepted seconds and calculate actual charge per accepted second, active minutes per accepted shot, and rejected charge as a share of actual spend.
- 02
What should exist
Open this step
One cost receipt that preserves rejected and accepted attempts, separates estimate from actual and labor from waiting, and can show `undefined · stop`.
- 03
How to tell it worked
Open this step
Every accepted shot replays its exact route, input, attempts, actual charge, and labor. Zero accepted seconds never appear as zero cost, and no call crosses the precommitted cap.
- 04
Stop when
Open this step
Stop when a shot fails two attempts, the next call breaches any cap, the remaining sample exceeds the node-01 envelope, or the shot, asset, route, or acceptance rule must change.
- 05
How to back out
Open this step
Keep actual charges, failure class, and input hashes; do not add a third try. Return to node 02 for the shot, node 03 for assets, node 04 for the route, or use stills, limited motion, and manual compositing.
BITSHOVEL R8 ACCEPTED-SHOT LEDGER · FIXED FICTIONAL FIGURES
Method and interfaces
One rejection and one pass stay on the ledger; two failures read `undefined · stop`.
Open method boundary
The visual contains no provider, currency, account, model, or real frame. It separates actual charge, active labor, rejected spend, and accepted seconds, and refuses to dress a zero denominator as zero cost.
DEMO COST 05 shows counting structure only: 4u rejected plus 4u accepted makes 1.6u per accepted second for a five-second shot. If both fail, the denominator does not exist and the ledger reads `undefined · stop`. `u` is not currency and every figure is fixed fiction.
About this image and its source
Created by BitShovel on August 17, 2026 with no real provider, currency, price, account, bill, shot, project, model, or run result.
Open source page ↗SOURCES AND EVIDENCE
Sources and evidence
One official pricing page, one pinned open-source method, and one specific retry report explain why version, actual charge, and a confirmation gate matter. They cannot establish a BitShovel shot cost or an industry average.
Open evidence boundary
Historical E2 remains the old-page label. Revision 8 uses Vidu's current official pricing page only to show that route and conditions affect listed cost, a pinned OpenReels repository to separate estimate from actual usage, and narrows ArcReel #949 to one reporter asking for failure diagnosis and retry confirmation. The old Tencent table was not readable in this review, so none of its old figures becomes a current input.
- 01Maker pricing documentation · Rechecked
Vidu's official pricing page varies usage by route, version, audio, and conditions
Open source boundary
The page explains why a cost receipt needs an exact route, check date, and failure terms. Dynamic figures are not copied here; an actual-call receipt controls.
Open original source ↗ - 02Open-source method reference · Rechecked
Pinned OpenReels separates pre-confirmation estimate from post-render actual usage
Open source boundary
It supports an estimate-then-receipt method. It is not a BitShovel run, AI-short-drama bill, industry cost, quality, or revenue evidence.
Open original source ↗ - 03Specific user report · Rechecked
ArcReel #949: one reporter asked for failure diagnosis and retry confirmation
Open source boundary
The public issue supports a confirmation gate before retrying. It establishes no root cause, failure rate, billed loss, affected version, or general input-format conclusion.
Open original source ↗
REVISION RECORD
Revision record
R8 stops copying dynamic prices into a comparison and turns cost into a capped, replayable node receipt that can stop on zero output.
Open 8 revisions
- Revision 1
Reframed one model price as accepted-shot spend, human time, and rework source.
- Revision 2
The old page used dated Vidu and Tencent tables and separated charge per accepted second from human minutes.
- Revision 3
Added a zero-revenue first-release downside so eligibility or views could not become budgeted income.
- Revision 4
The old site replaced an editorial generated hero with an open-licensed released-film frame and moved process UI downstream.
- Revision 5
The old site moved to traceable UI directly tied to costing instead of letting one film represent every task.
- Revision 6
The old site reiterated the evidence boundary between released narrative media and costing-process UI.
- Revision 7
Removed narrative lead media unrelated to costing and kept traceable task-aligned sources.
- Revision 8
Narrowed the five-shot price comparison to a precommitted ledger for no more than three shots; separated estimate, actual, subscription, labor, and waiting; made zero accepted seconds undefined and a stop; and corrected the ArcReel generalization.
WHAT THIS RECORD LEAVES
What this record leaves
Node 05 does not produce a “cheap model.” It produces an accepted-shot cost receipt that keeps failure visible.
Only when accepted shots, actual charges, and active labor replay without crossing the written cap do the assets and receipt enter node 06. Failure returns to the shot, asset, or route—no third try and no future views or revenue funding today's budget.
Back to the Dig index