DCO: cost model

01

Volume with a 30% waste rate

Every batch includes frames that will not pass the judge loop and have to be regenerated. The working rate used here is 30% — not every image discarded outright, but 30% more API calls budgeted than the number of panels actually delivered, so the discard-and-retry cycle is already paid for. A 1.3× multiplier on the panel count gives the number of API calls to budget.

Case	Calls
20-panel story	20 × 1.3 = 26 API calls
30-panel story	30 × 1.3 = 39 API calls
This site's scenario: 6-beat story	6 × 1.3 = 7.8 → rounded up to 8 API calls

The rounding matters: a fractional call does not exist, so the working number for one of this site's six-beat stories is 8 calls, not 7.8. That is the figure used in every calculation below.

02

Cost per image, by model tier

Three image-generation tiers, each suited to a different stage of the pipeline. The useful-image cost already has the 30% waste rate folded in: it is the figure to multiply by the number of panels actually delivered, not by the number of API calls.

Model	Best for	Cost
Gemini 3.1 Standard/Flash	Fast drafts and preliminary storyboards	$0.04 base → $0.052 per useful image
Gemini 3.1 Pro	Balanced, standard visual continuity	$0.134 base → $0.174 per useful image
Gemini 4 Argon	Top tier: high spatial consistency, cinematic 4K detail	$0.24 base → $0.312 per useful image

Check against the reference figure: a 30-panel story on Argon costs 30 × $0.312 = $9.36 — the same number as 39 calls × $0.24 base. The two ways of counting agree, which is what makes the per-useful-image figure usable directly against a delivered-panel count.

03

The text prompt behind each image

Each image call is preceded by an LLM call that writes the actual generation prompt. Four components make it up.

Component	Average volume	Note / detail
System prompt + character sheet	1,000–2,000 input	Style rules, visual constraints, detailed character description
Multi-shot context / history	1,000–2,500 input	Past winning prompt examples, to keep dynamic consistency
Reference images as input (vision)	~1,000–1,500 input	If 2–3 reference images are passed in, processed as visual tokens
LLM output	300–800 output	The final prompt and technical parameters (JSON/Python spec) for the image call

04

Text cost for one story

Worked example: a 30-panel story, 39 API calls at the 30% waste rate, an average prompt of 4,500 input tokens and 500 output tokens per call. Total volume for the story: roughly 175,500 input tokens and 19,500 output tokens.

LLM text tier	Text-token cost / story (39 gen.)	Incidence on the Argon-4 image cost ($9.36)
Gemini 3.1 Flash/Standard	~$0.02–$0.04	< 0.5%
Gemini 4 Argon / Pro-class (text)	~$0.30–$0.45	~3%–4.5%

The incidence column compares the text cost of writing the prompts against the image cost of generating them on Argon ($9.36 for this 30-panel story): on the cheap tier the prompting text is noise, under half a percent of the bill; even on the expensive tier it stays under 5%. Prompt-writing text is not where the budget goes — image generation is.

05

Claude Sonnet for story generation

A separate cost from the two above: one Claude call writes the structured description file for the whole story — generate_story_spec() in the technical breakdown — not per panel, once per story.

Operation	Standard (per 1M tokens)	Batch API (−50%)
Input tokens (prompt)	$3.00	$1.50
Output tokens (generation)	$15.00	$7.50
Prompt caching (write)	$3.75	N/A
Prompt caching (read)	$0.30	N/A

Figures per 1M tokens. Assumption, not given: a story-spec call for a six-beat story is estimated here at 4,000 input tokens (brief, character bios, a couple of worked examples) and 3,000 output tokens (the full beat-by-beat JSON). That gives $0.057 per story at the standard rate, or $0.029 on the Batch API. Either way it is small change next to the image cost — which is the expected shape: Claude writes the story once, Gemini renders it many times.

06

Total cost: per story and per campaign

Adding the three pieces together — image generation, the per-image prompting text, and the one Sonnet story-spec call — for this site's six-beat scenario: 8 API calls per story, not 6, because that count already carries the 30% waste rate from Chapter 01 — six delivered panels, judge-loop retries included — plus the standard Sonnet rate for the one story-spec call:

