DEV Community: Tony Spiro

The Content Flywheel: How We Run AI Agents From Publish to Insights and Back

Tony Spiro — Fri, 21 Aug 2026 15:46:32 +0000

Most AI content tooling stops at the draft. You prompt a model, it produces something, a human edits it, and the loop ends there. Whatever happens to that content after publish never makes it back to the thing that wrote it.

At Cosmic, we've completed the loop. Our agents publish into Cosmic, Cosmic Insights measures what the content does, and the same agents read that data on a schedule and decide what to write, fix, or retire. That closed loop is what we call the content flywheel, and we run it on cosmicjs.com every day.

Here is how it actually works, with real numbers from the project that powers content on this website.

The four stages

A content flywheel needs four things wired together. Miss one and it stops being a loop.

A content model an agent can write to. Structured, queryable fields.
An agent with real capabilities. Read the CMS, write to the CMS, browse the web, post to Slack.
Measurement attached to the content. Traffic attributed back to the object itself.
A scheduled goal that closes the loop. Something that wakes up, reads the data, and acts.

Cosmic gives you all four in one place, which is the entire reason the loop is short enough to be useful.

Stage 1: The content model

Our blog post type has the fields you would expect, plus the ones that make measurement possible: seo_title, seo_description, teaser, published_date, last_updated, and relationship fields for author, category, and tags.

That structure matters more than it sounds. Because last_updated is a real date field and tags is a real relationship, an agent can ask questions like "which posts tagged AI Agents have not been touched in 90 days" and get an answer it can act on. A single freeform body field leaves that question unanswerable.

Agents read and write this model through the same REST API and TypeScript SDK your app uses:

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

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

// Find posts in a topic cluster that are going stale.
// Query relationship fields by object ID, not slug: slugs can
// collide across object types and resolve to the wrong object.
const { objects } = await cosmic.objects
  .find({
    type: 'blog-posts',
    'metadata.tags': '6a21aa1ed66dd9646b9e028a', // "AI Agents" tag object ID
    'metadata.last_updated': { $lt: '2026-05-20' },
  })
  .props('id,title,slug,metadata.last_updated')
  .limit(25);

The agent uses the same query. There is no separate agent API to learn and no second copy of your content to keep in sync.

Stage 2: The agents

An agent in Cosmic is a team member you configure. You grant capabilities: read content, write content, browse the web, call external APIs, send messages to Slack or Telegram, read analytics, work on a connected repository. What the agent does is decided by the capabilities you give it.

Ours are split by job, the same way a content team is:

A content lead agent that researches, writes, and publishes into the bucket.
A social coordinator agent that pulls the day's published posts and writes platform-specific copy.
A growth agent that reads Insights and reports to the team in Slack.

They hand work to each other. The social agent asks the content agent what shipped in the last 24 hours, gets back titles, slugs, and categories, and writes from that instead of guessing.

Stage 3: Measurement that points back at the content

This is the stage most teams skip, and it is the one that makes the loop real.

Cosmic Insights tracks pageviews, visitors, sessions, bounce rate, custom events, and revenue. The part that matters for a flywheel is object attribution. Add one meta tag to your page and traffic rolls up by Cosmic object alongside the URL path:

<meta name="cosmic-context" content='{"object_id":"6a873688f234aa885b778173","object_type":"blog-posts"}'>

Now the agent that wrote the post can ask how that exact object performed. Custom events fill in the rest:

window.cosmicInsights('signup_cta_click', {
  object_id: '6a873688f234aa885b778173',
  object_type: 'blog-posts',
});

On cosmicjs.com, here is what our event data looked like over the 30 days ending August 20, 2026:

Event	Events	Visitors
signup_started	751	645
signup_completed	350	335
cta_click	314	247
signup_cta_click	265	223
lesson_view	243	97

A 46.6% completion rate from signup start to finish is a number we can hold a strategy against. Google organic sent 19,664 events from 16,838 visitors in that same window, which tells us which half of the funnel deserves attention. These are rolling-window figures, so they move; the point is that an agent can pull them on demand rather than guess.

Stage 4: The scheduled goal that closes it

A capability without a cadence is still a manual process. In Cosmic you give an agent a goal with a cron schedule, and it works through that goal in a bounded loop until it decides it is done.

Our loop-closing goals look roughly like this:

Weekly, Tuesday morning: read the last seven days of Insights by path and by custom event, compare against the prior seven, and post the deltas to Slack with content recommendations.
Weekly: scan competitor blogs and pricing pages, cite every claim with the URL fetched in that same run, and recommend counter-content.
Daily: report which posts published in the last 24 hours so downstream agents can act on them.

The rule we enforce on every one of these: every number in the output has to come from a tool call made in that same run. No remembered figures, no plausible-looking estimates. An agent that fabricates a metric poisons the flywheel faster than a slow one starves it.

The week the flywheel caught something we missed

Here is the concrete example, and it is not a flattering one.

Our highest-traffic blog cluster is a set of AI coding tool comparisons. They pull thousands of Google visitors a month. When we pulled signup_cta_click broken down by page, none of those posts appeared in the list. Zero measured CTA clicks against our best organic traffic.

The obvious conclusion was that the posts had no calls to action. So we read the objects back out of the CMS and checked. Every post had a mid-article signup block and a bottom CTA block, both rendering correctly on the live page.

The actual problem was in the shared CTA blocks. Cosmic lets you define reusable rich-text blocks and reference them from any post with a token like {{bottom-cta}}. Ours pointed at a bare signup URL with no UTM parameters and no click event bound to it. The clicks were happening. Nothing was recording them.

One edit to two shared blocks instrumented every blog post in the bucket at once, because the blocks are referenced by every post that uses them. The blog channel now shows up in source attribution.

The most valuable output here was diagnostic. The flywheel told us that a question we thought we had answered had never actually been measured.

What we got wrong the first time

Three honest lessons from running this for a while:

Attribution gaps look like content failures. Our first read of the data said the comparison posts were bad at converting. The real answer was that we could not see the conversions. Verify instrumentation before you rewrite content.

Read the object back after every write. We have had writes report success while silently dropping a field, usually on repeaters and relationship fields. Our agents now re-read every object after writing it and confirm the field actually stored. Use explicit object IDs for relationship fields, since slugs can collide across object types.

Bounce rate is a weak signal on its own. A developer who lands from Google, reads a comparison post, and leaves satisfied counts as a bounce. Pair it with custom events before you conclude anything.

Building your own

The shortest path to a working loop:

Model your content with real fields, especially dates and relationships. Agents can only act on structure they can query.
Add the Insights script and a cosmic-context meta tag to your content templates so traffic rolls up by object.
Fire one custom event on your primary conversion action.
Create an agent with content read and write capability, plus analytics access.
Give it one scheduled goal that reads last week's data and reports what changed.

Start with step five as a report-only goal. Let it tell you what it sees for a few weeks before you let it publish anything. Trust in the loop should be earned with evidence, and the loop is very good at producing evidence.

You can read more about how agents are configured on the Cosmic AI agents page, or connect your own AI tools directly to your content model through the Cosmic MCP server.

Give your AI agents a content backend they can write to. Structured, versioned content objects, a REST API and TypeScript SDK, and an MCP server your coding agent connects to directly. The Free plan includes 1 Bucket, 1,000 Objects, and 1 agent. No credit card required.

Start for free or see Cosmic for AI teams.

How to Migrate from Payload CMS to Cosmic

Tony Spiro — Sat, 15 Aug 2026 19:34:05 +0000

Last verified: August 14, 2026. Every claim about Payload on this page was checked against Payload's own live pages on that date: Payload Cloud pricing and status, What is Payload, and the Local API docs. Cosmic pricing was checked against cosmicjs.com/pricing. Note that payloadcms.com/pricing returned a 404 on this date; Cloud plan details now live on the /cloud-pricing page.

