DEV Community: Tony Spiro

How to Build an AI Content Pipeline with Claude and a Headless CMS

Tony Spiro — Sat, 01 Aug 2026 01:33:05 +0000

Most "AI content pipeline" tutorials hand you a second vendor. You install an AI provider's SDK, manage a second API key, absorb a second bill, and then write glue code to move the output into wherever your content actually lives.

Cosmic generates text, images, and video through the same API that stores your content. One SDK, one key, one bill. This guide builds a working pipeline on that API: a source document goes in, a reviewed draft comes out, and a human approves it before anything reaches production.

Everything below uses the official TypeScript SDK, @cosmicjs/sdk. No second AI provider required.

What we are building

A content pipeline has four stages, and the third one is the reason the other three are worth automating.

Source. The raw material: a brief, a transcript, a quarterly report, a spreadsheet of survey results.
Generate. Turn the source into a structured draft.
Review. A human reads it, edits it, and decides whether it ships.
Publish. The approved draft goes live through your existing front end.

Skip stage three and you are running a slop factory. The pipeline below treats the review gate as load-bearing infrastructure, not an afterthought.

Prerequisites

A Cosmic account. The Free plan includes 1 Bucket, 2 team members, 1,000 Objects, and a monthly AI token allocation, which is enough to build and test this end to end.
Your Bucket slug, read key, and write key, from Settings → API Access in your Bucket.
Node.js and a package manager.

A write key is required for every AI operation. Keep it server side only.

Step 1: Install the SDK and create a client

npm install @cosmicjs/sdk

import { createBucketClient } from '@cosmicjs/sdk'

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG,
  readKey: process.env.COSMIC_READ_KEY,
  writeKey: process.env.COSMIC_WRITE_KEY,
})

That is the entire dependency list. The same client reads content, writes content, and generates it.

Step 2: Generate your first draft

cosmic.ai.generateText() takes a prompt and returns the generated text plus token usage.

const response = await cosmic.ai.generateText({
  prompt: 'Write a 400-word product description for a ceramic pour-over coffee dripper. Audience: home brewers. Tone: plain and specific. No superlatives.',
  max_tokens: 1000,
})

console.log(response.text)
console.log(response.usage) // { input_tokens, output_tokens }

The usage object matters more than it looks. It is how you attach a real cost figure to every piece of content the pipeline produces, which we come back to below.

If you prefer HTTP directly, the same call over REST:

curl https://workers.cosmicjs.com/v3/buckets/${BUCKET_SLUG}/ai/text \
  -d '{"prompt":"Write a product description for a coffee mug","max_tokens":500}' \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer ${BUCKET_WRITE_KEY}"

Step 3: Feed it a real source document

This is the step that turns a prompt toy into a pipeline. The media_url parameter points at any file in your Bucket and the model analyzes it as part of the request. Images, PDFs, Excel spreadsheets, Word documents.

Upload a quarterly report to your Bucket, then generate from it:

const summary = await cosmic.ai.generateText({
  prompt:
    'Summarize the key points from this document as a bulleted list. Include only figures stated in the source. Do not extrapolate.',
  media_url: 'https://cdn.cosmicjs.com/quarterly-report.pdf',
  max_tokens: 1000,
})

The grounding this gives you is the whole point. A model working from a prompt alone invents plausible numbers. A model working from your PDF is constrained by a document you control, and the instruction to use only stated figures becomes checkable: a reviewer can open the same PDF and verify every claim.

The same parameter works with the chat format when you need multi-turn refinement over one source:

const analysis = await cosmic.ai.generateText({
  messages: [
    { role: 'user', content: 'What trends do you see in this sales data?' },
    { role: 'assistant', content: 'Looking at the spreadsheet, I can see several patterns...' },
    { role: 'user', content: 'What was the highest performing month?' },
  ],
  media_url: 'https://cdn.cosmicjs.com/sales-data.xlsx',
  max_tokens: 500,
})

Useful source documents for a content team: customer interview transcripts, support ticket exports, release notes, analytics CSVs, competitor pricing pages saved as PDFs.

Step 4: Write the result into the CMS as a draft

Generation and storage are the same client, so this is one call and no glue code.

const { object } = await cosmic.objects.insertOne({
  title: 'Q3 Performance Recap',
  type: 'blog-posts',
  status: 'draft', // never 'published' from an automated step
  metadata: {
    markdown_content: summary.text,
    teaser: 'Generated from the Q3 report. Pending editorial review.',
  },
})

console.log(object.id)

The status: 'draft' line is the pipeline's safety property. Every generated object lands in a state that is invisible to your production front end until a person changes it.

Step 5: Make the review gate real

A review gate that depends on someone remembering to check a folder will fail. Two things make it hold.

Query the queue. Anything awaiting review is one request away:

const { objects } = await cosmic.objects
  .find({ type: 'blog-posts', status: 'draft' })
  .props(['id', 'title', 'created_at'])

Wire that to a Slack message on a schedule and the queue comes to your team instead of waiting to be discovered.

Publishing stays a human action. The approval step is a deliberate status change, made by a person:

await cosmic.objects.updateOne(objectId, { status: 'published' })

Keep that call out of your generation script entirely. Put it behind an editor's click in the dashboard, or behind an internal tool that requires a named approver.

Step 6: Pick a model, and keep the ability to change it

The model parameter defaults to claude-opus-5. It also accepts Gemini models such as gemini-3.1-pro-preview, OpenAI models such as gpt-5.2-codex, and Moonshot Kimi models such as kimi-k3.

const draft = await cosmic.ai.generateText({
  prompt: brief,
  model: 'gemini-3.1-pro-preview',
  max_tokens: 2000,
})

Switching providers is a one-line change with no new dependency, no new key, and no new billing relationship. That matters because the model you pick today will be superseded. A pipeline that pins itself to a single vendor's SDK has to be rebuilt every time the frontier moves. See why your AI stack should be model-agnostic for the longer argument.

A practical split for a content pipeline: a cheaper Budget-tier model for mechanical work like extracting bullet points or drafting meta descriptions, and a Standard-tier model for prose that a reader will actually see.

Step 7: Generate the featured image in the same pipeline

The AI API also generates images and video, so the featured image does not have to be a manual handoff to a designer or a trip to a stock library. Image generation is billed as a fixed token cost per image: a DALL-E 3 image is 4,800 output tokens, a Gemini 1K or 2K image is 32,160, and a Gemini 4K image is 57,600. Videos through Veo cost considerably more, from 144,000 tokens for a 4-second fast render.

See the AI API reference for the image and video request formats. Generated media lands in your Bucket's media library, so you can attach it to the draft object in the same run that created the draft.

Step 8: Stream when a human is watching

Batch jobs do not need streaming. Editor-facing tools do, because a blank screen for twenty seconds reads as a broken feature.

import { TextStreamingResponse } from '@cosmicjs/sdk'

const result = await cosmic.ai.generateText({
  prompt: 'Draft an intro paragraph for this post',
  max_tokens: 500,
  stream: true,
})

const stream = result as TextStreamingResponse

let fullResponse = ''
stream.on('text', (text) => {
  fullResponse += text
})
stream.on('usage', (usage) => console.log('Usage:', usage))
stream.on('end', () => console.log('Complete:', fullResponse))
stream.on('error', (error) => console.error('Error:', error))

Step 9: Give the pipeline memory

Generation is half of a useful pipeline. Retrieval is the other half. Before drafting a new post, check whether you already published one on the same topic, and feed the existing coverage into the prompt as context.

Cosmic includes semantic search over your Bucket content, which finds objects by meaning rather than keyword match. That is how you stop a pipeline from producing four posts that compete with each other for the same search query. See the semantic search docs for the query format.

The no-code path: connect Claude directly to your CMS

If you want an AI assistant operating on your content interactively instead of a scripted job, use the Cosmic MCP server. It exposes your Bucket as tools that Claude Code, Claude Desktop, or Cursor can call directly: read objects, create drafts, upload media, generate content.

The read-key-only configuration is worth knowing about here. Point the MCP server at a read key and every create, update, and delete tool is blocked, which gives you an assistant that can analyze your content library and propose changes without the ability to write anything. Full setup is in connect Claude Code to your CMS with MCP and the MCP server docs.

Guardrails that actually matter

Six rules, learned the practical way.

Never publish from an automated step. Generation writes drafts. Only a person changes status to published.
Ground every factual claim in a source document. Use media_url and instruct the model to use only stated figures. Claims a reviewer cannot trace to a source get cut, not softened.
Cap max_tokens per job. It is your circuit breaker against a runaway loop consuming a month of allocation.
Log usage on every call. Store input and output tokens alongside the object so you can attribute cost per piece.
Keep write keys server side. Every AI operation needs one. A write key in client code is a public write key.
Deduplicate before you generate. Run a semantic search first. Two posts targeting one query split their own rankings.

What this costs

AI usage draws tokens from your plan allocation, and text generation applies a tier multiplier to the actual tokens used.

Budget, 1.0x: GPT-5 Nano, GPT-5 Mini, Claude Haiku 4.5. 1,000 actual tokens deducts 1,000.
Standard, 2.0x: 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. 1,000 actual tokens deducts 2,000.
Premium, 4.0x: Claude Fable 5. 1,000 actual tokens deducts 4,000.

Media is a fixed cost per asset, billed as output tokens, with the image and video figures listed in Step 7.

Plan pricing, current at time of writing: Free at $0/month, Builder at $49/month, Team at $299/month, Business at $499/month, and Enterprise on custom pricing. Additional team members are $29/user/month. Token packs are available if you exceed your monthly allocation. Check the pricing page for current allocations and pack sizes.

Measuring whether the pipeline is working

Volume is the wrong metric. A pipeline that triples output and halves engagement has made things worse. Track these instead:

Approval rate. What share of generated drafts a human ships without a rewrite. A low rate points at your prompts and source documents, not the model.
Editing distance. How much reviewers change before publishing. Rising distance means quality is drifting.
Cost per published piece. Logged usage divided by pieces that actually shipped, counting the drafts you threw away.
Engagement on generated pieces versus hand-written ones. The honest test.