Tier	Image	Per-image text	Sonnet story-spec	Total / story
Flash	$0.32	$0.004–$0.008	$0.057	~$0.38
Pro	$1.07	$0.06–$0.09	$0.057	~$1.19–$1.22
Argon 4	$1.92	$0.06–$0.09	$0.057	~$2.04–$2.07

Scaled to the full campaign — sixteen 6-beat creative sets over twelve weeks, the same figure the overview page's time-to-market section derives from the refresh-cadence benchmark — the generation-and-control stages (stages 1–3, not formats or export) cost on the order of $6 on Flash, $19 on Pro, $33 on Argon 4 for the whole campaign, standard rates; roughly 5–10% less with Sonnet on the Batch API. These are API list prices for stages 1–3 only — they are not a quote, and they say nothing about the time a human reviewer spends, which the overview page's production metrics cover separately.

Open — not priced here

Formats and export (stages 4–5 of the engine — see Chapter 06/07 of The Engine: generation, control, export) are not in this total. Reformatting a shot into a new aspect ratio may be a cheap crop or a full outpaint call depending on the shot, and no per-call price for that operation has been fixed yet — so it stays an open parameter rather than a guessed number.

A more realistic version of the above, beyond this page's own six-beat example. Assumptions, declared as such: a mascot-pair brand story like the ones on this site usually runs closer to ten beats once it has a real arc — setup, development, turn, payoff — rather than the six used above for simplicity; the waste rate is widened to a 30–50% range, since a flat 30% floor is optimistic once a judge is actually rejecting real output; and the model is fixed to Pro — the realistic middle tier for client work, neither the cheapest nor the top. Formats and export, flagged as unpriced just above, are estimated here too: of the three extra aspect ratios every approved shot needs beyond its native format, one is assumed to require a full outpaint call at the Pro rate, the other two surviving as a free reactive crop.

Waste rate	API calls	Image generation	Per-image text	Sonnet story-spec	Formats/export (est.)	Total / story
30%	10 × 1.3 = 13	$13.91	$0.78–$1.17	$0.09	$10.70	~$25.50–$25.90
50%	10 × 1.5 = 15	$16.05	$0.90–$1.35	$0.09	$10.70	~$27.70–$28.20

The Sonnet figure is the same $0.057 assumption from Chapter 05, rescaled: output tokens grow with beat count (roughly 500 tokens/beat there), input stays flat at 4,000 tokens for brief and character bios, which gives about 5,000 output tokens and $0.09 at ten beats. Formats/export is ten approved beats × one assumed outpaint call at the Pro rate ($1.07) — it does not grow with the waste rate, because reformatting only touches shots that already passed the judge, never the discarded retries.

Scaled to the same sixteen-set, twelve-week campaign used throughout this page, at ten beats per set on Pro: on the order of $410–$450 for the whole campaign, formats and export included — against the $19 quoted earlier for stages 1–3 alone. The gap between those two numbers is exactly what "not priced here" was hiding.

A gap in everything above: the judge's own call. Every total so far adds image generation, the prompt-writing text and the Sonnet story-spec call — it never prices judge_and_correct() itself, the Gemini VLM call in chapter 09 of DCO Engine: technical description that looks at a generated shot against the reference images and returns a per-assertion verdict. That call runs once per generation attempt, not once per delivered panel — so its count is the same inflated number as the API-calls row above (the 30% or 30–50% waste figure), not the smaller count of panels actually shipped.

No benchmarked price exists for it; this is a placeholder by analogy, flagged as such below. A judge call and the per-image prompting-text call of chapter 03 have a similar shape — a handful of images as vision input, a compact structured output — so this page reuses that call's price as the judge's estimate: $0.004–$0.008 on Flash, $0.06–$0.09 on Pro or Argon 4. It is as likely to be too low (a verdict with per-assertion severity and class is more structured than a prompt) as too high (it compares against fewer images than the full generation prompt does).