What actually changed at Payload

Payload has joined Figma. The announcement is on the Figma blog, and it is linked from the top of every page on payloadcms.com.

Two things follow from that, both stated by Payload directly on its Cloud page:

New Payload Cloud deployments are paused. In Payload's words: "Although deployment of new projects is currently paused, existing Cloud projects will continue running as normal."
Existing Cloud projects will eventually move. From the same page's FAQ, answering "Will I need to migrate my project?": "Yes, eventually. There is no rush, but we are planning to build something better that you will be able to migrate to once it's available."

Here is what has not changed. Payload the framework is still open source, still actively developed, and still self-hostable. Payload's own docs state that Payload remains a self-hosted solution, and that anywhere you can run a Next.js app, you can run Payload. If you self-host Payload today, nothing above forces your hand.

The teams with a real decision to make are the ones who picked Payload Cloud because they wanted someone else to run the database, the file storage, and the deploys.

Should you migrate at all?

Three honest options. Pick based on your team, not on vendor news.

Stay on Payload and self-host it. The right call if your content model leans on Payload's code-first strengths: custom access control, hooks, field-level permissions, or an admin panel you have meaningfully customized in React. You will need to own a database, object storage, and a deploy target. Payload is a Next.js application, so this is familiar work for a Next.js team.

Wait for whatever Figma ships. Payload says there is no rush and that a migration path to something new is planned. If your project is stable and you have infrastructure people, waiting costs you little.

Move to a managed API-first CMS. The right call if the reason you chose Payload Cloud was that you did not want to run infrastructure, and you would rather not go back to running it. That is the path this guide covers.

What you give up moving to Cosmic

Stating this plainly, because a migration guide that pretends there are no tradeoffs is not worth reading.

The Local API goes away. Payload's biggest technical advantage is that it runs in the same Node process as your app, so you can query the database directly from a React Server Component with no network hop. Cosmic is an HTTP API. For most content sites the difference disappears behind caching and static generation, but it is a genuine architectural change and you should know it going in.
No GraphQL. Payload exposes REST and GraphQL. Cosmic offers a REST API and a TypeScript SDK, and does not offer GraphQL. If your frontend is built on Payload's GraphQL endpoint, that query layer gets rewritten.
Code-first config becomes dashboard-first modeling. In Payload your collections live in version-controlled TypeScript. In Cosmic you define Object Types in the dashboard or over the API. Some teams consider that a downgrade in reviewability, and others consider it the point.
Custom admin components. React components you injected into the Payload admin panel do not carry over.
Auth and access control. Payload ships user auth and granular access control as first-class features. If you used Payload as your application's auth layer and not only as a CMS, that responsibility moves elsewhere.

If several of those matter a lot to you, self-hosting Payload is probably the better answer, and you should stop reading here. No hard feelings.

Mapping Payload concepts to Cosmic

Payload	Cosmic
Collection	Object Type
Document	Object
Global	Single Object (a type with one Object)
Field	Metafield
`slug`	Object slug
Upload collection	Media library
Relationship field	Object metafield (`object` / `objects`)
Array field	Repeater metafield
Blocks field	Repeater, or rich text with Content Blocks
Group field	Parent metafield group
Draft / published	Object status (`draft` / `published`)
Localization	Locale variants on an Object Type

The shapes line up closely enough that most migrations are a data-transform problem rather than a redesign.

Step 1: inventory what you actually have

Before writing any script, list every collection and global, the document count in each, and which fields are genuinely used. Migrations balloon because teams port fields nobody has filled in for two years.

Payload's Local API gives you counts quickly:

import { getPayload } from 'payload'
import config from '@payload-config'

const payload = await getPayload({ config })

for (const collection of payload.config.collections) {
  const { totalDocs } = await payload.count({ collection: collection.slug })
  console.log(`${collection.slug}: ${totalDocs}`)
}

Write the output down. It is your migration checklist and your verification target at cutover.

Step 2: export from Payload

Run this inside your Payload project so @payload-config resolves. Two details matter: pagination: false returns every document instead of the first page, and depth: 0 keeps relationships as raw IDs instead of expanding them into nested objects. You want raw IDs, because you are going to remap them yourself.

import { getPayload } from 'payload'
import config from '@payload-config'
import fs from 'node:fs/promises'
import path from 'node:path'

const payload = await getPayload({ config })
const outDir = path.resolve('./payload-export')
await fs.mkdir(outDir, { recursive: true })

// Collections
for (const collection of payload.config.collections) {
  const { docs } = await payload.find({
    collection: collection.slug,
    pagination: false,
    depth: 0,
    overrideAccess: true,
  })

  await fs.writeFile(
    path.join(outDir, `${collection.slug}.json`),
    JSON.stringify(docs, null, 2),
  )

  console.log(`exported ${docs.length} from ${collection.slug}`)
}

// Globals
for (const global of payload.config.globals) {
  const doc = await payload.findGlobal({ slug: global.slug, depth: 0 })

  await fs.writeFile(
    path.join(outDir, `global-${global.slug}.json`),
    JSON.stringify(doc, null, 2),
  )
}

Commit that folder somewhere safe. Everything after this point is reversible as long as the export exists.

Step 3: model your content in Cosmic

Create one Object Type per Payload collection. You can do it in the dashboard, or script it so the whole migration is repeatable:

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!,
})

await cosmic.objectTypes.insertOne({
  title: 'Posts',
  singular: 'Post',
  slug: 'posts',
  metafields: [
    { key: 'excerpt', title: 'Excerpt', type: 'textarea' },
    { key: 'content', title: 'Content', type: 'markdown' },
    { key: 'hero', title: 'Hero Image', type: 'file' },
    {
      key: 'author',
      title: 'Author',
      type: 'object',
      object_type: 'authors',
    },
  ],
})

Migrate types with no relationships first (authors, categories, tags), then the types that point at them. That ordering saves you a second reconciliation pass.

Step 4: move the media

Payload upload documents store a filename and a URL. Pull each file and push it into the Cosmic media library, keeping a map from the old Payload ID to the new Cosmic media name so you can rewrite references later.

const idMap = new Map<string, string>()

for (const doc of uploadDocs) {
  const res = await fetch(doc.url)
  const buffer = Buffer.from(await res.arrayBuffer())

  const { media } = await cosmic.media.insertOne({
    media: { originalname: doc.filename, buffer },
    folder: 'payload-import',
    alt_text: doc.alt ?? '',
  })

  idMap.set(doc.id, media.name)
}

If you set alt text in Payload, carry it across now. Alt text lives on the Cosmic media record itself, so every Object referencing that image inherits it, which is one less accessibility cleanup later.

Step 5: convert rich text

This is the step that surprises people, so budget real time for it.

Payload stores rich text as a structured JSON tree, not as markdown or HTML. You cannot drop that JSON into a markdown metafield and expect it to render. You need a serializer that walks the tree and emits markdown or HTML.

Payload's rich text documentation covers converting its editor state to other formats, and that is the tool to reach for. Two things to watch:

Uploads embedded in rich text become nodes referencing an upload ID. Rewrite those to the Cosmic media URLs from your idMap in Step 4.
Blocks embedded in rich text need a destination. Either flatten them into markdown, or create a reusable Cosmic Content Block and reference it with a {{block-name /}} token in a rich text metafield.

Convert one document, eyeball the output, then convert the rest. Do not batch-convert 2,000 documents on faith.

Step 6: import into Cosmic

With media mapped and rich text serialized, the import itself is short. Keep a Payload-ID to Cosmic-ID map as you go so relationship fields can be resolved on a second pass.

import { createBucketClient } from '@cosmicjs/sdk'
import posts from './payload-export/posts.json'

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