FAQ

Do I need my own Anthropic or OpenAI API key?

No. Text, image, and video generation run through the Cosmic API using your Bucket write key. Model access is included in your plan allocation.

Which models are available?

Claude, Gemini, OpenAI, and Moonshot Kimi models, selected with the model parameter. The default is claude-opus-5. The full list is in the AI API docs.

Can the AI read my existing files?

Yes. Pass media_url pointing at any file in your Bucket: images, PDFs, Excel spreadsheets, Word documents, and more.

Does Cosmic have a GraphQL API?

No. Cosmic provides a REST API and the JavaScript/TypeScript SDK, @cosmicjs/sdk.

Can I run this without writing code?

Yes, through the MCP server or the AI features in the dashboard. The code path gives you scheduling and repeatability.

Will generated content hurt my SEO?

Unreviewed content will. The review gate in Step 5 exists for that reason. Publish what a human has verified and cut what nobody can source.

Ship the boring version first

The smallest useful pipeline is one source document, one prompt, one draft object, one reviewer. Build that, run it for a week, then add scheduling and images and retrieval once you trust the output.

This is the outcome teams are after when they automate content operations. As Maximilian Wuhr, Co-Founder at FINN, put it: "Cosmic is: us never having to ask a developer to change anything on the backend of our website."

Start building for free with AI generation included on every plan, or book 20 minutes with our CEO to talk through your content workflow. If you want the interactive version instead, wire up Cosmic AI agents or the MCP server and start from a conversation.

DeepSeek V4 Flash: Benchmarks, Pricing, and What It Means for Content Agents

Tony Spiro — Fri, 31 Jul 2026 22:08:25 +0000

Originally published on the Cosmic blog.

DeepSeek released V4-Flash on July 31, 2026, and pushed it to public beta on the API under the model name deepseek-v4-flash. It landed on the front page of Hacker News twice within hours.

The headline is easy to summarize: near the top of the intelligence rankings, at the bottom of the price rankings. The details are more interesting than the headline, and one of them changes the cost math in a way the per-token price does not show.

Here is what shipped, what the numbers say, and where a model like this fits in a content pipeline.

What actually shipped

According to DeepSeek's official changelog, V4-Flash uses the same architecture and the same parameter size as the earlier V4-Flash-Preview. The only change is post-training. DeepSeek re-post-trained the model and reports scores that represent a significant jump over the V4-Pro-Preview.

A few practical notes from the release:

The model is in public beta on the API.
It natively supports the Responses API format and has been adapted for Codex.
The V4-Pro API, app, and web experiences are unchanged. An official V4-Pro release is still to come.
Independent measurement puts it at 284B parameters, with weights not publicly released.
It is text in, text out. No image, audio, or video input.

That last point matters if you were hoping to drop it into a workflow that processes screenshots or PDFs. You cannot, at least not directly.

The benchmark numbers

DeepSeek published the following scores, evaluated with its own DeepSeek Harness in minimal mode at max effort, top_p 0.95, temperature 1.0:

Benchmark	Score
Terminal Bench 2.1	82.7
Cybergym	76.7
Toolathlon (verified)	70.3
DSBench-FullStack	68.7
DSBench-Hard	59.6
DeepSWE	54.4
NL2Repo	54.2
Agent Last Exam	25.2
Automation Bench (Public)	25.1

Read the shape of that table rather than any single row. The strongest results cluster around terminal use, tool calling, and multi-step engineering work: Terminal Bench at 82.7 and Toolathlon at 70.3 are agentic evaluations, not trivia recall. This is a model tuned to operate software.

The bottom two rows deserve an honest caveat. Agent Last Exam and Automation Bench are deliberately brutal, long-horizon evaluations where scores in the twenties are normal across the frontier right now. A 25.2 is not a failure. It is a reminder that fully autonomous, hours-long task completion remains unsolved by everyone.

One more caveat worth stating plainly: these are vendor-published numbers, produced with the vendor's own harness at max effort settings. Treat them as a strong signal and verify on your own evals before you migrate anything that matters.

Independent measurement from Artificial Analysis puts V4-Flash at an Intelligence Index of 50, ranking it 2nd out of 162 models in its class, against a class median of 17.

The price story, and the part people will miss

On raw API pricing, V4-Flash ranks 1st out of 162 in its class:

$0.14 per 1M input tokens
$0.28 per 1M output tokens
$0.003 per 1M cached input tokens, a 98% discount on a cache hit
$0.06 per 1M tokens blended
1M token context window

That cache-hit price is the number to pay attention to, and it is the one that gets skimmed past. For any agent that runs repeatedly against the same system prompt, the same schema definitions, and the same style guide, the fixed prefix of every request is identical. Caching turns that prefix from a recurring cost into a rounding error.

Now the catch.

Artificial Analysis also measured verbosity, and V4-Flash consumed 210M output tokens to complete the Intelligence Index, against a median of 62M. That ranks it 58th of 162 on output efficiency. It produced roughly three and a half times the median number of tokens to reach its score.

Cheap tokens and cheap tasks are two different measurements. A model at a third of the per-token price that emits three times the tokens has spent your savings. The total cost to evaluate V4-Flash on the Intelligence Index came to $72.02, which is genuinely low, so the economics still work out well here. The lesson is that you should benchmark cost per completed task on your own workload rather than reading the price-per-million column and stopping there.

If your workload is latency-sensitive, the verbosity number is also a throughput warning. More tokens means more time to last token.

Where this fits in a content pipeline

Strong tool-calling scores, a 1M token context window, and a 98% cache discount describe a specific kind of useful: long-running agents that read and write structured content.

That is a real workload. Translating a content library into six locales. Auditing every post for a deprecated product claim. Regenerating meta descriptions across a thousand objects. Keeping a changelog in sync with release notes. These jobs are repetitive, schema-bound, and expensive at frontier prices, which is exactly the profile where a cheap, cache-friendly, tool-capable model earns its place.

The 1M context window matters here for a specific reason. Content operations tend to need broad but shallow context: a large number of records, each fairly small. You can put an entire content model and hundreds of objects in a single request and let the model reason across all of it, instead of building a retrieval layer to work around a smaller window.

With Cosmic, the read side of that loop is a few lines. Pull the objects and the fields you need:

import { createBucketClient } from '@cosmicjs/sdk';

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG!,
  readKey: process.env.COSMIC_READ_KEY!,
});

const { objects: posts } = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props('id,slug,title,metadata.seo_description')
  .limit(200);

Because .props() limits the payload to the fields you actually asked for, you control your own token bill at the source. Sending 200 slugs and meta descriptions costs a fraction of sending 200 full post bodies.

Then hand the batch to the model. The API is OpenAI-compatible, so the client you already have works:

const response = await fetch('https://api.deepseek.com/chat/completions', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${process.env.DEEPSEEK_API_KEY}`,
  },
  body: JSON.stringify({
    model: 'deepseek-v4-flash',
    messages: [
      { role: 'system', content: STYLE_GUIDE },
      { role: 'user', content: JSON.stringify(posts) },
    ],
  }),
});

Keep STYLE_GUIDE byte-identical across runs so it stays cacheable. Put the variable content in the user message. That one discipline is where the 98% cache discount actually shows up on your invoice.

Writing results back through the SDK closes the loop, and because every change lands as a versioned object rather than a direct database write, you keep an audit trail of what the agent changed.

Should you switch?

A reasonable read as of today:

Good fit for V4-Flash

High-volume, repetitive content operations where per-task cost dominates
Agentic and terminal-oriented work, which is where the benchmarks are strongest
Workloads with a large stable prompt prefix that will hit the cache
Jobs that need broad context across many records

Look elsewhere

Anything requiring image, audio, or video input, since the model is text-only
Latency-critical, user-facing interactions, given the verbosity numbers
Production systems with no tolerance for a public beta API
Deployments that require open weights, which are not available here

The honest summary: this is a strong, cheap, tool-capable text model that is well suited to background content work and not yet the right choice for multimodal or latency-sensitive paths. Run it against your own evals before you commit.

Build the pipeline the model plugs into

Model leaderboards will keep churning. The thing that determines whether you can take advantage of a release like this one is whether your content layer is API-first, so swapping the model behind it is a config change rather than a migration.

That is what Cosmic is for. Your content lives in a headless CMS with a REST API and a TypeScript SDK, so any model, agent, or framework can read and write it. When a cheaper or smarter model ships next month, you point at it and move on.

Start building free and connect a bucket in minutes
Read the AI features overview to see what is built in
Comparing coding agents too? See our Claude Code vs GitHub Copilot vs Cursor breakdown
Running this at team scale? Book 15 minutes with our CEO

Benchmark scores in this post are from DeepSeek's official changelog dated July 31, 2026. Pricing, Intelligence Index, parameter count, and verbosity figures are from Artificial Analysis. Vendor-published benchmarks were produced with DeepSeek's own harness at max effort settings, so verify against your own workload.

Claude Sonnet 5 vs Opus 5: A Real-World Comparison (2026)

Tony Spiro — Fri, 31 Jul 2026 22:07:25 +0000

Originally published on the Cosmic blog.

Anthropic shipped Claude Sonnet 5 on June 30, 2026 and Claude Opus 5 on July 24, 2026. Both are excellent. The expensive mistake is picking one, wiring it into every code path, and then either overpaying on trivial work or under-resourcing the work that actually matters.

This is the practical breakdown: what each model is measurably good at, what the same job costs on each once you account for tokenization, and a routing rule you can ship this week.

The short answer

Your workload	Use	Why
Content generation, summarization, chat, classification, tagging	Sonnet 5	Highest quality per dollar. This is the volume tier.
Day-to-day coding, refactors, test writing, PR review	Sonnet 5	72.7% on SWE-bench Verified, a 10.4 point jump over Sonnet 4.6.
Long autonomous agent runs with tool calls	Opus 5	Anthropic reports it ranked first on Zapier's AutomationBench for end-to-end task completion.
Architecture decisions, ambiguous multi-step problems, novel reasoning	Opus 5	Self-verification and judgment are the headline improvements.
Anything where a wrong answer is expensive to unwind	Opus 5	Lowest misaligned-behavior score of Anthropic's recent releases at 2.3.
High-volume production traffic on a budget	Sonnet 5	It is the default on Claude Free and Pro for a reason.

If you want one sentence to take away: run Sonnet 5 by default and escalate to Opus 5 on the specific paths where judgment matters more than throughput.

What the benchmarks actually say

There is a wrinkle worth knowing before you compare scores. Anthropic evaluated these two models on different suites, so there is no clean head-to-head table, and anyone who publishes one has filled in gaps with guesses.

Here is what was actually published for Sonnet 5:

Benchmark	Sonnet 5	Sonnet 4.6	Opus 4.8
SWE-bench Verified	72.7%	62.3%	79.4%
Terminal-bench	76.1%	55.4%	not published
GPQA Diamond	78.0%	not published	not published
MMMU	76.3%	not published	not published
MathVista	76.6%	not published	not published
CharacterEval	90.3%	not published	not published

And here is what was published for Opus 5:

State of the art on coding and knowledge work, measured on Frontier-Bench and GDPval-AA.
First place on Zapier's AutomationBench for end-to-end task completion.
An ARC-AGI 3 score roughly three times the next-best model.
A misaligned-behavior score of 2.3, the lowest of Anthropic's recent releases.
Matches Claude Fable 5 on intelligence at approximately half the cost.
A fast mode that runs about 2.5x quicker.

Notice what is missing: Anthropic did not publish a SWE-bench Verified number for Opus 5. So the honest comparison on classic coding benchmarks is Sonnet 5 at 72.7% against Opus 4.8 at 79.4%, with Opus 5 positioned above Opus 4.8 on the newer agentic and knowledge-work suites. Treat any "Opus 5 scores X% on SWE-bench" claim you find elsewhere as unsourced.

The practical read: Sonnet 5 closed most of the gap to the previous Opus generation on straightforward coding. Opus 5's advantage shows up in long-horizon agent work, self-verification, and problems where the model has to decide what the task even is.

What it actually costs

List prices per million tokens:

Model	Input	Output	Notes
Sonnet 5	$2	$10	Introductory pricing through August 31, 2026
Sonnet 5	$3	$15	Standard pricing from September 1, 2026
Opus 5	$5	$25	Same as Opus 4.8

Headline math says Opus 5 costs 1.67x Sonnet 5 at standard pricing, and 2.5x during the introductory window. That understates Sonnet 5's real cost, because Sonnet 5 ships a new tokenizer that counts the same text as 1.0x to 1.35x more tokens. You pay per token, not per word, so that inflation lands on your invoice.

Work a concrete example. Take a job that a baseline tokenizer counts as 1,000,000 input tokens and 200,000 output tokens:

Scenario	Input cost	Output cost	Total	Opus 5 premium
Opus 5	$5.00	$5.00	$10.00	baseline
Sonnet 5 standard, no inflation	$3.00	$3.00	$6.00	1.67x
Sonnet 5 standard, 1.35x inflation	$4.05	$4.05	$8.10	1.23x
Sonnet 5 intro, no inflation	$2.00	$2.00	$4.00	2.50x
Sonnet 5 intro, 1.35x inflation	$2.70	$2.70	$5.40	1.85x

That 1.23x row is the one that should change your thinking. On text-heavy workloads that tokenize badly, at standard pricing, Opus 5 costs about 23% more than Sonnet 5 rather than 67% more. If judgment quality matters on that path at all, a 23% premium is easy to justify.

Two caveats so you use this honestly. The inflation range is 1.0x to 1.35x depending on your content, and where you land is an empirical question about your own data. And the September 1 price change means any cost model you build this month needs revisiting. Run 1,000 real requests through both models, compare your actual billed token counts, and decide from your numbers instead of this table.

A routing rule you can ship

Most teams do not need a clever classifier. A static route based on task type captures nearly all of the savings:

Default to Sonnet 5. Content, chat, summaries, tagging, ordinary code changes.
Escalate to Opus 5 on three triggers: the task requires more than roughly ten tool calls, the task is architectural or ambiguous, or a wrong answer is expensive to reverse.
Escalate on retry. If Sonnet 5's output fails validation twice, retry once on Opus 5 instead of a third time on Sonnet 5. This is the highest-return rule on the list and it takes about six lines of code.
Never hardcode the model name. Anthropic shipped two frontier models in 25 days. Whatever you pin today will be stale within a quarter.

Point four is where most of the long-term pain lives. If your model identifiers are compiled into your application, every model release becomes a pull request, a review, and a deploy.

Keep model config out of your codebase

Store your routing configuration as content instead. Then swapping Sonnet 5 for Sonnet 5.1 is a field edit that takes effect immediately, with no rebuild.

Install the SDK:

npm install @cosmicjs/sdk

Define the routing table as an object in Cosmic and read it at runtime:

import { createBucketClient } from '@cosmicjs/sdk';

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG!,
  readKey: process.env.COSMIC_READ_KEY!,
});

type ModelRoute = {
  default_model: string;
  escalation_model: string;
  escalate_after_failures: number;
};

export async function getModelRoute(): Promise<ModelRoute> {
  const { object } = await cosmic.objects
    .findOne({ type: 'model-config', slug: 'production' })
    .props('metadata')
    .depth(0);

  return object.metadata as ModelRoute;
}

Use it at the call site:

const route = await getModelRoute();

let model = route.default_model;        // "claude-sonnet-5"
if (isArchitectural(task) || failures >= route.escalate_after_failures) {
  model = route.escalation_model;       // "claude-opus-5"
}

const result = await runTask({ model, task });

When the next model lands, a non-engineer updates one field in the dashboard and production picks it up. No deploy, no pull request, no engineer in the loop. Cosmic exposes this over a REST API and the TypeScript SDK, so the same config is readable from any framework or runtime you use.

For the previous generation's version of this decision, see Sonnet 4.5 vs Opus 4.5.

Frequently asked questions

Is Opus 5 better than Sonnet 5?
On ambiguous reasoning, long autonomous agent runs, and self-verification, yes. On cost per acceptable output for high-volume tasks, Sonnet 5 wins clearly. They are built for different jobs.

What does Claude Sonnet 5 cost?
$2 per million input tokens and $10 per million output tokens through August 31, 2026, moving to $3 and $15 on September 1, 2026.

What does Claude Opus 5 cost?
$5 per million input tokens and $25 per million output tokens, unchanged from Opus 4.8.

Did Anthropic publish a SWE-bench Verified score for Opus 5?
No. Sonnet 5 scored 72.7% and Opus 4.8 scored 79.4%. Opus 5's published results cover Frontier-Bench, GDPval-AA, Zapier AutomationBench, and ARC-AGI 3.

Which Claude model should I use for coding?
Sonnet 5 for the majority of day-to-day work. Escalate to Opus 5 for architecture, cross-cutting refactors, and anything where you cannot cheaply verify the result.

Why do my Sonnet 5 token counts look higher than expected?
Sonnet 5 uses a new tokenizer that counts the same text as 1.0x to 1.35x more tokens than the previous generation. Compare billed tokens, not word counts.

Build on infrastructure that outlives the model

Anthropic shipped two frontier models in under a month. The teams handling that well are the ones that never put a model name in a source file.

Cosmic is an AI-powered headless CMS where your content and your configuration both live behind a REST API and a TypeScript SDK. Model choice becomes a content decision, editable by anyone on your team, live in production the moment it is saved.

Start free on the Free plan with 1 Bucket, 2 team members, and 1,000 Objects. No credit card required. If you want to talk through a specific architecture, book 20 minutes with our CEO.

Bun vs Node vs Deno in 2026: How to Choose a JavaScript Runtime

Tony Spiro — Fri, 31 Jul 2026 22:05:36 +0000

Three JavaScript runtimes are now viable for production work: Node.js, Deno, and Bun. That is a genuinely good problem to have, and it makes the choice harder than it was when Node was the only answer.

Most runtime comparisons you will find lead with benchmark charts. We are going to skip those, and the reason is worth stating plainly: published runtime benchmarks are almost always produced by the runtime's own team, measured on a workload chosen to flatter it. Your API is not that workload. The numbers that matter are the ones you measure on your own code, and we show you how to get them at the end of this post.

What this guide covers instead is the set of differences that are stable, documented, and actually decide the outcome: ecosystem depth, how each runtime handles TypeScript, what ships in the box, the security model, and where you can deploy.

The short version

	Node.js	Deno	Bun
Best for	Anything where ecosystem risk matters	Security-sensitive and web-standard code	Fast local dev and all-in-one tooling
TypeScript	Needs a build step or a loader	Runs `.ts` directly	Runs `.ts` directly
Package manager	npm, pnpm, yarn	npm specifiers plus JSR	Built in (`bun install`)
Test runner	Built in	Built in	Built in
Bundler	External	Built in	Built in
Permissions	Opt-in, still maturing	Deny by default	Opt-in
Hosting support	Everywhere	Good and growing	Good and growing

If you want the one-line answer: pick Node when the cost of an ecosystem surprise is high, pick Deno when you want strict sandboxing and web-standard APIs, pick Bun when developer iteration speed and a single toolchain matter most.

Most people arrive here weighing a pair rather than all three, so it helps to name the tradeoff in each one. If your question is bun vs node, you are trading ecosystem certainty for a faster toolchain and fewer config files. If it is deno vs node, the deciding factor is the permission model rather than performance, because Deno refuses ambient filesystem and network access that Node grants freely. And if it is bun vs deno, both already run TypeScript directly and ship their own test runner and bundler, so the real choice is the fastest toolchain against the strictest sandbox. The three sections below take those pairings in order.

Node.js vs Bun and Deno: the incumbent case

Node is the incumbent, and incumbency is a real technical feature. Every hosting provider supports it, every observability vendor has an agent for it, every obscure npm package was tested against it, and every Stack Overflow answer assumes it. When something breaks at 2am, Node is the runtime most likely to have a documented answer already written.

Node has also closed much of the gap that made the alternatives attractive in the first place. It ships a built-in test runner, native ESM support alongside CommonJS, a built-in watch mode, and a permission model that continues to develop release over release. A lot of the "you need Deno for that" arguments from a few years ago no longer hold.

Where Node costs you: TypeScript still wants a build step or a loader in most setups, and the toolchain is assembled rather than provided. A typical project pulls in a package manager, a bundler, a transpiler, a test runner, and a linter, each with its own config file and its own upgrade cadence. That assembly is flexible, and it is also the single biggest source of setup friction in the JavaScript ecosystem.

Choose Node if: you are shipping something you will maintain for years, you have compliance or vendor requirements, or you depend on native modules that only ever get tested against Node.

Deno vs Node: the security model

Deno's defining decision is that code gets no ambient permissions. A Deno process cannot read the filesystem, open a network connection, or read environment variables unless you granted that specific capability at launch. Every other runtime here works the opposite way: any dependency you install can do anything your process can do.

That matters more every year. Supply chain attacks against package registries are now routine, and "this transitive dependency exfiltrated our environment variables" is a real class of incident. Deno makes it structurally harder, and no amount of care in Node or Bun gives you the same guarantee.

Beyond the sandbox, Deno leans hard on web standards. fetch, Request, Response, URL, and Web Streams are the native vocabulary, so code you write for a Deno server often moves to a browser, a service worker, or an edge function with little change. It runs TypeScript directly, ships a formatter, linter, test runner, and bundler, and supports npm packages through npm: specifiers alongside its own JSR registry.

Where Deno costs you: npm compatibility is good but not total, and the packages most likely to give you trouble are the ones doing something unusual with native bindings or filesystem layout. You will occasionally spend an afternoon on a dependency that would have just worked on Node.

Choose Deno if: you are handling sensitive data, you want dependency risk contained by default, or you are writing code that needs to run at the edge and on a server without a rewrite.

Bun vs Node: the toolchain

Bun's pitch is consolidation. One binary is your runtime, package manager, bundler, test runner, and script runner. There is no separate transpiler to configure, no bundler config, and TypeScript and JSX run directly. For a greenfield project, the difference between bun init and assembling an equivalent Node toolchain is substantial, and it stays substantial every time you onboard a new engineer.

Bun also ships batteries that other runtimes leave to packages: an HTTP server API, a SQLite driver, a shell API for cross-platform scripting, and a password hashing implementation. Fewer dependencies means less to audit and less to upgrade.

Compatibility was Bun's weakest point early on and is now its strongest argument. It implements Node's APIs deliberately so that existing projects and existing npm packages run unmodified, which makes it realistic to adopt Bun in a codebase you did not start from scratch.

Where Bun costs you: it is the youngest of the three. The edges you hit will be less documented, and the engineer who hits one is more likely to be the first person to hit it. Some teams also use Bun only as a package manager and test runner while continuing to run Node in production, which is a legitimate and low-risk way to get most of the benefit.

Choose Bun if: you are starting something new, your team is small enough that toolchain friction is a real tax, or your test suite and install times are actively slowing you down.

Your content layer should not care

One thing worth checking before you commit: whether the services your app depends on will follow you across runtimes.

An API-first content layer is portable by construction. The official Cosmic TypeScript SDK is standard JavaScript over a REST API with no native bindings, so the same code runs unchanged on all three runtimes, and in edge functions and React Server Components as well.

import { createBucketClient } from '@cosmicjs/sdk';

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG!,
  readKey: process.env.COSMIC_READ_KEY!,
});

const { objects: posts } = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props(['id', 'title', 'slug', 'metadata'])
  .depth(1);

console.log(posts);

Install it with npm install @cosmicjs/sdk, bun add @cosmicjs/sdk, or a npm:@cosmicjs/sdk specifier on Deno. The application code is identical in all three cases. Runtime choice stays a runtime decision and never becomes a content migration.

How to actually decide

Skip the benchmark blog posts, including the ones that favor us. Run this instead.

1. Test your real dependency tree first. Take your existing package.json, install it on each candidate runtime, and run your test suite. This single step eliminates more options than any performance measurement will, and it takes an afternoon. A runtime that cannot install your dependencies is not a candidate no matter how fast it is.

2. Measure your workload, not a synthetic one. Put each runtime behind the same load generator, serving your actual routes against your actual database, and compare p95 and p99 latency under a concurrency level you expect in production. Average throughput on a hello-world handler predicts nothing about your app. If the difference you measure is within noise, and for many CRUD APIs it will be, then performance is not your deciding factor and you should choose on tooling and risk instead.

3. Confirm your deployment target. Check that your hosting platform, your CI runner, your APM vendor, and your container base image all support the runtime you want. Node passes this trivially. The other two usually pass, and "usually" is worth verifying before you write code rather than after.

4. Price the migration honestly. Moving an existing production service between runtimes is a real project with a real regression risk. The upside has to be large enough to justify it. New services are where switching costs are near zero, so that is where experimenting belongs.

5. Consider splitting the decision. Using Bun for local development, installs, and tests while deploying on Node is a common and sensible arrangement. You get the fast toolchain where it saves you time daily, and the boring runtime where reliability matters most.

The honest conclusion

For most teams shipping a web application in 2026, all three runtimes will work. That is the actual state of the ecosystem, and any post that tells you one of them is obviously correct for everyone is selling something.

Node remains the lowest-risk default and has quietly absorbed most of the features that once made it feel dated. Deno is the right call when dependency risk is a genuine threat model rather than a hypothetical. Bun is the most pleasant to develop against and the easiest to start with, and its compatibility work has made it a reasonable production choice rather than an experiment.

Pick based on your team's risk tolerance and where your friction actually is. Then make sure the rest of your stack, your content layer included, does not lock the decision in.

FAQ

Is Bun production ready in 2026?

Yes, for most workloads. Bun implements Node's APIs deliberately so existing npm packages and projects run unmodified, and teams are running it in production. The remaining risk is maturity rather than capability: fewer engineers have hit any given edge case before you. Teams that want the tooling benefit with minimal risk often use Bun for installs, tests, and local development while deploying on Node.

Can I run npm packages on Deno?

Yes, through npm: specifiers, and compatibility covers the large majority of the registry. Packages that rely on native bindings or unusual filesystem assumptions are the ones most likely to need work. Test your actual dependency tree before committing.

Which JavaScript runtime is fastest?

It depends entirely on the workload, and any single answer to this question is marketing. Bun and Deno both publish favorable benchmarks against Node, and those benchmarks measure workloads their teams selected. For a typical API that spends most of its time waiting on a database or an upstream service, runtime differences are frequently within measurement noise. Benchmark your own routes under realistic concurrency and compare p95 latency before you let performance drive the decision.

Should I migrate an existing Node app to Bun or Deno?

Usually not on its own merits. Migrating a production service carries real regression risk, and the payoff has to be large to justify it. Adopt a new runtime on a new service where switching costs are near zero, learn its failure modes there, and revisit migration once you have operational experience.

Do I still need TypeScript build tooling?

On Deno and Bun, no: both execute .ts files directly. On Node you still want a build step or a loader for most setups. Note that running TypeScript directly is not the same as type checking it, and Deno and Bun both skip type checking at runtime by design, so keep tsc --noEmit in CI regardless of runtime.

Does a headless CMS work the same across all three runtimes?

If it is API-first, yes. The Cosmic TypeScript SDK is standard JavaScript over a REST API with no native dependencies, so identical application code runs on Node, Deno, and Bun, plus edge runtimes and React Server Components.

Originally published on the Cosmic blog. Cosmic is an AI-powered headless CMS with a REST API, TypeScript SDK, and AI Agents that live in Slack, WhatsApp, and Telegram. Try it free, no credit card required.

How to Connect Claude Code to Your CMS with MCP

Tony Spiro — Thu, 30 Jul 2026 22:08:46 +0000

Claude Code is fluent in your repository and blind to your content. It can refactor the component that renders your blog, but ask it to publish the post that component displays and it has nowhere to look. The Model Context Protocol (MCP) closes that gap. It gives Claude Code a set of tools it can call against your CMS directly, so reading and writing content happens in the same conversation as the code.

This guide connects Claude Code to a Cosmic bucket. With the hosted endpoint it takes about five minutes and requires no install.

What MCP actually gives Claude Code

MCP is an open protocol for exposing tools to AI assistants. The Cosmic MCP server implements it and exposes 18 tools across four areas:

Objects (5 tools): list, get, create, update, and delete content
Media (4 tools): list, get, upload, and delete files
Object Types (5 tools): list, get, create, update, and delete content models
AI Generation (4 tools): generate text, images, video, and audio into your bucket

Once connected, "publish the MCP draft and generate a hero image for it" resolves to real tool calls against your bucket. No browser tab, no copy-paste, no manual export.

There are two ways to connect:

Hosted MCP (recommended): point your client at https://mcp.cosmicjs.com/v1/buckets/{your-bucket-slug} and authenticate with your bucket keys. Nothing to install.
Self-hosted (stdio): run the @cosmicjs/mcp npm package locally via npx. Useful for offline work, or when you want the MCP process running inside your own dev environment.

Before you start

You need three things:

A Cosmic bucket. The Free plan is $0/month and includes 1 Bucket, 2 team members, and 1,000 Objects, which is more than enough to follow along. Start for free.
Your bucket slug, read key, and write key. Step 1 below covers where to find them.
Claude Code installed.

The hosted path needs no local runtime at all. Node is only required if you choose the self-hosted stdio option, since that runs through npx.

Step 1: Get your bucket credentials

Log in to the Cosmic dashboard
Navigate to your bucket
Go to Settings -> API Access
Copy your bucket slug, read key, and write key

A recommendation before you paste anything: start with the read key only. Cosmic issues separate read and write keys per bucket, so you can give Claude Code full visibility into your content while making it structurally incapable of changing it. Add the write key once you trust the setup. The read-only vs full access section below covers exactly what changes.

Step 2: Connect with hosted MCP (recommended)

Claude Code picks up project-scoped MCP servers from a .mcp.json file at the root of your repository. Create it with:

{
  "mcpServers": {
    "cosmic": {
      "url": "https://mcp.cosmicjs.com/v1/buckets/your-bucket-slug",
      "headers": {
        "Authorization": "Bearer your-read-key:your-write-key"
      }
    }
  }
}

Replace your-bucket-slug, your-read-key, and your-write-key with the values from Step 1. The endpoint supports the streamable-HTTP MCP transport.

How the authorization header works

Cosmic packs both keys into a single bearer token, separated by a colon. The write key is the part after the colon:

# Read-only access
Authorization: Bearer rk_abc123def456

# Full access (read + write)
Authorization: Bearer rk_abc123def456:wk_zyx987wvu654

Omit the colon and the write key for read-only access. If your client cannot send a colon-packed token, you can pass the write key out-of-band using the X-Cosmic-Write-Key header instead.

One housekeeping note: .mcp.json now contains live credentials, so add it to .gitignore before your next commit.

The same mcpServers block works for Claude Desktop and Cursor. The MCP server docs list the exact config file paths for each client, including ~/Library/Application Support/Claude/claude_desktop_config.json on macOS and .cursor/mcp.json for Cursor.

Step 2, alternative: self-hosted over stdio

If you would rather run the server yourself, the @cosmicjs/mcp package ships a stdio binary. Point Claude Code at npx:

{
  "mcpServers": {
    "cosmic": {
      "command": "npx",
      "args": ["@cosmicjs/mcp"],
      "env": {
        "COSMIC_BUCKET_SLUG": "your-bucket-slug",
        "COSMIC_READ_KEY": "your-read-key",
        "COSMIC_WRITE_KEY": "your-write-key"
      }
    }
  }
}

The stdio binary reads credentials from environment variables:

COSMIC_BUCKET_SLUG (required): your Cosmic bucket slug
COSMIC_READ_KEY (required): bucket read key for read operations
COSMIC_WRITE_KEY (optional): bucket write key for write operations

Leave COSMIC_WRITE_KEY out entirely for a read-only server. You can also install it globally with npm install -g @cosmicjs/mcp instead of resolving it through npx each time.

Step 3: Verify the connection

Restart Claude Code and run:

/mcp

You should see cosmic listed with its tools. Then confirm it can actually reach your bucket by asking for something only your bucket knows:

List all object types in my Cosmic bucket

Claude Code should call cosmic_types_list and return your real content models. If it returns your object types, the connection is live and correctly authenticated.

The 18 tools, and when each one fires

Objects

cosmic_objects_list: list or search objects, filtered by type, status, and locale, with pagination
cosmic_objects_get: fetch a single object by ID or slug, with optional metafield, depth, and locale params
cosmic_objects_create: create a new object with title, slug, status, and metafields (write key required)
cosmic_objects_update: update an existing object's title, slug, status, or metafield values (write key required)
cosmic_objects_delete: permanently delete an object by ID (write key required)

Media

cosmic_media_list: list media files, optionally scoped to a folder
cosmic_media_get: fetch metadata and the imgix URL for a single file
cosmic_media_upload: upload from a URL or base64 payload into the media library (write key required)
cosmic_media_delete: delete a media file (write key required)

Object Types

cosmic_types_list: list every object type in the bucket
cosmic_types_get: fetch the full schema for one object type, including metafields, options, and helper text
cosmic_types_create: create a new object type with a metafield schema (write key required)
cosmic_types_update: update a type's schema or metafield definitions (write key required)
cosmic_types_delete: delete an object type and all its objects (write key required)

AI Generation

cosmic_ai_generate_text: generate text with optional context pulled from existing objects in your bucket
cosmic_ai_generate_image: generate an image and store it in the media library (write key required)
cosmic_ai_generate_video: generate video with Google Veo and store it in the media library (write key required)
cosmic_ai_generate_audio: generate narration via OpenAI TTS, 13 voices available, stored in the media library (write key required)

The two tools worth calling out for agent work are cosmic_types_list and cosmic_types_get. An agent that reads your schema before writing produces valid metafields on the first attempt instead of guessing key names and failing.

Read-only vs full access

This is the part to get right before you point an agent at a production bucket.

With a read-only token, every write tool is blocked with a clear error message and read tools work as normal. Specifically, the blocked set is every *_create, *_update, and *_delete tool, plus all four AI generation tools, since each of those writes generated assets into your media library.

So a read-only setup still lets Claude Code explore your content models, read every object, and reason about your content while it writes application code. It just cannot mutate anything. That is a good default for a first session against real data.

What this looks like in practice

With the server connected, these are all single prompts:

List all blog posts in my Cosmic bucket

Create a new blog post titled "Getting Started with MCP" with the content
"This is an introduction to the Model Context Protocol..."

Update the blog post with ID "abc123" to change its status to published

Show me all images in the "blog-images" folder

Create a new object type called "Products" with fields for name, price,
description, and image

Generate audio narration of "Welcome to Cosmic CMS" using the "nova" voice
and upload it to my media library

The schema management case is the one developers tend to underestimate. Modeling content is usually a dashboard task. Through MCP it becomes something you can do from the same prompt where you are scaffolding the components that will consume it.

Agent scope: when the human has no Cosmic account yet

The hosted endpoint exposes a second, smaller scope at https://mcp.cosmicjs.com/v1/agent for the agent signup flow. It lets an AI agent provision a brand new Cosmic project and bucket on behalf of someone who does not have an account, without leaving the MCP transport. It exposes three tools:

cosmic_agent_signup (no auth): creates an unclaimed project and bucket tied to a human_email. Returns the agent_key, read_key, write_key, and a claim_url. Cosmic emails the human a 6-digit OTP.
cosmic_agent_verify (requires agent_key): submits the OTP, lifts restricted-mode limits, and enables AI generation.
cosmic_agent_status (requires agent_key): checks claim status, remaining limits, and recovers the bucket keys.

New buckets start in restricted mode: no AI credits, a maximum of 50 objects, and a 5 MB media cap. Unclaimed projects are hard-deleted after 14 days.

The bucket-scoped tools listed earlier are not available on the agent endpoint, and the agent tools are not available on the bucket endpoint. A single conversation often uses both: the agent signs the human up, captures the returned bucket keys, then switches to the bucket scope to start creating content.

MCP server vs Agent Skills

Cosmic offers two things that sound similar and do different jobs:

MCP server is for direct content management. It answers "list my blog posts." The AI calls tools that operate on your bucket.
Agent Skills is for code generation guidance. It answers "build a blog with Cosmic." The AI writes application code using the SDK.

Use both. Agent Skills helps Claude Code write code like this:

import { createBucketClient } from '@cosmicjs/sdk';

const cosmic = createBucketClient({
  bucketSlug: 'your-bucket-slug',
  readKey: 'your-read-key',
});

const { objects: posts } = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props(['title', 'slug', 'metadata'])
  .depth(1);

The MCP server then lets the same session manage the content that code renders. One tool writes the app, the other operates the data behind it.

Guardrails for production buckets

Four habits worth adopting:

Read key first. Connect with a read-only token for your first few sessions. Add the write key when you have seen what the agent actually does.
Experiment in a separate bucket. Bucket allowances scale with your plan: Free includes 1, Builder ($49/month) includes 2, Team ($299/month) includes 3, and Business ($499/month) includes 5. Point destructive experiments at a bucket you do not mind losing.
Treat the delete tools as manual-approval only. cosmic_objects_delete, cosmic_media_delete, and especially cosmic_types_delete are permanent, and deleting an object type takes all of its objects with it. Never let an agent call these speculatively.
Mind your seats. Plans include a set number of team members (Free 2, Builder 3, Team 5, Business 10) and additional users are $29/user/month, so decide who needs dashboard access rather than adding everyone by default.

Troubleshooting

The server does not appear in /mcp. Confirm .mcp.json is valid JSON at the repository root and restart Claude Code. Some Claude Code versions want the transport named explicitly, so if a hosted config still will not connect, try adding "type": "http" alongside url.

npx cannot find the package. The package name is @cosmicjs/mcp, scoped, including the @. Verify Node is installed and on your PATH.

Write tools return an error but reads work. Your bearer token is missing the write key. Check that the header is Bearer READ_KEY:WRITE_KEY with a colon and no spaces, or send the write key via X-Cosmic-Write-Key.

404 from the hosted endpoint. The bucket slug in the URL is wrong. Copy it again from Settings -> API Access, since the slug is not always identical to your project's display name.

Tools connect but return nothing. Confirm you are pointed at the bucket you think you are. Ask Claude Code to run cosmic_types_list and compare the result against the dashboard.

Next steps

Start with the hosted endpoint and a read-only token. Ask Claude Code to list your object types, then ask it to summarize the content in your bucket. Once that works, add the write key and let it draft something. The full tool reference and per-client config paths live in the MCP server documentation.

Try it yourself. Cosmic is an AI-powered headless CMS with a REST API, a TypeScript SDK, and a hosted MCP server. Create a free account and connect Claude Code in about five minutes. Evaluating Cosmic for a team? Book a call with Tony.

Originally published on the Cosmic blog.

Why Your AI Stack Should Be Model-Agnostic

Tony Spiro — Thu, 30 Jul 2026 22:08:15 +0000

The AI model landscape shifted three times in the last 90 days.

Claude Opus 5 shipped. Gemini 3.1 Pro dropped. Kimi K3 landed with competitive benchmark scores.

If your content infrastructure is wired to a single model, every one of those releases is a decision you have to make under pressure: do we migrate, do we stay, do we fork the integration?

Model-agnostic infrastructure means you route to the best model for the job, swap when a better option ships, and your content layer stays stable throughout.

The problem with single-model lock-in

Most teams start with one model because it is the fastest path to shipping. You pick the best available option, wire it into your stack, and move on. That works fine until one of the following happens:

A better model ships at lower cost per token
Your chosen model has a reliability incident and you need to reroute fast
A task-specific model outperforms the general-purpose one you standardized on
Your provider changes pricing, deprecates a version, or shifts rate limits
Your team wants to benchmark models against each other before committing

None of these are edge cases. All of them happened in the last quarter.

When your content workflow is tightly coupled to one model string, any of those events becomes a migration project. When your content infrastructure is model-agnostic, they become a config change.

What model-agnostic looks like in practice

Cosmic's AI layer exposes a single, consistent API regardless of which model you route to underneath. The models currently available, organized by cost tier:

Budget tier (1x cost multiplier)

GPT-5 Nano
GPT-5 Mini
Claude Haiku 4.5

Best for: high-volume, low-complexity tasks. Metadata generation, tag extraction, alt text, short summaries.

Standard tier (2x cost 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

Best for: most content workflows. Long-form drafting, structured generation, agentic tasks, code-adjacent content.

Premium tier (4x cost multiplier)

Claude Fable 5

Best for: tasks where output quality directly drives outcomes and cost per call is not the primary constraint.

Note: confirmed model ID strings from the API docs are claude-opus-5 (API default), gemini-3.1-pro-preview, gpt-5.2-codex, and kimi-k3. Full ID strings for all other models are in the AI API reference.

Every model above is accessible through the same Cosmic AI API call. You change the model parameter. Nothing else changes in your integration.

Routing by task, not by habit

Model-agnostic infrastructure enables a pattern most teams do not have today: routing different tasks to the model best suited for each one.

Here is a practical example using the Cosmic TypeScript SDK:

import { createBucketClient } from '@cosmicjs/sdk';

const cosmic = createBucketClient({
  bucketSlug: 'your-bucket-slug',
  readKey: 'your-read-key',
  writeKey: 'your-write-key',
});

// Budget tier: fast, cheap metadata generation at scale
const metadata = await cosmic.ai.generateText({
  model: 'claude-haiku-4-5', // Budget tier, 1x cost
  prompt: 'Generate SEO metadata for this blog post: ' + postBody,
  max_tokens: 300,
});

// Standard tier: long-form drafting
const draft = await cosmic.ai.generateText({
  model: 'claude-opus-5', // API default
  prompt: 'Draft a 1,200-word technical blog post on this topic: ' + brief,
  max_tokens: 2000,
});

// Standard tier: multimodal image-aware task
const altText = await cosmic.ai.generateText({
  model: 'gemini-3.1-pro-preview', // multimodal
  prompt: 'Write accessible alt text for this image',
  media_url: imageUrl,
  max_tokens: 100,
});

console.log(metadata.text);
console.log(draft.text);
console.log(altText.text);

The content layer, your Cosmic bucket, your object types, your structured data, stays identical across all three calls. Only the model changes.

If you use Cursor or Claude Code as your primary editor, you can connect Cosmic to Cursor or Claude Code with MCP in about 10 minutes and have your agents managing content directly, regardless of which underlying model you route to.

Why this matters more now than it did six months ago

The model release cadence has accelerated. In Q2 and Q3 2026 alone: Claude Sonnet 4.6, Claude Opus 5, Gemini 3.1 Pro, GPT-5 and variants, Claude Fable 5, Kimi K3. That is roughly one significant model event every two weeks.

Teams wired to a single model are making an implicit bet that the model stays best-in-class. That bet has not held for any model over a sustained period. The competitive frontier moves too fast.

The practical implication: content infrastructure and AI model selection are now separate concerns that should be managed separately. Your CMS should not force you to pick one and stay there.

What to do today

If you are building content workflows on Cosmic, three practical steps:

Audit your model usage. Are you defaulting to one model everywhere because that is what you started with, or because it is genuinely the best choice for each task? These are different answers.
Route by cost and capability. High-volume, low-complexity tasks belong on Budget tier models. Reserve Standard and Premium tier for drafting, reasoning, and tasks where output quality directly affects outcomes.
Build model-switching into your workflow from the start. If your agent or pipeline hardcodes a model string, extract it to a config variable. The next model release is coming in roughly two weeks.

Start building

Cosmic's full model list and AI API reference is at cosmicjs.com/docs/api/ai. Every model listed above runs against the same content layer, so changing models is a config change.

Try it yourself. Cosmic is an AI-powered headless CMS with a REST API, a TypeScript SDK, and model-agnostic AI generation built in. Create a free account and route your first call in minutes. Evaluating Cosmic for a team? Book a call with Tony.

Originally published on the Cosmic blog.

Cosmic vs Hygraph: Headless CMS Comparison (2026)

Tony Spiro — Fri, 24 Jul 2026 02:38:55 +0000

If you're evaluating headless CMS platforms and Hygraph is on your shortlist, you've probably noticed the overlap with Cosmic. Both are API-first, both target developers, and both position themselves as modern alternatives to monolithic CMS platforms. But they make meaningfully different bets on what a headless CMS should do in 2026.

This comparison covers pricing, API and SDK, developer experience, AI capabilities, team collaboration, and migration path. Every claim is sourced from public documentation and pricing pages.

The short version

Cosmic is a full-stack AI-native headless CMS with built-in AI Agents, Workflows, an MCP Server, and a JavaScript/TypeScript SDK. It is built for teams that want content infrastructure and AI tooling in one place.

Hygraph is a federated content platform that emphasizes content federation (pulling from multiple sources into one graph) and a schema-first content modeling approach. It is strong for complex enterprise content federation use cases.

The right choice depends on your use case.

Pricing

Cosmic

Free: $0/month, 1 Bucket, 2 team members, 1,000 Objects
Builder: $49/month, 2 Buckets, 3 team members, 5,000 Objects
Team: $299/month, 3 Buckets, 5 team members, 20,000 Objects
Business: $499/month, 5 Buckets, 10 team members, 50,000 Objects
Enterprise: Custom pricing
Additional users: $29/user/month

Hygraph

Free: $0/month, limited API calls, 2 environments, community support
Growth: $399/month, more environments, higher API limits, email support
Scale / Enterprise: custom pricing

Hygraph's paid tiers jump steeply from free to Growth at $399/month, making it expensive for small teams. Cosmic's $49 Builder plan gives you a meaningful production-grade entry point before committing to a higher tier.

API and SDK

Both platforms are API-first. The difference is in the SDK experience.

Cosmic ships an official TypeScript SDK with full type safety, a clean object-oriented interface, and built-in AI text generation. Cosmic's REST API covers all CRUD operations and is straightforward to use without the SDK if you prefer.

Hygraph relies on its REST Content API and a client SDK. Hygraph's heritage is schema/graph-based, which gives it power for complex relational queries but adds setup overhead for teams who want to move fast.

AI capabilities

This is where the platforms diverge most sharply.

Cosmic

AI Agents: deploy agents in Slack, WhatsApp, and Telegram that can read and write content, run Workflows, and respond to your team conversationally
AI Workflows: multi-step automated content pipelines (research, draft, SEO review, publish) running on a schedule or triggered by events
MCP Server: connect any MCP-compatible AI client directly to your content bucket
AI Text Generation: generate content using Claude, Gemini, GPT, or Kimi K3 models directly from the Cosmic API and dashboard

Hygraph

Hygraph has introduced some AI-assisted content features, primarily around content generation within the editor. It does not offer a native AI Agents layer, conversational Slack/WhatsApp integration, or an MCP Server.

If your team wants to run AI agents as part of your content operation, Cosmic is the only platform in this comparison that ships that natively today.

Developer experience

A few honest differences:

Onboarding: Cosmic's free tier requires no credit card and gets you to a working API in minutes.
Content modeling: Hygraph's schema-first modeling is powerful for complex relational structures. Cosmic's object and metafield system is faster to set up and easier for non-technical team members.
Environments: Hygraph offers multiple environments on paid plans. Cosmic's bucket model gives you isolated content contexts per project.
Localization: both platforms support localization. Hygraph has deep localization support baked into its schema model. Cosmic supports locale-specific content at the object level.

Team collaboration

Cosmic's AI Agents are built around team collaboration: your marketing team can edit content, trigger Workflows, and query your CMS directly from Slack or WhatsApp, without touching the dashboard. For teams where non-developers need to contribute content without developer bottlenecks, Cosmic's agent layer removes friction in a way that Hygraph's editor-centric model does not replicate.

Hygraph's collaboration is centered on the content editor and role-based permissions within the dashboard, which works well for teams that live in the CMS UI.

Content federation

Hygraph's standout feature is content federation: the ability to define a unified content graph that pulls from multiple third-party sources (Salesforce, commerce platforms, DAMs, etc.) alongside Hygraph-managed content. If your content strategy requires unifying data from many external systems into a single queryable layer, Hygraph's federation model is purpose-built for that.

Cosmic does not offer native content federation. If federation is your primary requirement, Hygraph is the stronger fit.

The honest summary

Choose Hygraph if:

Content federation across multiple external systems is your primary use case
You need deep schema-first relational content modeling
You are on a large enterprise contract that needs Hygraph's federation enterprise tier

Choose Cosmic if:

You want AI Agents, Workflows, and an MCP Server as part of your CMS, not a separate integration
You want your marketing team to manage content from Slack or WhatsApp without developer involvement
You need a production-grade CMS at $49/month before committing to a higher tier
You are building on Next.js, Astro, Nuxt, or any JavaScript framework and want a TypeScript-first SDK

Start for free on Cosmic — no credit card required.

Migrating from Umbraco to a Headless CMS (2026 Guide)

Tony Spiro — Fri, 24 Jul 2026 02:38:15 +0000

Umbraco has served a lot of teams well for a long time. It is a mature, open-source .NET CMS with a solid editor experience and a large community. But when teams move to a modern JavaScript frontend (React, Next.js, Astro, Nuxt), they hit a familiar friction points: Umbraco's .NET backend doesn't fit naturally into a Node/JS deployment pipeline, the API layer requires configuration work that headless-first platforms handle out of the box, and marketing teams end up bottlenecked waiting on developers for routine content changes.

This is the migration pattern Tripwire Interactive faced. The game developer behind the Red Orchestra and Killing Floor franchises was running Umbraco when they decided to rebuild their corporate website on a modern React stack. They needed each new game to get a dedicated landing page, and their marketing team needed to manage Blog, Career, and Press content without pulling in a developer every time. They moved to Cosmic.

Here is how a migration like that works, and what to think about before you start.

Why teams leave Umbraco for headless

The common triggers:

Frontend rebuild. Your team is moving to React, Next.js, Astro, or Nuxt and Umbraco's .NET backend creates a mismatch in the deployment stack.
Marketing team bottleneck. Content changes require developer involvement because Umbraco's template system is tightly coupled to the backend.
API-first requirement. You need to serve content to a web app, a mobile app, and potentially third-party integrations from one source of truth.
Hosting and ops overhead. Self-hosted Umbraco requires server maintenance, .NET runtime management, and database ops. A hosted headless CMS moves that off your plate.

What you are migrating

A typical Umbraco-to-headless migration involves four things:

Content types (Document Types in Umbraco) → Object Types in your headless CMS
Content nodes (the actual content tree) → Objects
Media library → hosted media in your headless CMS
Frontend templates → your new JavaScript frontend (React, Next.js, etc.)

Step 1: Audit your Umbraco content model

Before touching anything, export and document your existing Document Types. For each type, note the type name and alias, every property and its data type, any nested content or block list structures, and relationships between types.

Step 2: Map Document Types to Object Types

In Cosmic, content is organized as Object Types with Metafields. Each Umbraco Document Type becomes a Cosmic Object Type. Each property becomes a Metafield.

Step 3: Export content from Umbraco

Umbraco's Content Delivery API (available in Umbraco 13+) is the cleanest export path. For older versions, use the Examine index or a custom controller to export content as JSON.

Step 4: Import content to Cosmic

With your content exported and your Object Types defined, import using the Cosmic JavaScript SDK. Run imports in batches with a small delay between inserts if you have hundreds of objects.

Step 5: Update your frontend

With content in Cosmic, your React or Next.js frontend queries it via the SDK instead of Umbraco's Delivery API. The pattern is the same; only the client changes.

What Tripwire got out of it

Tripwire Interactive migrated from Umbraco to Cosmic when rebuilding their corporate site on React. In the words of Owen Liversidge, Lead Developer:

"Cosmic allowed us to easily integrate a secure and fast back-end API into our React app. Cosmic fit our needs with its simple web-based dashboard so that members of our marketing team can create, edit, and delete new content on the fly. Our team has been enjoying the ease of use with the new system."

The marketing team can now manage game landing pages, blog posts, career listings, and press releases without filing a ticket.

Common migration pitfalls

Rich text with embedded media. Migrate media assets first, then find-and-replace URLs in exported content before import.
Nested content / Block List. These map to Cosmic repeater or parent metafield groups but the JSON structure differs. Budget extra time for a transform function.
URL redirects. Preserve clean URLs or set up 301 redirects. Google has indexed those URLs.
Editor training. Budget 30 minutes of walkthrough with your marketing team.

Next steps

Cosmic's free tier is the fastest way to validate the content model before committing to a full migration. Create a bucket, define one or two Object Types mirroring your Umbraco Document Types, and run a small batch import to see how the data lands.

Start for free on Cosmic — no credit card required.

The Power of Headless CMS and AI Agents for Modern Content Teams

Tony Spiro — Tue, 21 Jul 2026 23:25:26 +0000

The way we create, manage, and deliver content is changing fast. Two technologies are leading that charge: headless CMS architecture and AI agents. On their own, each is powerful. Together, they're transforming how teams build digital experiences.

Note: This article was written using Kimi K3, Moonshot AI's open-source frontier model. Kimi K3 will be available as a built-in model inside Cosmic soon... stay tuned

What Is a Headless CMS? (A Quick Refresher)

A traditional CMS bundles your content backend with a specific frontend. Think of the classic monolithic website platforms. A headless CMS removes that constraint by separating content management from presentation entirely. Your content lives in a central hub and is delivered via APIs to anywhere:

Websites and web apps
Mobile applications
Smart devices and wearables
Digital signage and kiosks
AI agents

This API-first approach means your content is future-proof. A new channel emerges? You don't rebuild anything. You just connect.

What Are AI Agents?

AI agents go beyond simple chatbots or one-off prompts. An AI agent is a system that can perceive, reason, and act, often autonomously, to accomplish goals. Think of agents that can:

Research topics and draft content briefs
Generate and optimize copy for different channels
Analyze performance data and suggest improvements
Automate repetitive publishing workflows
Personalize content for different audience segments

The key difference from basic AI tools: agents don't just respond. They do things. They chain tasks together, make decisions, and interact with other systems through APIs.

Why Headless CMS + AI Agents Work So Well Together

AI agents need structured, accessible data to work with. A headless CMS provides exactly that.

1. Structured Content Is Agent-Friendly

AI agents thrive on structure. When your content is stored as well-defined objects with clear fields, types, and relationships, agents can read, write, and manipulate it programmatically. No scraping messy HTML. No guessing at page layouts. Just clean, predictable data.

2. APIs Are the Perfect Handshake

Because headless CMS platforms expose content through APIs, AI agents can plug in directly. Your agent becomes a first-class citizen in your content workflow, drafting, updating, localizing, and organizing content alongside your human team.

3. Automation That Actually Scales

Imagine an agent that:

Monitors your analytics for underperforming pages
Rewrites headlines and meta descriptions for better SEO
Creates localized versions for your international markets
Submits everything as drafts for human review

With a headless CMS, this workflow is an afternoon of API integration, not a months-long engineering project.

4. Humans Stay in Control

The best part of this pairing: the CMS remains your single source of truth with built-in guardrails. Revision history, draft states, role-based permissions, and approval workflows mean AI agents accelerate your team without going rogue. Humans review, refine, and publish. Agents handle the heavy lifting. Your team keeps final say on voice and what goes live.

Real-World Use Cases

Content generation: Agents draft articles, product descriptions, and landing pages directly into the CMS
Localization: Automatically translate and adapt content for global audiences
SEO optimization: Continuously audit and improve metadata, alt text, and internal links
Content migrations: Agents intelligently map and transform legacy content into structured models
Personalization: Serve dynamic content variations based on user behavior and segments
Editorial assistance: Suggest related content, flag inconsistencies, and enforce brand voice

Getting Started

Ready to bring AI agents into your content operations? Here's a simple path:

Structure your content well. Define clear content models with meaningful fields. Good structure in means good results out.
Start with one workflow. Pick a high-volume, low-risk task like generating meta descriptions or alt text.
Use API keys with scoped permissions. Give agents exactly the access they need, no more.
Keep humans in the loop. Route agent output to drafts first. Build trust, then expand autonomy.
Measure and iterate. Track time saved, content quality, and engagement. Let data guide your next automation.

The Bottom Line

A headless CMS gives your content freedom. AI agents give your team leverage. Together, they create a content operation that's faster, smarter, and ready for whatever channel comes next.

The teams winning today combine human creativity with machine efficiency. Your content deserves the same advantage.

Curious how Cosmic makes this easy? With a powerful REST API, built-in AI capabilities, and flexible content modeling, Cosmic is the headless CMS built for the age of intelligent content.

Start building for free and see what's possible. Or book a quick intro with Tony to see how teams are using Cosmic AI Agents today.

How to Migrate to a Headless CMS (WordPress, Webflow, Ghost, Shopify)

Tony Spiro — Tue, 21 Jul 2026 20:31:10 +0000

Most teams reach the same wall at different speeds. Your content is buried inside a platform that tightly couples your editing experience, your schema, and your delivery layer. You can't serve the same content across a mobile app, a web app, and a third-party integration without duplicating work.

Migrating to a headless, API-first CMS changes this. Your content becomes a structured data layer that any frontend can consume, your editors keep a clean dashboard, and your developers get a REST API and SDK they can query from anywhere.

The migration itself has always been the hard part. Until now.

Cosmic Migrate: Point It at Your Site, and It Does the Work

Cosmic's migration tool removes the manual work that makes migrations painful. You point it at your existing site, and it:

Analyzes your pages and content structure
Proposes a content model with the right object types, metafields, and relationships
Migrates your content into a structured, API-first CMS with a clean REST API and JavaScript/TypeScript SDK ready to use

It supports WordPress, Webflow, Ghost, and Shopify out of the box. No CSV exports, no manual field mapping, no writing migration scripts from scratch.

👉 Try the migration tool at cosmicjs.com/migrate

Why Teams Migrate to a Headless CMS

The content is locked to one delivery layer. WordPress, Webflow, and Ghost were built to put content on web pages. Serving that same content to a mobile app, a kiosk, or a third-party integration requires workarounds or rebuilding the content in a separate system. A headless CMS stores content as structured data and exposes it via API. Your content team edits once. Every surface consumes from the same source of truth.

The schema is rigid. WordPress gives you posts, pages, and custom post types with plugin overhead for anything more complex. In a headless CMS, you define exactly the content model your project needs.

Developer velocity slows down. When developers need to change how content is structured, they are often waiting on backend changes in a monolithic CMS. In a headless setup, the CMS is infrastructure. Neither the frontend team nor the content team blocks the other.

This is the value teams like FINN experience directly. Maximilian Wuhr, Co-Founder at FINN, put it plainly: "Cosmic is: us never having to ask a developer to change anything on the backend of our website."

Migration Paths by Platform

From WordPress to a Headless CMS

Cosmic Migrate analyzes your WordPress site's structure, identifies your post types and fields, proposes equivalent Object Types and metafields in Cosmic, and migrates your content and media. Your WordPress posts become objects. Your ACF fields map to metafields. Your media uploads to Cosmic's media library.

From Webflow to a Headless CMS

Cosmic Migrate reads your Webflow Collection structure and maps it to Cosmic Object Types. Plain Text fields become metafields. Reference fields become relationship metafields. After migration, your Webflow Collections are Cosmic Object Types accessible via the REST API.

From Ghost to a Headless CMS

Cosmic Migrate ingests your Ghost export and creates objects in Cosmic with your posts' content, tags, authors, and featured images. Your Ghost JSON becomes a structured Cosmic bucket ready to query.

From Shopify to a Headless CMS

Cosmic Migrate analyzes your Shopify store and migrates your blog posts, pages, and editorial content into Cosmic. Product data typically stays in Shopify; Cosmic handles the content layer.

How the Migration Process Works

Go to cosmicjs.com/migrate and enter your site URL or upload an export file
Cosmic analyzes your site and surfaces a proposed content model
Review the proposed Object Types and metafields. Adjust if needed
Confirm the migration. Cosmic creates your Object Types, migrates your content, and uploads your media
Connect your frontend with the Cosmic SDK and your bucket credentials

For most sites under a few hundred pages, the analysis and migration complete in minutes.

Real Teams, Real Results

FINN moved their marketing content to Cosmic and removed the developer bottleneck from their content publishing workflow entirely.

Parque Explora, Colombia's largest science and technology museum, uses Cosmic to power multilingual content delivery across their digital properties.

Eastman Music runs their product catalog and editorial content through Cosmic, serving content via the REST API.

Vuetify uses Cosmic to manage their documentation and community content.

Ready to Migrate?

If your content is locked inside a platform that slows your team down, the path out is now much shorter.

👉 Start your migration at cosmicjs.com/migrate

Want to talk through your specific migration? Book a call with Tony Spiro to walk through your setup.

Best Free Headless CMS Platforms in 2026 (Ranked and Compared)

Tony Spiro — Mon, 20 Jul 2026 16:23:21 +0000

If you're evaluating headless CMS platforms, the free plan is usually where the decision starts. You want to build something real, validate your architecture, and make sure the developer experience is solid before committing to a paid tier.

The problem: free plans vary wildly. Some give you a genuinely useful starting point. Others are barely enough to run a demo. This post fixes that. We ranked the best free headless CMS platforms in 2026 by what you actually get on the free tier.

What to look for in a free headless CMS

Objects / content entries: how much content can you store before hitting a wall?
API access: can you build a production-ready app, or are you rate-limited out of the gate?
Team members: can more than one person use the free plan?
Buckets / workspaces: can you run more than one project?
Upgrade path: when you outgrow free, does the next tier make sense?
AI features: does the platform give you any AI tooling on free, or lock it behind enterprise?

1. Cosmic

Free plan includes:

1 Bucket (project)
2 Team members
1,000 Objects
REST API + JavaScript/TypeScript SDK
Media storage and imgix image optimization
1 AI Agent (draft, publish, and manage content from Slack, WhatsApp, or Telegram)
Full dashboard access

Cosmic's free plan is the only one in this list that includes an AI Agent out of the box. You can connect a Slack channel and have an AI Agent draft, edit, and publish content without touching the dashboard. The REST API and TypeScript SDK are fully available on free, so you can build a real production app without hitting artificial API rate limits.

When you're ready to grow, the Builder plan ($49/month) gives you 2 Buckets, 3 Team members, 5,000 Objects, and 3 AI Agents.

Start free on Cosmic | See all plans

2. Contentful

Free plan includes: 10 Team members, 2 roles, 2 locales, 25 Content types, 100,000 API calls/month, 10,000 records.

Contentful's free plan is generous on team seats (10 users), which makes it appealing for larger teams just starting out. The bigger limitation: paid plans start at $300/month, which is a significant jump once you need more locales, roles, or API capacity.

3. Sanity

Free plan includes: up to 20 users, unlimited content types, 1M API CDN requests/month, 100GB asset storage, 2 datasets.

Sanity's free tier is genuinely generous on users and API calls. The tradeoff: steeper learning curve, and Sanity Studio requires configuration that's less approachable for non-technical editors.

4. Strapi

Free plan includes: self-hosted (open source), unlimited users, unlimited content types, REST API, community support only.

Strapi is open source, so the software itself is free. But "free" here means you're managing your own hosting, security, backups, and updates. Strapi Cloud (managed) starts at $29/month.

5. Storyblok

Free plan includes: 1 user, 1 locale, 200 components, 100,000 API calls/month, 1TB asset storage.

Storyblok's free plan is limited to a single user, which makes it essentially a solo-developer tier. Even a two-person team needs a paid plan.

6. Prismic

Free plan includes: 1 user, 1 locale, unlimited documents, 4M API calls/month, page builder.

Prismic's free plan has the highest API call limit in the group (4M/month). Like Storyblok, the 1-user cap is the main constraint.

7. Hygraph

Free plan includes: 3 seats, 2 roles, 2 locales, 10 components, 500,000 API calls/month, unlimited asset storage, comments and live preview.

Hygraph's Hobby plan is one of the more collaborative free tiers, with 3 seats, commenting, and live preview included. It's GraphQL-native, which is a strength for developers who want a flexible query layer.

Which free headless CMS is right for you?

Choose Cosmic if you want AI-native content tooling from day one, a clean REST API and TypeScript SDK, and a free plan that covers real solo or two-person projects.
Choose Contentful if you have a larger team (up to 10) who need to prototype together.
Choose Sanity if you're a developer who wants maximum flexibility and is comfortable with a code-first setup.
Choose Strapi if you want full ownership and have the DevOps resources to self-host.
Choose Storyblok or Prismic if you're a solo developer and visual editing or high API throughput is your top priority.
Choose Hygraph if you want collaborative features and GraphQL on a free tier.

Start free on Cosmic, no credit card required | View pricing | Book a demo

Best Contentful Alternatives in 2026 (Ranked & Compared)

Tony Spiro — Mon, 20 Jul 2026 16:22:43 +0000

If you've been shopping for a Contentful alternative, you already know the pattern: great product, pricing that scales faster than your traffic, and a feature roadmap that prioritizes enterprise accounts over indie teams. This list cuts through the noise. We compared seven platforms on pricing, AI features, developer experience, and content modeling flexibility. Cosmic is on this list too, and we'll be upfront about where it fits and where it doesn't.

What to look for in a Contentful alternative

Before picking a platform, decide which of these matters most to your team:

Free plan generosity: Does it let you build something real before paying?
Pricing transparency: Can you predict your bill as you scale?
Developer experience: REST API, SDK quality, TypeScript support, local preview?
AI-native features: Content generation, AI agents, semantic search built in, or bolt-on?
Content modeling: How flexible are the field types and relationships?
Team collaboration: Roles, permissions, editorial workflows, draft/publish controls?

1. Cosmic

Best for: lean teams and developer-led projects that want AI-native features without enterprise pricing.

Cosmic is a headless CMS built around the idea that content teams and developers should be able to move independently. Marketers publish from a clean editor. Developers query content via REST API or the TypeScript SDK. And AI Agents handle the repetitive work in between.

What sets it apart from Contentful:

AI Agents included on every plan. Free accounts get 1 Agent and 1 Workflow. Agents connect to Slack, WhatsApp, and Telegram, draft and publish content, run scheduled tasks, and browse the web for research.
Cosmic Insights included. Cookieless web analytics with per-object attribution, built in.
Semantic search. Find content by meaning across your bucket.
MCP Server. Cosmic has a native MCP server, so AI tools like Claude can read and write your content directly.
Predictable pricing. No metered API calls on the paid plans.

Pricing (verified July 2026):

Free: $0/month, 1 Bucket, 2 Team members, 1,000 Objects, 1 Agent
Builder: $49/month, 2 Buckets, 3 Team members, 5,000 Objects, 3 Agents
Team: $299/month, 3 Buckets, 5 Team members, 20,000 Objects, 10 Agents
Business: $499/month, 5 Buckets, 10 Team members, 50,000 Objects, 25 Agents
Additional users: $29/user/month

Start free, no credit card required

2. Sanity

Best for: teams that want maximum content modeling flexibility and are comfortable with a steeper setup curve.

Sanity uses a code-first content studio configured in TypeScript. Strengths: extremely flexible schema, GROQ query language, real-time collaboration. Watch out for: the free plan limits you to 2 datasets, and pricing scales by API usage on higher tiers.

3. Storyblok

Best for: marketing teams and agencies that prioritize visual editing and a component-based approach.

Storyblok's Visual Editor is genuinely good. Non-technical editors can see exactly what content will look like before publishing. Watch out for: the free plan is limited to 1 user, and pricing steps up significantly for team features.

4. Hygraph

Best for: teams with complex content federation needs or existing GraphQL infrastructure.

Hygraph is built around a federated content approach. Strengths: content federation, strong GraphQL API, good localization. Watch out for: pricing can be opaque for teams not already GraphQL-native.

5. Strapi

Best for: teams that want full control and are comfortable self-hosting.

Strapi is open-source and self-hostable. Strengths: open source, full self-hosting, large plugin ecosystem. Watch out for: self-hosting means you own infrastructure, security patches, and uptime.

6. Prismic

Best for: marketing-focused teams building slice-based page layouts with Next.js, Nuxt, or SvelteKit.

Prismic's Slice Machine is a unique approach: developers define reusable page sections in code, and editors compose pages from them. Watch out for: the slice model can feel rigid for content-heavy applications.

7. Builder.io

Best for: teams that prioritize visual page building and A/B testing over structured content management.

Builder.io is more of a visual CMS and page builder. Strengths: powerful visual editor, A/B testing built in. Watch out for: structured content modeling is not its primary strength.

How to choose

You want AI agents and automation built in: Cosmic
You need maximum schema flexibility and have developer resources: Sanity
Your editors need a visual preview before publishing: Storyblok
You have GraphQL infrastructure or content federation needs: Hygraph
You need self-hosting and data sovereignty: Strapi
You're building slice-based marketing pages: Prismic
Landing pages and A/B testing are your primary use case: Builder.io

All seven platforms have free tiers or trials. The fastest way to validate fit is to spin up a project and build something real before committing.

Try Cosmic free, no credit card required or book a 20-minute intro with Tony to see it in action.