Scenario	Story	Judge calls	Judge cost	Revised total/story
Six-beat, Flash	8 calls (Chapter 01)	8	$0.03–$0.06	$0.38 → ~$0.41–$0.44
Six-beat, Pro	8 calls	8	$0.48–$0.72	$1.19–$1.22 → ~$1.67–$1.94
Six-beat, Argon 4	8 calls	8	$0.48–$0.72	$2.04–$2.07 → ~$2.52–$2.79
Ten-beat Pro, 30% waste	13 calls (Chapter 06)	13	$0.78–$1.17	$25.50–$25.90 → ~$26.3–$27.1
Ten-beat Pro, 50% waste	15 calls	15	$0.90–$1.35	$27.70–$28.20 → ~$28.6–$29.6

What it does to the two campaign totals already on this page. On the bare six-beat, stages-1–3-only figure, the judge call is a real jump — roughly +20% on Flash, +50–80% on Pro and Argon 4 — because that figure was always missing a whole category of call, not a rounding error. On the realistic sixteen-set campaign of Chapter 06 above, which already includes formats and export, the same judge cost is a much smaller share of a much bigger number: the $410–$450 campaign total becomes roughly $423–$472, a 3–5% increase. The two percentages describe the same dollar amount against two different bases — the alarming one was always measuring against a total this page itself flagged as incomplete.

The real cost risk is not this call — it is the waste rate moving. The judge call itself, at a few cents to a dollar per story, is noise next to image generation, which is most of the bill throughout this page. What would actually move the budget is stricter checks (the colour, logo and tone checks of chapter 12 of DCO Engine: technical description) lowering the first-pass yield and pushing more shots into retry — and nothing on this page measures that effect yet, because nobody has run the B4 study that chapter 12 proposes. Chapter 07 below adds a lever for exactly this risk.

07

Optimisation strategies

Four levers, in the order they are worth pulling. These are proposals, not figures in production yet.

Prompt caching on the static part. The system prompt and character sheet (1,000–2,000 tokens, chapter 03) repeat unchanged across every call in a campaign. Caching them turns a $3.00/1M input cost into a $0.30/1M read after the first write — a 10× reduction on the one block of text that never changes between calls.
Batch API wherever the job isn't time-critical. Story-spec generation and most prompt-writing calls don't need a synchronous answer — the 50% discount on both Claude legs (chapter 05) applies directly.
Tiered model selection by stage. Flash for the first generation and every judge-rejected retry, Pro or Argon 4 reserved for the shot that has already passed — instead of generating every candidate at top tier and discarding 30% of the expensive ones.
A compact character sheet instead of re-sending reference images. Reference images as vision input cost ~1,000–1,500 tokens per call (chapter 03); a well-written text description of the same identity constraints is typically shorter and removes that cost from every call after the first.
Run stricter or new checks in shadow mode first. A rule addition (colour, logo, tone — chapter 12 of DCO Engine: technical description) logs what it would have flagged without acting on it, so its effect on the waste rate is measured against the fixture library of open question E there before it is allowed to trigger a real retry on a client campaign. Turns the cost risk of a stricter judge from a guess into a number, for the price of a few fixture runs instead of a live campaign's worth of extra retries.

08

The reserved zone for the template

A template is an HTML layout with fixed boxes: in a 1:1 unit, the headline might sit in the top 18%, the price-and-CTA block in the bottom 22%. Those coordinates are known in advance and don't change. Today's order is: generate the image first, then the platform overlays the boxes on top. If a character's face sits in that bottom 22%, the price lands on it.

The reactive fix — after the image exists, choose the crop that keeps the cast out of the box — the engine can already do, because it has the description file and knows where the characters stand in every beat (Chapter 06 of the overview post). The proactive fix is the more interesting one: the box geometry enters the staging instruction itself. The description file gains a field such as reserved: bottom 22%, and the staging line becomes “both characters in the top two-thirds, bottom fifth clear tablecloth.” The scene is composed with the space already left empty.