for (const doc of posts) {
  await cosmic.objects.insertOne({
    type: 'posts',
    title: doc.title,
    slug: doc.slug,
    status: doc._status === 'published' ? 'published' : 'draft',
    metadata: {
      excerpt: doc.excerpt ?? '',
      content: await toMarkdown(doc.content),
      hero: doc.hero ? idMap.get(doc.hero) : null,
      author: authorIdMap.get(doc.author),
    },
  })
}

Preserve the original slug values. That single decision is what keeps your URLs, your rankings, and your inbound links intact.

Step 7: rewire the frontend

If your app is Next.js, this is the most mechanical part of the whole project. Payload Local API calls become Cosmic SDK calls.

Before:

const payload = await getPayload({ config })
const { docs } = await payload.find({
  collection: 'posts',
  limit: 10,
  sort: '-publishedDate',
})

After:

import { createBucketClient } from '@cosmicjs/sdk'

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

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

Use .props() to request only the fields the page renders. Payload's Local API had no network cost, so over-fetching was cheap. Over an HTTP API it is not, and trimming the payload is the single easiest performance win in the port.

Step 8: verify, then cut over

Work through this before you flip DNS:

Counts match. Compare every Object Type count against the inventory from Step 1.
Spot-check the ugly documents. Not the simple ones. The post with nested blocks, four images, and a relationship array.
Every relationship resolves. Query with .depth(1) and confirm nothing comes back null.
Slugs are identical to production Payload for every public URL.
Media loads on a real page render, not only in the dashboard.
Redirects staged for any URL that genuinely had to change.
Keep Payload running in parallel until the checks pass. There is no prize for deleting it early.

What this costs on Cosmic

Verified against cosmicjs.com/pricing on August 14, 2026:

Plan	Price	Buckets	Team members	Objects
Free	$0/mo	1	2	1,000
Builder	$49/mo	2	3	5,000
Team	$299/mo	3	5	20,000
Business	$499/mo	5	10	50,000
Enterprise	Custom	Custom	Custom	Custom

Additional team members beyond a plan's included seats are $29/user/month.

The practical move is to run the whole migration on the Free plan first. One Bucket and 1,000 Objects is enough to prove the export, the transform, and the import against real content before anyone approves a budget line.

FAQ

Is Payload CMS being shut down?
No, and nothing on this page should be read that way. Payload is open source and self-hostable, and Payload states that existing Cloud projects continue running as normal. What changed is that new Payload Cloud deployments are paused, and Payload says existing Cloud projects will eventually need to migrate to a future replacement.

Can I keep my URLs?
Yes, as long as you carry the slug field across unchanged. Cosmic Objects have a slug you control, so a one-to-one mapping is normal.

Does Cosmic support GraphQL?
No. Cosmic provides a REST API and a TypeScript SDK. Payload does expose GraphQL, so if your frontend depends on it, plan on rewriting that data layer.

How long does a migration take?
It depends almost entirely on rich text and blocks. A handful of collections with plain fields is an afternoon. A heavily block-driven site with thousands of documents is a multi-week project, and the serializer is where the time goes.

Can I run both during the transition?
Yes, and you should. Import into Cosmic, point a staging branch at it, verify against the Step 8 checklist, and only then cut over.

Next steps

If you were on Payload Cloud for the managed hosting and you want to stay out of the infrastructure business, the cheapest way to evaluate Cosmic is to migrate one collection and look at the result.

Create a free Bucket and run the export script above against your smallest collection. If you would rather walk through your content model with someone first, book time with our CEO Tony Spiro.

Claude Marks Its AI-Generated Content Now: What That Means for Your CMS

Tony Spiro — Tue, 11 Aug 2026 22:03:00 +0000

Anthropic published a support article on how Claude marks AI-generated content, and it spent this morning on the Hacker News front page. The document itself is short and mostly technical. The discussion was neither, because it lands on a question most content teams using AI have been quietly deferring: when a model touches your content, is there a record, and whose job is it to keep one?

Here is what actually shipped, what it can and cannot prove, and the part that falls to you.

What Anthropic shipped

Anthropic signed the EU AI Act's Article 50(2) Code of Practice on Transparency of AI-Generated Content. Claude models launched in the EU on or after August 2, 2026 support machine-readable marking at launch, and Anthropic says it is working to add marking support to models released before that date.

There are two mechanisms.

Imperceptible watermarks in text. Claude weaves a mark directly into the text it generates. A reader cannot see it, and Anthropic states it does not change the meaning, quality, or readability of the output. Because the watermark is part of the text, it travels with the text when it is copied and pasted, and it may persist through some editing.

C2PA signed provenance metadata on files. When Claude generates a supported file type, including .svg, .png, and .jpg, it attaches signed provenance metadata following the Coalition for Content Provenance and Authenticity open standard. A signed label signals the file was processed by Claude and lets you detect whether it has been tampered with.

Marking is applied at the model level, so it follows the models across the surfaces they run on: Claude Platform (API), Claude, Claude Code, Claude Cowork, and Claude Tag. Embedded watermarks also apply when supported models are accessed through AWS, Google Cloud, or Microsoft Foundry. Anthropic is explicit that coverage is not uniform, and that signed file metadata in particular may not be supported on every platform. Marking applies worldwide, not only to users in the EU. Detection documentation is described as forthcoming.

If you build products on Claude, Anthropic's own guidance is that you should independently assess what Article 50 requires of you. Signing the code of practice covers Anthropic's models. It does not discharge your obligations for the thing you shipped.

What a detected mark tells you, and what it does not

The limitations section is the most useful part of that document for anyone running a publishing pipeline, and Anthropic is unusually direct about it.

A mark means Claude processed the text. It does not establish that Claude wrote it. Anthropic gives the examples itself: people use Claude to proofread, translate, summarize, and convert files, and the output can carry a mark even when the underlying ideas, text, or data came from somewhere else. Any policy that treats a detected mark as proof of machine authorship will produce false accusations against your own writers.

Absence of a mark proves nothing. Anthropic lists the cases: content from a model released before marking was supported, text that has been heavily edited or paraphrased or translated, passages too short to carry a reliable signal, and files whose metadata was stripped.

File metadata is fragile in completely ordinary ways. Anthropic names format conversion, re-saving, and screenshots as things that strip C2PA metadata. If you have ever run images through an optimization or resizing pipeline, you have probably stripped provenance metadata already without noticing. Verify what actually survives your own media pipeline before you rely on it.

So the honest summary: watermarking is a meaningful transparency measure for the open internet and a weak internal record for your team. Detection answers "did a model touch this" with a qualified maybe. It does not answer the questions your team will actually be asked.

The questions you will actually be asked

When a claim in a published post turns out to be wrong, or a customer asks how your documentation is produced, or legal asks what your AI disclosure covers, the questions are specific:

Which model produced this draft, at what version?
Was it a person using an assistant, or an agent running unattended?
Which human reviewed it before it went live, and on what date?
Were the product facts, pricing, and customer references checked against a source of truth?
How many published pages are fully machine-generated and have never been read by anyone on the team?

None of those are recoverable from an invisible watermark, even a perfectly detected one. All of them are trivially recoverable from your CMS, if you decided in advance to store them.

Store provenance as typed fields

Provenance that lives in a Slack thread, a spreadsheet, or someone's memory is not provenance. Add it to the content model so it is queryable, reportable, and impossible to skip.

A minimal set of fields that covers the questions above:

Field	Type	Purpose
`ai_assisted`	Switch	Was a model involved at all
`ai_role`	Select	`drafted`, `edited`, `translated`, `researched`
`ai_model`	Text	Model and version, e.g. `claude-sonnet-5`
`human_reviewer`	Object	Relationship to your authors type
`review_date`	Date	When a person actually signed off
`facts_verified`	Switch	Product facts and pricing checked against source

The ai_role distinction is the one that matters most, because it is exactly the distinction watermark detection cannot make. A post Claude drafted end to end and a post Claude proofread can carry the same mark. Your own record separates them.

Writing that record with the Cosmic TypeScript SDK:

npm install @cosmicjs/sdk

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

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

await cosmic.objects.updateOne('OBJECT_ID', {
  metadata: {
    ai_assisted: true,
    ai_role: 'drafted',
    ai_model: 'claude-sonnet-5',
    human_reviewer: 'jane-doe',
    review_date: '2026-08-11',
    facts_verified: true,
  },
});

The payoff is the query. Finding every AI-drafted post that no human has signed off on becomes one request instead of an audit:

const { objects: unreviewed } = await cosmic.objects
  .find({
    type: 'blog-posts',
    'metadata.ai_assisted': true,
    'metadata.facts_verified': false,
  })
  .props('slug,title,metadata.ai_model,metadata.review_date')
  .limit(100);

Run that on a schedule and the answer to "how much unreviewed machine-generated content is live on our site" stops being a guess. Because the fields are typed and served over the REST API, you can surface the same record on the page itself if your disclosure policy calls for it, without maintaining a second system to track it.

One note on the practical side: adding a field to a content model and backfilling it is a content-team task in a headless CMS, not an engineering ticket. Maximilian Wuhr, Co-Founder at FINN, described the value of that arrangement plainly:

"Cosmic is: us never having to ask a developer to change anything on the backend of our website."

Reporting on it

Provenance fields tell you how a piece was made. The next question is whether it performs, and whether machine-drafted work holds up against human-drafted work on your own site.

Cosmic Insights rolls traffic up by the actor who created the underlying content, splitting it across human users, agents, and automations. That turns a philosophical argument into a measurable one. If agent-drafted pages bounce harder or convert worse than human-drafted pages, you will see it in the numbers rather than debating it in a meeting. If they perform the same, that is worth knowing too.

What to do this quarter

Six things, none of which require a replatform.

Add provenance fields to your content models. Start with the six above. Ship them before you need them, because retrofitting provenance onto two years of archives is guesswork.
Backfill the last 90 days only. Recent content is what people are reading and what will get questioned. Older archives can be marked unknown, honestly.
Test what your media pipeline does to C2PA metadata. Upload a Claude-generated image, run it through your normal transform and optimization path, and check whether the Content Credentials survive. Assume they do not until you have verified it.
Write down your disclosure policy in one paragraph. What level of model involvement triggers a public disclosure on the page? "Claude drafted this" and "Claude proofread this" are different, and your policy should say so before a reader asks.
Keep detection out of your enforcement policy. If you are checking freelancer or agency submissions, treat a watermark hit as a reason to open a conversation. Anthropic's own documentation states that a detected mark is not fully conclusive, so it cannot carry a policy violation on its own.
Scope the keys your agents hold. If an agent can write to production, the provenance record it leaves is the only trail you have. Cosmic issues separate read and write keys, so a client connected with a read-only key gets the read tools while every write tool and all four AI generation tools are blocked with a clear error message. Details are on the MCP server page and in Connect Claude to Your CMS.

The through line

Model-level watermarking is a good development, and it solves a problem at the wrong altitude for your purposes. It helps the broader internet identify synthetic content at scale. It does very little for the team that has to explain how a specific paragraph on a specific page came to exist.

That record is yours to keep, and the only place it can reliably live is next to the content itself, as structured fields you can query. Teams that add those fields now will answer provenance questions in one API call. Teams that wait will reconstruct them from memory, which is another way of saying they will not answer them at all.

If you are already running AI in your publishing workflow, this is a one-afternoon change with a long tail of value. You can model provenance fields on the Cosmic free plan and query them over the REST API today.

Start free or book 15 minutes with our CEO to talk through how your content model should record agent work.

Sources

Anthropic, How Claude marks AI-generated content, Claude Help Center
C2PA, Coalition for Content Provenance and Authenticity

Originally published on the Cosmic blog.

Connect Claude to Your CMS: A 5-Minute Guide to the Cosmic MCP Server

Tony Spiro — Mon, 10 Aug 2026 22:03:30 +0000

If you already run Claude every day, the next obvious question is whether it can touch your content. Not summarize it. Not draft copy in a chat window you then paste somewhere. Actually read your content model, query it, and write back to it.

Cosmic answers that with an MCP server. This guide gets you connected in about five minutes, then covers the part most people skip: what Claude is allowed to do once it is connected.

What MCP actually gives you

Model Context Protocol is a standard way for an AI client to discover and call tools. Instead of you describing your CMS to Claude in prose, Claude asks the server what tools exist and calls them directly.

The Cosmic MCP server exposes 18 bucket-scoped tools. They cover objects, object types, media, and AI generation. Bucket-scoped is the important word: the server operates against one Bucket, using the keys you give it, and it cannot reach across your other Buckets.

The five-minute setup

1. Get your Bucket keys

In your Cosmic dashboard, open your Bucket, then Settings > API Access. Copy three things: your Bucket slug, your read key, and your write key. The keys are separate on purpose, and that separation is the single most useful control in this whole setup. More on that below.

2. Add the server to your MCP client config

The hosted endpoint is the fastest path and needs no install. Point your client at https://mcp.cosmicjs.com/v1/buckets/{your-bucket-slug} and authenticate with your keys in the Authorization header.

For Claude Desktop, edit your config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

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

Cursor takes the same shape in .cursor/mcp.json for a single project, or ~/.cursor/mcp.json globally.

Read the bearer token carefully: read key, colon, write key. Drop the :your-write-key suffix and the connection becomes read-only. Hold onto that detail, because it is the control worth understanding before you point any of this at production.

If you would rather run the MCP process inside your own dev environment, the @cosmicjs/mcp package ships a stdio binary that reads credentials from environment variables:

{
  "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"
      }
    }
  }
}

Save the file and restart the client. The Cosmic tools show up in the tool list.

3. Verify the connection

Ask Claude something read-only first:

"List the object types in this Bucket and tell me how many objects are in each."

If you get back your real content model, you are connected. If you get nothing, the key or the Bucket slug is wrong, and the error message will say which.

4. Try a real task

Once reads work, the useful prompts look like this:

"Find every published blog post missing an SEO description and list the slugs."

"Create a draft post from this outline, set the author to Tony Spiro, and leave status as draft."

"Add alt text to every image in the media library that does not have any."

That last one is the kind of chore that never gets done manually and takes an agent about a minute.

The control that matters: read keys and write keys

Here is the part worth understanding before you hand an agent your production Bucket.

Cosmic issues separate read and write keys. Give an MCP client a read-only key and it gets the read tools only. Every write tool returns a clear blocked error. Nothing is guessed, nothing is inferred from a system prompt, and no amount of clever prompting talks its way past it.

You can verify this yourself in under a minute:

Set the Authorization header to Bearer your-read-key with no write key and no colon
Ask Claude to create a new object
Read the blocked error it returns

That is a checkable guardrail, not a policy document. It is also the honest starting posture for anyone connecting an agent to real content: read-only first, then widen scope deliberately once you trust the workflow.

When you are ready for writes, the safe pattern is a write-enabled key pointed at a staging Bucket, with the production Bucket still read-only. Cosmic plans include multiple Buckets from Builder up, so a dedicated staging Bucket for agent work is a reasonable setup rather than an exotic one.

Writing content through the API instead

If you would rather script the workflow than chat it, the TypeScript SDK covers the same ground:

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!,
});

// Read: find drafts with no SEO description
const { objects: posts } = await cosmic.objects
  .find({ type: 'blog-posts', status: 'draft' })
  .props('id,title,slug,metadata.seo_description');

const missing = posts.filter((p) => !p.metadata?.seo_description);

// Write: patch one of them
await cosmic.objects.updateOne(missing[0].id, {
  metadata: {
    seo_description: 'A short, specific summary under 155 characters.',
  },
});

Note that writeKey is a separate argument from readKey. Omit it and every write call fails, which is the same guardrail the MCP server relies on.

