If you landed here from a model comparison post, you already know the benchmark numbers. Reasoning scores, context windows, tokens per second, price per million. Useful data, and none of it answers the question you actually have: which model should I point at my content pipeline, and how do I wire it up so the output lands in production instead of in a Slack thread?
This post answers that. It is written for the person who has to ship the content.
The three-axis framework
Model choice for content work comes down to three axes. Score your use case on each one and the answer usually falls out.
Axis 1: Revision tolerance
How much editing are you willing to do per piece?
- Low tolerance (publish with light proofing): you need the strongest available reasoning model. The cost delta per article is a rounding error next to an editor's hourly rate.
- High tolerance (draft is a starting point, a human rewrites 40% of it): a faster, cheaper model wins. You are paying for a scaffold.
Most teams misjudge this axis. They buy the premium model and then rewrite everything anyway, or they buy the cheap model for content that goes out unedited.
Axis 2: Volume shape
- Few pieces, high stakes (pillar pages, comparison pages, launch posts): premium model, long context, one call per piece.
- Many pieces, low stakes (product descriptions, alt text, meta descriptions, category blurbs): cheap and fast model, batched.
A 2,000-product catalog needing meta descriptions is a completely different job from a 3,000-word technical guide, and it should not use the same model.
Axis 3: Structure requirements
This is the axis nobody mentions in benchmark roundups, and it is the one that breaks pipelines.
CMS content is a typed object: a title with a character limit, a slug, an SEO description under 155 characters, a body in markdown, a set of tags drawn from a fixed vocabulary, a relationship to an author object. If the model returns loose prose where your schema wants a 155-character string, your pipeline fails at the write step.
So the real question on this axis is: how reliably does the model produce output that conforms to a schema? Test that specifically. Give it your actual object type definition and ask for 20 objects. Count the ones that validate.
Score your use case
The three axes give you a tier, not a single model name. Cosmic's AI API groups models into three token-cost tiers, and the tier is the decision that matters for budgeting:
- Budget, 1.0x multiplier: GPT-5 Nano, GPT-5 Mini, Claude Haiku 4.5
- Standard, 2.0x multiplier: GPT-5, GPT-5.2, GPT-5.2 Codex, GPT-5.5, Claude Sonnet 4.6, Claude Sonnet 5, Claude Opus 4.7, Claude Opus 4.8, Gemini 3.1 Pro, Kimi K3
- Premium, 4.0x multiplier: Claude Fable 5
Map the six common content jobs onto those tiers and you get a starting configuration:
| Use case | Revision tolerance | Volume shape | Structure need | Tier to start with |
|---|---|---|---|---|
| Pillar / comparison pages | Low | Few, high stakes | Medium | Premium (4.0x) |
| Technical tutorials with code | Very low | Few, high stakes | Medium | Standard (2.0x), reasoning model |
| Product descriptions | High | Many, low stakes | High | Budget (1.0x) |
| Meta descriptions, alt text | High | Many, low stakes | Very high | Budget (1.0x) |
| Localization of existing copy | Medium | Many | High | Standard (2.0x) |
| Editorial first drafts | High | Medium | Low | Standard (2.0x) |
Read the multipliers as relative cost, not absolute price. A Premium generation consumes four times the tokens of the same call on Budget, which is why running a 2,000-item catalog on the top tier gets expensive fast while a single pillar page on it costs almost nothing.
If you want the current head-to-head on the premium tier specifically, we broke it down in Claude Sonnet 5 vs Opus 5.
The part that actually determines whether this works
Model selection is maybe 20% of the outcome. The other 80% is the plumbing: where the generated content lands, whether it is reviewable before it goes live, and whether a human can fix it without a deploy.
Three requirements, in order of how often they get skipped:
1. Generated content must land as a draft. Any pipeline that writes straight to production is one bad generation away from an incident. Your CMS needs a draft state that the API can write to.
2. The schema must be enforced server-side. If your content model lets a 400-character string into a field meant for 155, the model's mistake becomes your search snippet. Validation belongs in the content model itself, where every write has to pass through it.
3. Editors need to fix output without touching code. This is the whole argument for a headless CMS in an AI pipeline. The model drafts, the API writes, and a human corrects it in a UI. Nobody should have to open a pull request to fix a typo.
For the full build, including grounding generations in a source document and streaming long outputs, see How to Build an AI Content Pipeline with Claude and a Headless CMS.
What this looks like in Cosmic
Generation and storage run through the same client, so the tier decision above is a parameter rather than an integration.
Generate
import { createBucketClient } from '@cosmicjs/sdk'
const cosmic = createBucketClient({
bucketSlug: process.env.COSMIC_BUCKET_SLUG!,
writeKey: process.env.COSMIC_WRITE_KEY!,
})
const { text, usage } = await cosmic.ai.generateText({
prompt: `Write an SEO description under 155 characters for: ${product.name}`,
max_tokens: 1024,
model: 'claude-opus-5',
})
The model parameter is the entire switch. Moving product descriptions from Standard down to Budget, or a pillar page up to Premium, is an edit to one string. There is no second provider account, no separate invoice, and no per-vendor SDK to keep current. We argued that case at length in Why Your AI Stack Should Be Model-Agnostic.
Omit model and the API uses claude-opus-5. Other IDs you can pass include gemini-3.1-pro-preview, gpt-5.2-codex, and kimi-k3. The full list lives in the AI API docs.
Note the second value in the response. usage comes back on every call, so you can log real token counts per piece instead of estimating them from a price-per-million table.
Write
Generated content goes in as a draft, against a typed object with server-side validation.
// `generated` is whatever your model returned, already parsed
await cosmic.objects.insertOne({
type: 'blog-posts',
title: generated.title,
slug: generated.slug,
status: 'draft', // always review before publishing
metadata: {
seo_description: generated.seoDescription, // maxlength enforced on the metafield
markdown_content: generated.body,
author: authorObjectId,
},
})
Two things to notice. status: 'draft' means an editor reviews every generation before it is public. And seo_description has a maxlength set on the metafield itself, so an over-long value is rejected at the API boundary instead of quietly shipping.
Reading it back for your frontend is the same SDK:
const { objects } = await cosmic.objects
.find({ type: 'blog-posts', status: 'published' })
.props('title,slug,metadata.seo_description,metadata.markdown_content')
.limit(20)
.sort('-created_at')
Cosmic exposes all of this over a REST API and the TypeScript SDK, so the pipeline is the same whether your model runs in a cron job, a serverless function, or an agent.
A cheap test before you commit
Before you standardize on a tier, run this. It takes an afternoon and it beats every benchmark chart.
- Take 10 real pieces of content you have already published.
- Write the prompt you would actually use in production, including your object schema.
- Generate 10 replacements with each candidate model, changing only the
modelstring between runs. - Count two numbers: how many validate against your schema on the first try, and how many minutes of editing each one needs to reach publishable.
- Add up the real cost. Log
usagefrom every call, then apply the tier multiplier: Budget 1.0x, Standard 2.0x, Premium 4.0x. That gives you measured token consumption per piece rather than an estimate. Multiply editing minutes by your loaded editorial rate and add the two figures together.
Pick the option with the cheapest total. That number predicts your real cost far better than a leaderboard position does.
The free plan includes 300,000 input and 300,000 output tokens per month, which is enough to run this entire comparison before you pay for anything.
Start building the pipeline
You can have both halves of this running against a real bucket today. Cosmic's free plan includes 1 Bucket, 2 team members, 1,000 objects, and the AI token allocation above, with no credit card required. Paid plans start at $49/month for Builder, and additional team members are $29/user/month. Full details on the pricing page.
Running a high-volume AI content pipeline and want to talk architecture? Book 20 minutes with Tony, our CEO. Cosmic is a YC W19 company and we have been doing API-first content since before it had a name.
Top comments (0)