What a New-Category Launch Costs in Model Tokens

The estimate works because the three workloads have almost nothing in common except the model that serves them.

Ad copy is short output, medium input, and high rerun count. Each variant carries the positioning statement, the segment description, the platform constraints and two or three examples of voice, which is a substantial prompt for a headline and two body lines. Variants get generated in batches of ten or twenty, reviewed, and regenerated with tightened instructions.

Landing pages are the opposite: long output, long input, and low rerun count. A page needs a headline, subhead, three or four benefit blocks, proof sections, objections and a call to action, and it needs the full positioning frame plus brand voice guidance in the prompt. You write twenty of them, not two thousand, because each one has to be reviewed by a human before it goes live.

Support replies are short on both sides but high in volume. Each reply needs a customer message, an order or product context block, and a policy snippet, and produces two or three paragraphs. Volume is driven by expected contact rate during the test, not by catalog size.

The practical consequence is that ad copy dominates the count of assets while landing pages dominate the count of tokens per asset. A budget that treats them as one pool will be wrong in both directions: too generous for the ad batch, too tight for the page batch.

Strategyzer's value proposition work makes the same point from the marketing side. Six out of ten ideas fail in the real world because teams launch something nobody wants, which argues for mapping jobs, pains and gains before you mass-produce copy per Strategyzer. In token terms, the mapping happens once in a long input prompt, and the volume of output is what you should be watching.

The numbers below are working estimates, not measurements from your account. Treat them as a starting template and replace each one with a count from ten real examples before you commit the budget.

Two calibration notes. First, output tokens per ad variant at around 2,000 assumes a headline, two body variants, a description and a short set of alternate hooks generated together so a reviewer sees options in one pass. If you generate a single headline per call you will spend more on repeated prompts and learn less per dollar. Second, landing page output at 6,000 tokens is roughly 4,500 words of draft, which is more than the page needs; budgeting for it acknowledges that the model will restate the brief and produce rationale you will discard.

For the landing page workload specifically, there is a hard constraint that has nothing to do with tokens. Only about 13 percent of A/B tests reach statistical significance in favor of the variant per Digital Applied's landing page statistics compilation. That means generating forty page variants and testing all of them is a waste of both traffic and token budget. Generate variants to explore messaging, then test two or three with enough traffic to conclude something.

If you want a mental model for what counts as a unit, the Langflow ad copy template is a useful reference: it collects product, audience, benefits, tone, platform and number of variations, then generates platform-optimized variants against different strategic angles via the Langflow template. Each variation that comes back is one output unit in the table above. The template also shows why input is not trivial: the prompt carries platform specifications and web research, so the 900-token input estimate is on the low side if you feed live search results into every call.

Take a company with 400 products grouped into 12 collections, launching a sub-brand aimed at a segment the current catalog serves badly. The two-week test plan is:

• 200 ad copy variants across three platforms
• 20 landing pages, one per collection plus eight segment-specific pages
• 2,000 support replies covering the top 40 objections and the order-status questions the test traffic will generate

Apply the table with a 2.0 average rerun multiplier across all three workloads to keep the arithmetic honest.

Ad copy. 200 variants times 2.0 reruns is 400 generations. Input: 400 times 900 tokens is 360,000 input tokens. Output: 400 times 2,000 is 800,000 output tokens.

Landing pages. 20 pages times 2.0 is 40 generations. Input: 40 times 3,500 is 140,000 input tokens. Output: 40 times 6,000 is 240,000 output tokens.

Support replies. 2,000 replies times 2.0 is 4,000 generations. Input: 4,000 times 1,200 is 4,800,000 input tokens. Output: 4,000 times 300 is 1,200,000 output tokens.

Totals: 5.30 million input tokens and 2.24 million output tokens. At a mid-tier list price of $2 per million input and $10 per million output, which sits in the middle of the published range for capable models per CostGoat, the bill is $10.60 for input and $22.40 for output, or about $33 before batch discounts. With the batch tier at half price the same work lands near $16.50.

That is the low hundreds of dollars ceiling the short answer describes, and it explains why the number feels anticlimactic. The real risk is not the list price. It is discovering in week two that someone has been regenerating landing pages without logging them, or that support replies are going out unbatched at the full interactive rate because the test funnel has real customers in it and nobody wanted to queue them.

Rerun discipline is where the money actually moves. In the example, dropping the average rerun multiplier from 2.0 to 1.5 saves roughly a quarter of the total. That is a process change, not a procurement one: review in batches, write rejection reasons down, and regenerate against the reasons.

A budget that holds has four parts, and skipping any one of them is how teams end up with a surprise line item.

1. Pilot batch with measured counts. Before committing, run ten units per workload and record actual input and output tokens. Replace the table numbers with your own. This costs a few dollars and eliminates the largest source of error.

2. Hard cap with alerts per workload. Create three separate spending limits, one per workload, at roughly 1.5 times the pilot-based estimate. Alerts at 50 and 80 percent. Separate caps matter because a run-away landing page loop should not be able to starve the support reply bank, and because the per-workload tally is the only way to learn which workload was misestimated.

3. Tally per finished asset. Log tokens, model, workload and asset identifier on every call. Then compute cost per finished asset at the end of week one. This is the number that lets you predict a full category launch, which is the decision the test exists to inform.

4. A stop rule written before the test starts. Choose the condition in advance, for example: if cost per finished asset exceeds three times the pilot estimate for two consecutive days, pause that workload and review the prompt. A stop rule written after the bill arrives is not a rule, it is a reaction.

One more control is worth the effort: keep the positioning frame in a single versioned prompt fragment shared by all three workloads. When the frame changes, as it will mid-test, you change it once. If instead each workload carries its own copy of the frame, you will regenerate all three when only one needed to move, and the rerun multiplier quietly doubles.

The budgeting logic mirrors what good positioning work already demands. A category move only holds up if the frame is specific enough that a buyer can check it, and the guide to category design versus positioning is blunt that most companies in the tens of millions need positioning clarity before a category launch is even on the table per PitchKitchen. Token budget is a proxy for the same discipline. If you cannot say which workload each generation belongs to, the framing is not specific enough yet either.

Four failure modes account for most overruns, and all four are visible before you spend anything.

Unbounded conversation history. If each support reply is generated in a thread that carries prior messages, input tokens grow with every turn. A 2,000-reply bank that looks cheap on paper can multiply its input side by five. Generate each reply from a fixed context block, not from an accumulating chat.

Regeneration without a reason. The rerun multiplier is the most sensitive number in the model. A team that rerolls on taste rather than on a documented rejection reason will run at 4x or 5x and will not notice until the cap trips.

Long prompts copied per call. A 3,500-token landing page prompt that includes the entire brand book is fine at 40 calls. Used in a loop across 2,000 calls it becomes the dominant cost. Split what must be in every prompt from what can be retrieved.

Paying interactive rates for batch work. Batch tiers exist precisely for work no human is waiting on, and the price difference is large enough to change the shape of the budget as the price comparison shows. Ad copy and landing page drafts belong in batch. Live support replies may not, if a customer is waiting, and that is a deliberate trade you should price rather than discover.

The way to keep these four under control is to treat the test like any other production run: one prompt per workload, versioned, with a logged token count per output and a named owner for the stop rule. When a workload misbehaves, you want to know within an hour, not at the fortnightly review.

If the plumbing is the part that slows you down, Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key, which means the three workloads can share one billing surface and one spend view while you keep the workload caps separate in your own logging. For teams that would rather hand the whole production run to a specialist, Quanta Experts can take the positioning frame and return the finished ad variants, pages and reply bank as deliverables.