What this is good for, and what it is not

Good fits today:

Content audits: missing metadata, broken internal links, stale dates, orphaned objects
Bulk mechanical edits: alt text, SEO descriptions, tag normalization, category cleanup
Draft generation against your real content model, so the shape is correct on the first pass
Answering questions about your own content library without opening the dashboard

Not a good fit yet:

Unsupervised publishing to production. Keep a human on the publish step.
Anything where a wrong write is expensive and hard to reverse.

The practical rule: let the agent do the reading and the drafting, and keep the irreversible actions behind a person.

Frequently asked questions

Do I need a paid plan to use the MCP server?
You can start on the Free plan, which includes 1 Bucket, 2 team members, and 1,000 Objects. If you want a separate staging Bucket for agent writes, that starts at the Builder plan ($49/month, 2 Buckets, 3 team members, 5,000 Objects).

Does Cosmic offer a GraphQL endpoint for this?
No. Cosmic offers a REST API and the JavaScript/TypeScript SDK. The MCP server sits on top of the same REST API.

Can I limit which object types an agent can touch?
The key-level control is read versus write. For tighter scoping, point the agent at a Bucket that only contains the content you want it to work on.

Does this work with clients other than Claude?
MCP is a client-agnostic standard, so any MCP-compatible client can connect to the same server with the same 18 tools. Cursor is covered above, and the hosted endpoint speaks the streamable-HTTP transport that other clients use.

Try it on a real Bucket

The fastest way to understand what an agent can do with a proper content model behind it is to connect one and ask it a question about your own content.

Create a free Cosmic account. No credit card required.
Read the MCP server docs for the exact client configuration
Want a walkthrough of the agent workflows other teams are running? Book 30 minutes with Tony

Cosmic is a YC W19 company building the content layer for teams that want their AI tools to work against real, structured content instead of copy pasted into a chat box.

Medusa.js + Next.js: How to Add a Content Layer to Your Storefront

Tony Spiro — Fri, 07 Aug 2026 19:28:03 +0000

Medusa is a strong commerce engine. It owns products, variants, pricing, inventory, carts, orders, and fulfillment, and it exposes all of it through a clean Store API. Once you have the Next.js Starter Storefront running, the commerce half of your site is basically solved.

Then marketing asks for a buying guide on every category page, a founder story block on the product detail page, a seasonal landing page that goes live Friday at 9am, and an FAQ section that changes weekly. None of that belongs in your commerce database, and none of it should require a deploy.

This post walks through the pattern we see working best: keep Medusa as the source of truth for commerce, add a headless CMS as the source of truth for editorial content, and join them in the Next.js layer on a shared key.

The problem with putting content in Medusa

Medusa lets you attach arbitrary metadata to products. It is tempting to stuff your marketing copy in there and call it done. That falls apart quickly for three reasons.

No editing experience. metadata is a key-value bag. Your content team gets a JSON blob, no rich text, no image handling, no preview, no revision history.
No content modeling. A buying guide has a title, hero image, intro, sections, related products, and an author. Flattening that into string keys means every consumer has to re-parse it.
Content that is not product-shaped has nowhere to live. A holiday gift guide, a shipping policy page, a comparison table, a homepage hero: none of these map to a product record at all.

The fix is a second system with its own model and its own editor, joined at read time.

Draw the ownership line first

Before you write any code, write down who owns what. This one decision prevents most of the sync bugs teams hit later.

Data	Owner	Why
Product handle, title, variants	Medusa	Commerce truth, drives cart and checkout
Price, inventory, availability	Medusa	Must be real time, never cached in a CMS
Cart, orders, customers, fulfillment	Medusa	Transactional
PDP long-form story, lifestyle imagery	CMS	Editorial, changes without a deploy
Buying guides, blog posts, landing pages	CMS	No product record exists
FAQs, size guides, care instructions	CMS	Reusable across many products
Navigation, promo banners, homepage blocks	CMS	Merchandising, changes weekly

The rule to enforce in code review: price and inventory never come from the CMS. Duplicating those into a content system creates a window where your site shows a price that checkout will reject. Read them from Medusa on every request.

Step 1: Get the Medusa storefront running

Start from the official Next.js Starter Storefront so you inherit the cart, checkout, and account flows.

npx create-medusa-app@latest my-store

That scaffolds a Medusa server and a Next.js storefront. Your storefront needs two environment values to talk to the backend:

# .env.local
NEXT_PUBLIC_MEDUSA_BACKEND_URL=http://localhost:9000
NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY=pk_...

The publishable key is created in the Medusa Admin under Settings, and it scopes requests to a sales channel. Requests to the Store API without it will be rejected.

Set up the Medusa JS SDK once and export a single client:

// src/lib/medusa.ts
import Medusa from '@medusajs/js-sdk';

export const medusa = new Medusa({
  baseUrl: process.env.NEXT_PUBLIC_MEDUSA_BACKEND_URL!,
  publishableKey: process.env.NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY!,
});

Fetching a product by its handle looks like this:

const { products } = await medusa.store.product.list({
  handle: 'classic-tee',
  fields: '*variants.calculated_price',
});

const product = products[0];

Step 2: Model the content side

Now add the content layer. In Cosmic, create an Object Type called Product Content with a metafield for every editorial element your PDP needs.

A model that has held up well in production:

Metafield key	Type	Purpose
`handle`	Text (unique)	The join key. Must match the Medusa product handle exactly.
`story`	Markdown	Long-form product narrative below the buy box
`lifestyle_images`	Files	Editorial photography separate from catalog shots
`care_guide`	Markdown	Reusable care or sizing content
`faqs`	Repeater	Question and answer pairs rendered as an accordion
`related_reading`	Objects	Links to blog posts or buying guides

The handle field is the whole design. Make it unique so two content entries can never claim the same product, and tell your editors it has to match Medusa character for character. Everything else in the model is free to change without touching commerce.

Install the Cosmic SDK and create the client:

npm install @cosmicjs/sdk

// src/lib/cosmic.ts
import { createBucketClient } from '@cosmicjs/sdk';

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

Then a small helper that fetches content for a handle and returns null instead of throwing when nothing exists yet:

// src/lib/product-content.ts
import { cosmic } from './cosmic';

export async function getProductContent(handle: string) {
  try {
    const { object } = await cosmic.objects
      .findOne({ type: 'product-content', 'metadata.handle': handle })
      .props('title,slug,metadata')
      .depth(1);

    return object;
  } catch (error: any) {
    if (error.status === 404) return null;
    throw error;
  }
}

That null return matters. It is what lets you launch a product before marketing has written anything for it.

Step 3: Join them in a server component

With both clients in place, the product page fetches from each system in parallel and renders one page.

// src/app/products/[handle]/page.tsx
import { medusa } from '@/lib/medusa';
import { getProductContent } from '@/lib/product-content';
import { notFound } from 'next/navigation';

export default async function ProductPage({
  params,
}: {
  params: Promise<{ handle: string }>;
}) {
  const { handle } = await params;

  const [{ products }, content] = await Promise.all([
    medusa.store.product.list({
      handle,
      fields: '*variants.calculated_price',
    }),
    getProductContent(handle),
  ]);

  const product = products[0];
  if (!product) notFound();

  return (
    <main>
      {/* Commerce: always from Medusa */}
      <h1>{product.title}</h1>
      <BuyBox product={product} />

      {/* Editorial: from the CMS, optional by design */}
      {content?.metadata.story && (
        <section className="product-story">
          <Markdown>{content.metadata.story}</Markdown>
        </section>
      )}

      {content?.metadata.faqs?.length > 0 && (
        <FaqAccordion items={content.metadata.faqs} />
      )}
    </main>
  );
}

Three things worth calling out.

Medusa decides whether the page exists. If there is no product, you 404. A content entry with no matching product should never render a page, because there would be nothing to add to a cart.