So yes — this is a branch of the pipeline that reads a set of predefined templates, but it never “looks” at them visually: it reads a small geometry table, one row per template and format, saying which rectangle, at which coordinates.

# one row of the template-geometry config table
{"template": "price_cta_1x1", "format": "1:1",
 "reserved_zone": {"position": "bottom", "height_pct": 22}}

# the field it adds to the story's description file
{"beat": 4, "reserved_zone": "bottom 22%",
 "staging_note": "both characters upper two-thirds, bottom fifth clear"}

The configuration table — data entry, not a model: one row per template and format, naming the rectangle a real client's templates actually reserve.
One added field in the description file, which already exists — so this is a field, not a new architecture.
A check that verifies the reserved rectangle really is quiet — low variance, few edges — about twenty lines of image analysis, and flags it when it isn't. No model to train.

Cast-aware cropping is already implicit in the data the engine produces today; reserved-rectangle staging is designed, not built, and is waiting for the template geometry of a real client to be put to the test.

09

Where the formats go

The four aspect ratios in chapter 06 — 1:1, 4:5, 9:16, 16:9 — are a standard industry convention, not a figure specific to any one client: every format an ad can run in reduces to one of these four frames. The table below is that convention, not a site-specific invention.

Aspect ratio	Typical placement
1:1	Instagram/Facebook feed, Google Display Network, Pinterest
4:5	Instagram/Facebook feed (mobile-optimised), LinkedIn feed
9:16	Instagram/Facebook Stories and Reels, TikTok, YouTube Shorts
16:9	Classic display banners, YouTube pre-roll/in-stream, CTV

The engine itself never learns any of this: a manifest row (chapter 06 of the overview post) only ever says a format field like 9:16, never "Instagram Story." Which row goes to which placement is decided one layer downstream, by the adapter into whichever DCO tool the client already runs — Flashtalking, Celtra, or DV360's own Studio, the three named in DCO and the Agency Market — according to what the agency actually bought for that campaign. Building a new adapter is the only place platform-specific knowledge belongs; the engine stays platform-agnostic by design.

10

What one campaign run costs, worked out

The time this architecture compresses is the time of producing the pool, and it can be measured without asking a client for data. A worked example, with the assumptions spelled out: a twelve-week display campaign, three slogans, one locked cast, six-beat stories, four formats. Industry rules of thumb suggest refreshing display creative every two to four weeks and keeping three to five variants in rotation (see this guide to banner refresh frequency): at a three-week cadence with four variants in rotation, the campaign consumes sixteen distinct creative sets, which at six beats by four formats comes to 384 deliverable units.

The point is which of those numbers template-based production already solves. Resizing and export, yes: one vendor reports going from eighty hours to eight to update and export a campaign (see this review of creative-production KPIs) — exactly the ground reformat_to_formats() and export_manifest() cover (chapters 05–06 of DCO Engine: technical description). What it does not solve is the sixteen distinct sets: traditionally each one is a shoot or an illustration commission, so in practice the sixteen collapse into four real concepts plus twelve recolourings — which is exactly template fatigue. run_campaign() produces the sixteen sets from the same locked cast plus sixteen story files passed to generate_variant().

The metrics reported for each run map directly onto CampaignResult.stats, defined in chapter 07 of DCO Engine: technical description — the same generated, passed_first_try, passed_after_correction, discarded, yield and refusal_rate fields serialised in result.json there. What's reported is approved variants per run, machine time per variant, minutes of human review per batch, and refusal rate. CTR and cost per conversion are not reported: they depend on the decision and measurement layers (layers 2 and 4 in the parent post's four-layer table), which are not this one.

11

What the campaign total means, and a leaner alternative

Worth spelling out, since the phrasing in Chapter 10 invites a reasonable misreading. The campaign figure above adds no time-based or distribution cost: trafficking, impressions and media spend are not this engine's job, are not priced anywhere on this page, and are paid by the client separately — exactly as already stated for the stage 1–3 figures earlier. The twelve weeks only justify how many distinct creative sets a campaign needs, under the refresh-cadence benchmark cited in Chapter 10; they add no per-week cost of their own. The ×16 means sixteen distinct sequences, not a cost of publishing or of duration. Each of those sixteen is exactly the atemporal, predefined unit this page has been costing throughout — one story, its images, its formats, its metadata — run sixteen times instead of once, because a campaign that must not wear out over twelve weeks needs sixteen different creative sets, not one set stretched over time.