Every content block is conditional. The page has to render correctly with zero CMS content. Test that path deliberately by pointing a local build at a handle that has no entry.

Fetch in parallel. Promise.all keeps the two round trips from stacking. On a PDP that difference is visible in your LCP.

Step 4: Keep pages fresh without redeploying

Static rendering is what makes this pattern fast. Cache invalidation is what makes it usable for a content team.

Tag your content fetches, then invalidate the tag from a webhook.

// src/app/api/revalidate/route.ts
import { revalidateTag } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const secret = request.headers.get('x-webhook-secret');

  if (secret !== process.env.REVALIDATE_SECRET) {
    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
  }

  const payload = await request.json();
  const handle = payload?.data?.metadata?.handle;

  if (handle) {
    revalidateTag(`product-content-${handle}`);
  }

  return NextResponse.json({ revalidated: true });
}

Point a Cosmic webhook at that route for the Object Edited and Object Published events. An editor publishes a change, the webhook fires, that single product page rebuilds. No deploy, no full site rebuild, no Slack message to a developer.

Do the same in reverse for Medusa: subscribe to product update events and revalidate the matching path when a title or description changes.

One exception to keep in mind. Price and inventory should not rely on webhook timing. Render those parts dynamically or fetch them client side so a customer never sees a cached price that checkout will reject.

Step 5: Everything that is not a product page

The PDP join is the interesting technical part. The larger traffic win is usually the pages that have no product record at all.

With a content layer already wired in, these become straightforward:

Buying guides and comparison pages. These are the pages that rank for research-stage queries. Model them as a guides type with a related_products field holding a list of handles, then hydrate live prices from Medusa at render time.
Category landing pages. Medusa gives you the collection and its products. The CMS gives you the hero, the intro copy, and the merchandising blocks above the grid.
Campaign pages. Marketing builds and schedules them without a developer. Cosmic supports scheduled publishing, so a Friday 9am launch is a field, not a deploy window.
Policy and support pages. Shipping, returns, sizing. Low glamour, high support-ticket deflection.

Same pattern each time: content from the CMS, live commerce data from Medusa, joined on the handle.

Four mistakes to avoid

Copying prices into the CMS. It will drift. When it drifts, customers see one number and get charged another. Always read price from Medusa.

Using the product ID as the join key. IDs change when you reseed a database or migrate environments. Handles are stable, human readable, and already unique in Medusa.

Making content required. If a missing CMS entry breaks the page, you have coupled your product launches to your content calendar. Optional by default.

Two sources of truth for the product title. Pick one, and it should be Medusa, since that is what appears on the order. If marketing needs a different display headline, add a separate display_headline field so the intent is explicit.

Why Cosmic fits this stack

A few specifics that matter when you are pairing a CMS with Medusa:

REST API and a TypeScript SDK. @cosmicjs/sdk is typed and works in Next.js server components without adapters or codegen steps.
Fully managed. You are already running a Medusa server and a database. Adding a second self-hosted service to patch and scale is real operational cost. Cosmic is hosted, so the content layer is one API call, not another deployment.
AI-assisted authoring. Editors can draft product stories, FAQs, and guide content directly in the dashboard, which is where the volume problem usually lives for catalogs with thousands of SKUs.
Scheduled publishing and webhooks. Both are built in, which is what makes the revalidation flow above work end to end.

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."

Get started

The whole integration is about 60 lines of glue code: one Medusa client, one Cosmic client, one join key, one webhook route.

Start free with Cosmic and model your first Product Content type in a few minutes. The Cosmic docs cover the SDK and webhook setup, and the Medusa docs cover the Store API side.

If you are planning a larger migration or running a catalog with thousands of SKUs, book time with Tony, our CEO, and he will walk through the content model with you.

FAQ

Can I use Cosmic to manage products instead of Medusa?
You can model product content in Cosmic, but you should not replace Medusa's product records. Carts, pricing rules, inventory, and orders depend on them. Use Cosmic for the editorial layer around the catalog.

Does this work with the Medusa Next.js Starter Storefront?
Yes. The pattern above drops into the starter's existing product route. You are adding a second data fetch alongside the Medusa one, and leaving the cart and checkout flows untouched.

How do I handle products with no content entry yet?
Return null from your content helper on a 404 and render every content block conditionally, as shown in Step 2 and Step 3. The product page stays fully functional.

What about multi-region or multi-language storefronts?
Medusa handles regional pricing and currency. Cosmic supports locales on objects, so you can request content in the visitor's locale using the same handle-based lookup.

Originally published on the Cosmic blog.

Sanity vs Strapi: Which Headless CMS Should You Choose in 2026?

Tony Spiro — Thu, 06 Aug 2026 22:03:25 +0000

Sanity and Strapi both call themselves headless, both let you define schemas in code, and both have large developer followings. They answer a different question underneath.

Sanity gives you a hosted content database, the Content Lake, with an open source editing environment on top. Strapi gives you a Node.js application under the MIT license that you run yourself, or pay Strapi Cloud to run for you.

That one architectural fork decides your query language, your upgrade path, your compliance story, your AI options, and your bill. This comparison walks through each of those with numbers verified against both vendors' live pricing pages on August 5, 2026.

TL;DR

	Sanity	Strapi
Model	Hosted content platform (Content Lake)	Open source Node.js app, MIT licensed
Who operates it	Sanity	You, or Strapi Cloud
Query API	GROQ and GraphQL over HTTP, JS client	REST and GraphQL from your own instance
Database	Managed, no direct access	Postgres, MySQL, or MariaDB that you own
Editing UI	Sanity Studio, an open source React app you deploy	Bundled admin panel
Entry price	Free plan, up to 20 seats, 10k documents	Community edition, free forever, unlimited entries
Seat cost	$15/seat/month on Growth	$15/seat/month on Growth, 3 seats included
Hosting cost	Included	Yours to pay, or $35 to $450 per project per month on Cloud
Governance extras	Comments, tasks, scheduled publishing on Growth; audit trail and SSO on Enterprise	Content History and Releases on Growth; Review Workflows and Audit Logs on Enterprise
Best fit	Teams that want structured content as a service with many editors	Teams that need to own the runtime and the data layer

Architecture: hosted content lake vs. an app you run

Sanity stores every document in the Content Lake, a hosted, schemaless JSON store with a real-time layer. You never provision a database or patch a server. You do give up direct database access, which matters if your security review requires the data to sit inside your own VPC.

Strapi is a Node.js application. You choose Postgres, MySQL, or MariaDB, you deploy it, and you own the runtime. That means full control over network boundaries, extensions, and custom middleware. It also means you own Node version upgrades, dependency patches, major-version migrations, backups, and on-call.

Strapi Cloud removes most of that operational load, and the pricing page shows the trade in plain terms. Starter projects at $35 per project per month sleep when idle. Always-on runtime begins with Pro at $90 per project per month. A 99.9% uptime SLA arrives at Business, $450 per project per month.

A useful way to decide: if your team can name the person who will handle a CVE in a transitive dependency on a Friday afternoon, self-hosted Strapi is a reasonable choice. If nobody's name comes to mind, a managed platform is cheaper than it looks.

Content modeling

Both tools model content in code, which keeps schema changes in version control and in code review.

Sanity schemas are JavaScript objects registered in your Studio. Portable Text handles rich text as structured data instead of an HTML blob, which pays off when the same content renders to web, native mobile, and voice. References are first class and resolve inside queries.

Strapi models are defined through the Content-Type Builder in the admin panel, which writes JSON schema files into your repository. Dynamic Zones let editors assemble a page from a library of components, which is the closest thing either product has to visual page building out of the box. Components, relations, and custom fields cover most modeling needs, and the Blocks editor handles structured rich text.

Strapi's advantage here is that the modeling UI ships with the product. Sanity's advantage is that Portable Text and the reference system are more rigorous once your content graph gets complicated.

APIs and developer experience

Sanity queries use GROQ, a projection language built for the Content Lake:

import { createClient } from '@sanity/client';

const client = createClient({
  projectId: 'your-project-id',
  dataset: 'production',
  apiVersion: '2026-01-01',
  useCdn: true,
});

const posts = await client.fetch(
  `*[_type == "post" && defined(slug.current)]{ title, "slug": slug.current, publishedAt }`
);

GROQ is genuinely powerful. It also has a learning curve, and every new engineer on your team pays it once.

Strapi exposes REST endpoints from your own instance, with GraphQL available as a plugin:

const res = await fetch(
  'https://your-app.example.com/api/articles?populate=cover&sort=publishedAt:desc',
  { headers: { Authorization: `Bearer ${process.env.STRAPI_TOKEN}` } }
);

const { data } = await res.json();

Strapi's API is conventional and quick to pick up. The cost shows up in performance work: response times depend on the instance you are running, the database you provisioned, and any caching you added yourself. Sanity's CDN handles that layer for you.

AI capabilities in 2026

This is where the two products have moved fastest, and where the fine print matters.

Sanity ships AI credits with every plan, 1,000 per month on Free and Growth, with overage billed at $0.05 per credit. Its AI features cover generation and transformation inside the editing workflow, plus embeddings and semantic search over the Content Lake.

Strapi introduced Strapi AI on the self-hosted Growth plan, also 1,000 credits per month, with additional credits at $1.50 per 100. Worth reading carefully before you commit: Strapi's own CMS pricing table lists Strapi AI as "Not yet available" in the Enterprise column at the time of writing. If AI in the editor is a requirement and you are heading toward an Enterprise contract, confirm availability with their sales team rather than assuming feature parity with Growth.

Both vendors now ship an MCP server, which lets AI coding agents read and write content through a standard protocol. Strapi announced general availability of theirs recently. We wrote about how the two approaches differ in Cosmic MCP Server vs Strapi MCP.

Pricing at realistic team sizes

Both vendors publish clear pricing, which is refreshing. The lists are not directly comparable, because Sanity's price includes hosting and Strapi's does not.

Sanity, verified August 5, 2026

Free: $0, up to 20 seats, 2 public datasets, 10,000 documents, 250,000 API requests per month, 100 GB assets
Growth: $15 per seat per month, up to 50 seats, private datasets, 25,000 documents, comments, tasks, scheduled publishing
Enterprise: custom, adds SSO with SAML, custom roles, audit trail, uptime SLA
Add-ons and overages: increased quota at $299 per month, dedicated support at $799 per month, extra datasets at $999 per dataset per month, additional API requests at $1 per 25,000, assets at $0.50 per GB

Strapi, verified August 5, 2026

Community: free forever, MIT license, unlimited entries and API calls, community support
Growth: $45 per month including 3 seats, additional seats $15 each, adds Strapi AI, Live Preview, Releases, and 30 days of Content History
SSO: a $150 per month add-on, plus $50 per month per seat
Enterprise: custom, adds Review Workflows, Audit Logs, and a SOC 2 report
Strapi Cloud hosting, priced per project: Starter $35, Pro $90, Business $450 per month, with additional environments at $60 or $300 per month depending on tier

A five-editor team, one production project

	Monthly	What is included
Sanity Growth	$75 (5 x $15)	Hosting, CDN, private dataset, 25k documents
Strapi Growth, self-hosted	$75 license (3 seats + 2 x $15)	License and features only. Your infrastructure, database, backups, and upgrade labor sit on top
Strapi Growth on Cloud Pro	$75 license + $90 hosting	Always-on runtime, weekly backups, multi-environment
Cosmic Team	$299	3 Buckets, 5 team members, 20,000 objects, fully managed

At five seats, Sanity Growth carries the lowest sticker price of the group, and we are not going to pretend otherwise. The number to watch on Sanity is per-seat scaling: twenty editors on Growth is $300 per month, and quota add-ons are priced in the hundreds. The number to watch on Strapi is the engineering time that never appears on the invoice, plus per-project hosting if you run more than one property.

Governance and compliance

Sanity puts collaboration features on Growth: comments, tasks, scheduled publishing, and 90 days of change review. SSO, custom roles, and audit trail are Enterprise.

Strapi gives Community users Role-Based Access Control for free, which is unusually generous. Content History with 30 days of retention and Releases arrive on Growth. Review Workflows and Audit Logs are Enterprise, and SSO is a paid add-on with its own per-seat charge.

If approval chains and audit trails are non-negotiable for you, price the Enterprise tier on both sides early. That is the point where headless CMS quotes stop being self-serve on either platform.

When to choose Sanity

You want structured content as a service and no infrastructure to run
You have many editors and want a low per-seat entry point
Your content graph is complex and Portable Text plus references earn their keep
Real-time collaborative editing matters to your workflow
Your team is willing to learn GROQ

When to choose Strapi

Data residency, VPC isolation, or air-gapped deployment is a hard requirement
You want an MIT-licensed codebase you can fork and extend without vendor permission
Your plugin and customization needs go beyond configuration
You have real DevOps capacity, or you are happy to pay Strapi Cloud for it
Unlimited entries and API calls at zero license cost fits your scale

Where Cosmic fits

Cosmic sits in the managed camp with Sanity, with a deliberately smaller surface area. You get a REST API and a TypeScript SDK, AI built into the editing workflow, and a dashboard that non-technical teammates can use on day one without a Studio deployment.

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

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

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

No local server, no database to provision, no GROQ to learn. Vuetify, the Vue component library with more than four million monthly npm downloads, cut server response times from 300-400 ms to about 50 ms after moving to Cosmic, with a team small enough that nobody has time to babysit a CMS.

The editorial side is the other half of it. 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.

Cosmic is a Y Combinator W19 company, and pricing is public: Free at $0 with 1 Bucket, 2 team members, and 1,000 objects; Builder at $49 per month; Team at $299 per month; Business at $499 per month; Enterprise custom. Additional users are $29 per user per month. Full details are on the pricing page.

FAQ

Is Strapi actually free?

The Community edition is free under the MIT license, with unlimited entries and API calls. Hosting, database, backups, monitoring, and upgrades are yours to fund. Growth features like Live Preview, Releases, Content History, and Strapi AI start at $45 per month with 3 seats included.

Does Sanity charge per seat?

Yes. Growth is $15 per seat per month for up to 50 seats. The Free plan allows up to 20 seats with 2 public datasets and 10,000 documents.

Does Cosmic charge per seat?

Yes. Each plan includes a set number of team members, 2 on Free, 3 on Builder, 5 on Team, 10 on Business, and additional users are $29 per user per month.

Does Cosmic support GraphQL?

No. Cosmic offers a REST API and a JavaScript/TypeScript SDK. Sanity and Strapi both offer GraphQL, so if GraphQL is a hard requirement, that is a real point in their favor.

Can I migrate off Strapi without rebuilding my front end?

Usually yes, if your front end talks to a content API through a thin data layer. We documented the process in Migrate from Strapi to Cosmic.

What if I am comparing against Contentful too?

We have those head to head as well: Sanity vs Contentful, Strapi vs Contentful, and the full field in our 2026 headless CMS comparison.

The honest summary

Pick Strapi if owning the runtime is worth the operational bill, and be realistic about who on your team pays that bill. Pick Sanity if you want a hosted content platform with a strong modeling story and a cheap seat, and budget for per-seat growth and quota add-ons. Pick Cosmic if you want managed infrastructure, a REST API with a TypeScript SDK, and AI in the editing workflow without a Studio to deploy or a Node app to patch.

You can test the third option in about ten minutes. Start building on Cosmic for free, no credit card required. If you are mid-evaluation and want a second opinion on your specific stack, book 20 minutes with our CEO.