The breakdown Chapter 10 left implicit, plus a cheaper alternative worked the same way:

Scenario	Model	Sequences	Cost / sequence	Campaign total
Maximum (as above)	Pro	16	$25.50–$28.20	~$410–$450
Lean, all Flash	Flash	5	$7.50–$8.20	~$37.50–$41
Hybrid (1 Pro + 4 Flash)	Pro + Flash	5 (1+4)	varies	~$55.50–$61

The last two rows answer a cheaper production idea: five variants in random rotation instead of sixteen, generated on Flash rather than Pro, with the Sonnet story-spec call left unchanged. Flash's image-generation call ($0.32 against Pro's $1.07) and per-image text ($0.004–$0.008 against $0.06–$0.09) drop straight into Chapter 06's formula; formats/export is extended to the same rate on the same one-outpaint-in-three logic — $3.20 per sequence instead of $10.70. That gives roughly $7.50–$8.20 per sequence on Flash, against $25.50–$28.20 on Pro — at five variants, all on Flash, a campaign runs about $37.50–$41. The hybrid row is the engineering idea described alongside this question: one reference sequence generated at full Pro quality, then fed back in as conditioning with an inflated prompt for the remaining four on Flash. It lands around $55.50–$61 — cheaper than pure Pro, more than pure Flash, trading part of the saving for whatever consistency the Pro-seeded reference buys.

Open — not verified here

Two assumptions in this comparison carry the same flag as the rest of this page. First, the 30–50% waste range was derived for Pro and is simply reused here for Flash, with no evidence a lighter model rejects at the same rate under the same judge — it could be higher, from weaker fidelity to the brief, or similar, if the story itself is simple; this page doesn't know which. Second, the prompt-inflation step in the hybrid row is a production idea, not a costed one: whatever time it takes to engineer that conditioning step doesn't appear in any of these numbers. Rotating five variants at random rather than delivering all of them is a trafficking choice and changes nothing here either — the same distinction as the ×16 above: generation cost is paid once per sequence produced, independent of how, or how often, a finished sequence is later served.

12

Multi-brand, multi-agency: what changes when the engine is shared

Every figure above prices one run for one brand. The business model discussed in The Agency Channel in Italy is different: one engine shared by five to ten small agencies, each with a few brands, each launching perhaps two or three campaigns a month (a working assumption, not data). Sharing changes what has to be counted. There are three layers of cost, and only the first is an API cost.