Pricing and feature details for Sanity and Strapi were verified against their public pricing pages on August 5, 2026. Vendor pricing changes often, so confirm current terms before signing anything.

Which AI Model Should Generate Your CMS Content? A Practical Framework

Tony Spiro — Wed, 05 Aug 2026 22:02:08 +0000

If you landed here from a model comparison post, you already know the benchmark numbers. Reasoning scores, context windows, tokens per second, price per million. Useful data, and none of it answers the question you actually have: which model should I point at my content pipeline, and how do I wire it up so the output lands in production instead of in a Slack thread?

This post answers that. It is written for the person who has to ship the content.

The three-axis framework

Model choice for content work comes down to three axes. Score your use case on each one and the answer usually falls out.

Axis 1: Revision tolerance

How much editing are you willing to do per piece?

Low tolerance (publish with light proofing): you need the strongest available reasoning model. The cost delta per article is a rounding error next to an editor's hourly rate.
High tolerance (draft is a starting point, a human rewrites 40% of it): a faster, cheaper model wins. You are paying for a scaffold.

Most teams misjudge this axis. They buy the premium model and then rewrite everything anyway, or they buy the cheap model for content that goes out unedited.

Axis 2: Volume shape

Few pieces, high stakes (pillar pages, comparison pages, launch posts): premium model, long context, one call per piece.
Many pieces, low stakes (product descriptions, alt text, meta descriptions, category blurbs): cheap and fast model, batched.

A 2,000-product catalog needing meta descriptions is a completely different job from a 3,000-word technical guide, and it should not use the same model.

Axis 3: Structure requirements

This is the axis nobody mentions in benchmark roundups, and it is the one that breaks pipelines.

CMS content is a typed object: a title with a character limit, a slug, an SEO description under 155 characters, a body in markdown, a set of tags drawn from a fixed vocabulary, a relationship to an author object. If the model returns loose prose where your schema wants a 155-character string, your pipeline fails at the write step.

So the real question on this axis is: how reliably does the model produce output that conforms to a schema? Test that specifically. Give it your actual object type definition and ask for 20 objects. Count the ones that validate.

Score your use case

The three axes give you a tier, not a single model name. Cosmic's AI API groups models into three token-cost tiers, and the tier is the decision that matters for budgeting:

Budget, 1.0x multiplier: GPT-5 Nano, GPT-5 Mini, Claude Haiku 4.5
Standard, 2.0x multiplier: GPT-5, GPT-5.2, GPT-5.2 Codex, GPT-5.5, Claude Sonnet 4.6, Claude Sonnet 5, Claude Opus 4.7, Claude Opus 4.8, Gemini 3.1 Pro, Kimi K3
Premium, 4.0x multiplier: Claude Fable 5

Map the six common content jobs onto those tiers and you get a starting configuration:

Use case	Revision tolerance	Volume shape	Structure need	Tier to start with
Pillar / comparison pages	Low	Few, high stakes	Medium	Premium (4.0x)
Technical tutorials with code	Very low	Few, high stakes	Medium	Standard (2.0x), reasoning model
Product descriptions	High	Many, low stakes	High	Budget (1.0x)
Meta descriptions, alt text	High	Many, low stakes	Very high	Budget (1.0x)
Localization of existing copy	Medium	Many	High	Standard (2.0x)
Editorial first drafts	High	Medium	Low	Standard (2.0x)

Read the multipliers as relative cost, not absolute price. A Premium generation consumes four times the tokens of the same call on Budget, which is why running a 2,000-item catalog on the top tier gets expensive fast while a single pillar page on it costs almost nothing.

If you want the current head-to-head on the premium tier specifically, we broke it down in Claude Sonnet 5 vs Opus 5.

The part that actually determines whether this works

Model selection is maybe 20% of the outcome. The other 80% is the plumbing: where the generated content lands, whether it is reviewable before it goes live, and whether a human can fix it without a deploy.

Three requirements, in order of how often they get skipped:

1. Generated content must land as a draft. Any pipeline that writes straight to production is one bad generation away from an incident. Your CMS needs a draft state that the API can write to.

2. The schema must be enforced server-side. If your content model lets a 400-character string into a field meant for 155, the model's mistake becomes your search snippet. Validation belongs in the content model itself, where every write has to pass through it.

3. Editors need to fix output without touching code. This is the whole argument for a headless CMS in an AI pipeline. The model drafts, the API writes, and a human corrects it in a UI. Nobody should have to open a pull request to fix a typo.

For the full build, including grounding generations in a source document and streaming long outputs, see How to Build an AI Content Pipeline with Claude and a Headless CMS.

What this looks like in Cosmic

Generation and storage run through the same client, so the tier decision above is a parameter rather than an integration.

Generate

import { createBucketClient } from '@cosmicjs/sdk'

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

const { text, usage } = await cosmic.ai.generateText({
  prompt: `Write an SEO description under 155 characters for: ${product.name}`,
  max_tokens: 1024,
  model: 'claude-opus-5',
})

The model parameter is the entire switch. Moving product descriptions from Standard down to Budget, or a pillar page up to Premium, is an edit to one string. There is no second provider account, no separate invoice, and no per-vendor SDK to keep current. We argued that case at length in Why Your AI Stack Should Be Model-Agnostic.

Omit model and the API uses claude-opus-5. Other IDs you can pass include gemini-3.1-pro-preview, gpt-5.2-codex, and kimi-k3. The full list lives in the AI API docs.

Note the second value in the response. usage comes back on every call, so you can log real token counts per piece instead of estimating them from a price-per-million table.

Write

Generated content goes in as a draft, against a typed object with server-side validation.

// `generated` is whatever your model returned, already parsed
await cosmic.objects.insertOne({
  type: 'blog-posts',
  title: generated.title,
  slug: generated.slug,
  status: 'draft', // always review before publishing
  metadata: {
    seo_description: generated.seoDescription, // maxlength enforced on the metafield
    markdown_content: generated.body,
    author: authorObjectId,
  },
})

Two things to notice. status: 'draft' means an editor reviews every generation before it is public. And seo_description has a maxlength set on the metafield itself, so an over-long value is rejected at the API boundary instead of quietly shipping.

Reading it back for your frontend is the same SDK:

const { objects } = await cosmic.objects
  .find({ type: 'blog-posts', status: 'published' })
  .props('title,slug,metadata.seo_description,metadata.markdown_content')
  .limit(20)
  .sort('-created_at')

Cosmic exposes all of this over a REST API and the TypeScript SDK, so the pipeline is the same whether your model runs in a cron job, a serverless function, or an agent.

A cheap test before you commit

Before you standardize on a tier, run this. It takes an afternoon and it beats every benchmark chart.

Take 10 real pieces of content you have already published.
Write the prompt you would actually use in production, including your object schema.
Generate 10 replacements with each candidate model, changing only the model string between runs.
Count two numbers: how many validate against your schema on the first try, and how many minutes of editing each one needs to reach publishable.
Add up the real cost. Log usage from every call, then apply the tier multiplier: Budget 1.0x, Standard 2.0x, Premium 4.0x. That gives you measured token consumption per piece rather than an estimate. Multiply editing minutes by your loaded editorial rate and add the two figures together.

Pick the option with the cheapest total. That number predicts your real cost far better than a leaderboard position does.

The free plan includes 300,000 input and 300,000 output tokens per month, which is enough to run this entire comparison before you pay for anything.

Start building the pipeline

You can have both halves of this running against a real bucket today. Cosmic's free plan includes 1 Bucket, 2 team members, 1,000 objects, and the AI token allocation above, with no credit card required. Paid plans start at $49/month for Builder, and additional team members are $29/user/month. Full details on the pricing page.

Sign up for Cosmic free

Running a high-volume AI content pipeline and want to talk architecture? Book 20 minutes with Tony, our CEO. Cosmic is a YC W19 company and we have been doing API-first content since before it had a name.

Keep reading

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.