Layer	What it contains	Scales with
Per run	API calls of Chapters 01–11: generation, judge, correction, formats	Campaigns (linear)
Per brand	Configuration file, reference pair, calibration set: human time, plus the API calls of the calibration runs	Brands onboarded (one-off; again if a brand's look changes)
Shared platform	Hosting, storage, job queue, monitoring, review tooling, maintenance	Fixed; spread over every tenant

The first layer is what this page already prices. At two to three campaigns a month per agency, it comes to the following, reusing the campaign totals of Chapter 11 (the arithmetic is a plain multiplication, rounded):

Scenario	Per campaign	Per agency / month (2–3 campaigns)	5–10 agencies pooled / month
Maximum, Pro (16 sequences)	~$410–$450	~$820–$1,350	~$4,100–$13,500
Lean, all Flash (5)	~$37.50–$41	~$75–$123	~$375–$1,230
Hybrid (1 Pro + 4 Flash)	~$55.50–$61	~$111–$183	~$555–$1,830

These figures assume every campaign has the size of the Chapter 11 scenarios, which is itself an assumption: a small agency's real campaigns may well be smaller. The point of the pooled column is something else. API cost is linear in campaigns, so pooling agencies does not make a single run cheaper. What pooling changes is the denominator of the other two layers: the shared platform's fixed cost F is divided by ten to thirty campaigns a month instead of two or three, roughly three to fifteen times less per campaign than a dedicated service would carry. As a condition: with a revenue R per campaign and a variable cost v per campaign (the first two layers), the platform breaks even at N = F / (R − v) campaigns a month. This is a formula, not an estimate: F and R are not known.

Two details of the technical side make the shared design plausible rather than a rewrite. The job interface in DCO Engine: technical description is already file- and API-based, so a shared service differs from a single-brand run in who submits the jobs and where each brand's files live, not in the engine. And every manifest row already carries a brand key, so one tenant's output can be filtered from another's; a tenant key above it is a new field this documentation does not specify yet.

A forfait on the three unknowns above, then — every number here is an estimate Claude worked out from the figures already on this site, not a measurement, and it is marked as such throughout.

Platform fixed cost F. Kept deliberately small, because nothing here has to be more than a database, object storage for generated images, a job queue and basic monitoring — a summary of that structure is in chapter 11 of DCO Engine: technical description. Call that €80–150 a month at this scale, rounded here to a flat F ≈ €150/month. Left out on purpose: the agency-facing API or dashboard an agency would actually log into to submit a job and review its output. That interface has not been designed yet — it is a one-off build cost, not a running one, and the same chapter 11 says so.

Per-brand onboarding. Writing the configuration file of chapter 02 is roughly an hour; building and labelling the small calibration set it needs — "a few dozen shots", per item D in DCO Engine: technical description — is another three to four hours of a reviewer's time; the calibration run itself is a handful of API calls, cheap enough to fold into the per-campaign figure below. Add two to three hours of creative-direction time choosing and tuning candidates out of generate_reference_pair(), per open question B in DCO Engine: technical description. Call it six to eight hours in total, ≈ €225–250 per brand, one-off, at a loaded reviewer/creative rate of roughly €30–35/hour. Not covered by this figure: the recurring version of the same creative-direction work, when a brand's own story moves it into a different visual world mid-campaign — that is closer to a second onboarding than a tweak, and stays unpriced here.

Variable cost per campaign, v. The lean-to-hybrid API range from Chapter 11 above, treated here at rough euro/dollar parity since the point is magnitude rather than an invoice: €35–55. Add roughly ninety minutes of human time across the three checkpoints of The Engine: generation, control, export (€25–50 at the same rate as onboarding). v ≈ €90/campaign at the mid-point of that range.

Revenue per campaign, R. This is the one number with no basis in anything on this site — a placeholder price, not a decision. Call it R ≈ €200/campaign, in the range of a €450–600 monthly subscription covering the two-to-three-campaign assumption. At those numbers, margin (R − v) ≈ €110/campaign, and the break-even condition above becomes N = F / (R−v) ≈ 150 / 110, just under two campaigns a month. If these are in the right neighbourhood, a single small agency already clears the platform's flat cost on its own at its normal two to three campaigns; pooling five to ten agencies isn't needed to survive, it's there to turn a thin break-even into a comfortable one, and eventually to amortise the undesigned agency-facing interface above.

Two to three campaigns a month. Still a working assumption, not a benchmark this site has found evidence for. One way to read it as plausible rather than arbitrary: a small agency rarely runs several large campaigns at once, but often holds a handful of smaller retainer clients, each refreshing creative at something like the quarterly cadence already cited in Chapter 10. Six to ten such clients, each refreshed roughly once a quarter, land in that same two-to-three-a-month range in aggregate. A reasoned guess, not a count.

Open — the price is still a decision

The forfait above fills in order-of-magnitude numbers; it doesn't settle anything. Still open: the real euro/dollar conversion, treated here at rough parity for an order of magnitude only; the pricing model this actually lands on (per campaign, per seat, subscription) and the real R it produces; the real campaign frequency of real small agencies, once there are some to ask; and the build cost of the agency-facing API and dashboard sketched in chapter 11 of DCO Engine: technical description, which sits entirely outside F above.