DEV Community: Studio1

Muse Wonder Review: Benchmarks, Pricing, and Access

Nancy Garg — Mon, 19 Oct 2026 15:35:58 +0000

TL;DR

Meta just released Muse Wonder and Muse Wonder Full, its first top-tier AI models. This post covers what they score, what they cost, who can use each one, and where Claude Opus 5.5 and GPT-6 Astra still come out ahead.

On the independent Artificial Analysis index, Muse Wonder Full scores 56, and Muse Wonder scores 52. Claude Opus 5.5 scores 58, and GPT-6 Astra scores 53.
Muse Wonder costs $4 per million input tokens and $20 per million output tokens on the API. Muse Wonder Full is not on the API at all. You only get it inside Muse Code plans that cost $50 or $200 a month.
Meta's own table shows the models leading on long coding projects, legal tasks, and memory. They trail on terminal work and from-scratch programming.

Meta spent most of 2026 shipping small, cheap models. On October 12, it changed lanes. Muse Wonder and Muse Wonder Full are bigger, pricier, and aimed straight at OpenAI and Anthropic.

Meta's scoreboard says they win a lot. The independent scoreboard says they get close. Both can be true, and the gap between the two is the part worth reading. Both models are also only a day old, so very few people outside Meta have used them for real work.

What is Muse Wonder?

Muse Wonder is a pair of AI models from Meta Superintelligence Labs, released on October 12, 2026. They are built to handle long, multi-step jobs for you, like fixing a big codebase, drafting a legal document, or planning something across several apps. Meta calls them its most capable models so far.

Here is what Meta says is new:

Active Memory. The model carries what matters about you from one chat to the next and brings it back when it is relevant to the task.
Active Focus. When a job gets hard, the model tries a different approach, recovers from mistakes, asks you a question if it is stuck, and checks in before doing anything important.
Wide input, text output. According to the model card, it accepts text, images, video, and audio, and replies in text.
Big memory per request. It can read up to 1 million tokens at once. That is roughly 750,000 words.
Closed weights. You cannot download either model, VentureBeat reports. Meta has not said whether it will open any Wonder model, per Axios. Its smaller Muse Glimmer model is open.

The models were trained at Meta's Prometheus data center in Ohio, according to TechCrunch. Axios adds that they went by the code name Watermelon before launch.

What is the difference between Muse Wonder and Muse Wonder Full?

Muse Wonder is the one you can build with today. Muse Wonder Full is the stronger one, but Meta only sells it through its coding app, Muse Code.

	Muse Wonder	Muse Wonder Full
Where you can use it	Meta Model API and Muse Code	Muse Code only
Price	$4 input and $20 output per 1M tokens	Included in $50 or $200 monthly plans
Pay-as-you-go API	Yes (model ID: muse-wonder-1.0)	No
Context size	1M tokens	1M tokens
Artificial Analysis score	52	56
Used to train Meta's models by default	No on the API, yes in Muse Code	Yes, until you switch it off

Meta also says Wonder will soon power more of the Muse chat app, rolling out first to paying subscribers.

How does Muse Wonder score on benchmarks?

A benchmark is a standard test. Every model takes the same exam, and a higher score is better. Because Meta wrote the launch table itself, we will start with the independent numbers and then look at Meta's.

What do outside testers say?

Artificial Analysis ran both models through its Intelligence Index, a mix of ten tests covering reasoning, knowledge, coding, and office-style tasks. The scores below are from VentureBeat's report.

Model	Artificial Analysis score
Claude Opus 5.5	58
Claude Sonnet 5.5	56
Muse Wonder Full	56
GPT-6 Astra	53
Gemini 4 Argon	53
Claude Fable 5.1	53
Muse Wonder	52

So Wonder Full lands in a tie for second. Plain Wonder, the one on the API, sits one point under GPT-6 Astra and six points under Opus 5.5.

What does Meta's own table say?

Meta compared both models with Claude Fable 5.1, GPT-6 Astra, and Claude Opus 5.5, all set to their highest effort. These are the rows that matter most, taken from Meta's model card and launch page.

By our count of Meta's full 14-row table, a Muse model holds the top score on 7 rows, Opus 5.5 on 6, and GPT-6 Astra on 1. Some of those wins are razor thin. JobBench is a 0.1-point loss for Wonder Full, and its Vals Finance Agent lead over Fable 5.1 is 0.2 points.

How much should you trust the table?

Three things to know before you quote it:

Meta picked the tests. Its model card says some competitor results were run by Meta itself on a best-effort basis, so the settings may not suit the other models.
Some tests cannot be rerun. Three of the scores come from Meta's internal tests (the Personal Superintelligence Index, MemoryBench, and FocusBench), according to Maccus. Nobody outside Meta can check them.
Not every row uses the same setup. On SWE-Marathon, the card says GPT-6 Astra and Fable 5.1 ran through their own coding tools, so it is not a fair side-by-side.

Meta also has history here. For Muse Spark 1.1, it reported 80 on Terminal-Bench 2.1, and an independent check came back at 76.2. Scores in a launch post tend to be the best case.

Even the strongest legal score needs context. Harvey LAB-AA counts a task as passed only when the result meets every requirement and has no made-up facts. A score of 13.1 means roughly one task in eight clears that bar. It is the best in the table, and it is still low.

How much does Muse Wonder cost?

Muse Wonder costs $4 per million input tokens and $20 per million output tokens on the Meta Model API. Cached input, which means text you send again and again, costs $0.20 per million. Those are the rates on Meta's own page.

A token is a small chunk of text, a bit shorter than a word. Input is what you send in. Output is what the model writes back.

Model	Input per 1M tokens	Output per 1M tokens
Muse Spark 1.3	$1.25	$4.25
Gemini 4 Argon (launch price)	$2	$10
Claude Sonnet 5.5	$2	$10
Muse Wonder	$4	$20
Claude Opus 5.5	$4	$20
GPT-6 Astra	$10	$50
Claude Fable 5.1	$10	$50

Prices are from VentureBeat's comparison. Argon's price goes to $4 and $20 after its launch period. Our Gemini 4 Argon review covers that in detail.

Two extra costs to know about. Web search through the API is $2.50 per 1,000 searches. And Meta caps each team at 3,000 requests and 4 million tokens a minute.

What does it cost per task?

The price per token does not tell you the bill. What matters is how many tokens a model uses to finish a job. Artificial Analysis measured the cost of its average test task:

Muse Wonder: $4.52
Claude Opus 5.5: $5.98
GPT-6 Astra: $3.26

Wonder is cheaper than Opus 5.5 here because it writes less. One report on Artificial Analysis data puts it at about 130 million output tokens for Wonder against 260 million for Opus 5.5. The same report says Wonder takes 19.27 seconds to start answering, compared with a 5.52 second median. That makes it a poor fit for anything where a person is waiting on screen.

How do you get access to Muse Wonder?

There are three ways in right now.

The Meta Model API. Sign up at dev.meta.ai and call muse-wonder-1.0. Meta says you can point an existing OpenAI-style client at it, so testing it in an app you already have should be quick.
Muse Code. This is Meta's coding assistant for the terminal. The Power Usage plan is $50 a month and gives 20 times the usage of the Everyday plan. The Maximum Usage plan is $200 a month and gives 80 times. Both include Muse Wonder Full.
The Muse app. Meta says Wonder is coming to it soon, starting with paid subscribers.

There is no free tier for Wonder Full, and there are no downloadable weights for either model.

Does Meta train on your data?

It depends on where you use the model. This is the part of the launch that is easiest to miss.

On the API, Muse Wonder runs in Standard mode, where Meta says your content is not used for training. Muse Code subscriptions default to Contributor mode instead. In that mode, Meta can use your prompts, code, files, and the replies to train future models. You can switch it off, but only for what you send afterward. The details are in VentureBeat's report and Meta's own subscription terms.

If you work with client code, check that setting before you paste in a single file. Companies with strict rules can also ask Meta about zero data retention. It comes with trade-offs, like no file uploads and no built-in web search.

Where does Muse Wonder still fall short?

Terminal work. On Terminal-Bench 4.0-AA, Wonder Full scores 57.1 against 59.6 for Opus 5.5 and 59.1 for GPT-6 Astra. Plain Wonder scores 52.0.
Building from scratch. On ProgramBench, Opus 5.5 scores 70.5. Wonder Full scores 59.0.
Health questions. Opus 5.5 and GPT-6 Astra both beat Wonder Full on HealthBench Pro.
Facts from memory. On Artificial Analysis's AA-Omniscience test, reported by IJR, Wonder Full scores 30 and Wonder scores 25. Opus 5.5 scores 46, GPT-6 Astra 43, and Gemini 4 Argon 42.
Speed to first word. Covered above. It is slow to start.
Known weak spots. Meta's model card says 3D and spatial reasoning is still a limit. It also says the models can slip on multi-step jobs in unfamiliar situations, and that they are not meant for anyone under 18.
Safety report. Meta says a full safety report is coming "soon." The model card says that without extra safeguards, Meta cannot rule out the model reaching its high-risk level for chemical and biological topics. So safeguards are switched on, and they may refuse some legitimate science requests.

What should you check before you switch?

Do not switch on a headline number. Here is a short checklist:

Test on your own work. Pull 20 real tasks from your own repo, docs, or inbox. Run them through your current model and through Muse Wonder.
Log the cost per task. The token price is the same as Opus 5.5, so the saving only shows up if Wonder really writes less on your work.
Time the first answer. If a person waits on the result, 19 seconds is a long wait.
Pick the right door. Use the API for work code. Only use Muse Code with Contributor mode off, or for code you do not mind sharing.
Wait if you are regulated. If you work in health, law, or finance, hold off for the full safety report.

Which should you pick: Muse Wonder, Claude Opus 5.5, or GPT-6 Astra?

There is no single winner. The independent scores point to this split:

Pick Muse Wonder if you run very long coding jobs or legal-style drafts, and you want Opus-level token prices with fewer tokens used. Our Claude Opus 5.5 review has the other side of that comparison.
Pick Claude Opus 5.5 if you want the highest overall score, strong from-scratch programming, and faster first answers.
Pick GPT-6 Astra if cost per task and terminal work matter most, and you can live with a higher token price.

Frequently asked questions

What is Muse Wonder?

Muse Wonder is Meta's new AI model for long, multi-step work such as coding, legal drafting, and personal planning. It launched on October 12, 2026, alongside a stronger version called Muse Wonder Full.

Is Muse Wonder free?

No. The API costs $4 per million input tokens and $20 per million output tokens. Muse Wonder Full needs a Muse Code plan at $50 or $200 a month. Meta says the Muse app will get Wonder first for paying subscribers.

Is Muse Wonder open source?

No. Neither Wonder model has downloadable weights. Meta has not said whether it will open any of them. Its smaller Muse Glimmer model is open.

Is Muse Wonder better than Claude Opus 5.5?

Not overall. Artificial Analysis scores Opus 5.5 at 58, Muse Wonder Full at 56, and Muse Wonder at 52. Meta's table shows Wonder ahead on long coding and legal tests, and Opus 5.5 ahead on terminal work and building programs from scratch.

Can I use Muse Wonder Full through the API?

No. Muse Wonder Full is only available inside Muse Code on the $50 and $200 plans. The API serves plain Muse Wonder.

How big is the context window?

Both models can read up to 1 million tokens in one request, which is roughly 750,000 words.

Can Muse Wonder handle images, audio, and video?

Yes for input. It accepts text, images, audio, and video. It only replies in text.

Does Meta use my data to train Muse Wonder?

Not on the API, where Standard mode applies. Muse Code defaults to Contributor mode, which lets Meta train on what you submit. You can switch it off for future messages.

DevRel Agency vs In-House DevRel Hire: Costs, Timelines, and When Each One Makes Sense

Nancy Garg — Sat, 17 Oct 2026 16:55:54 +0000

TL;DR

An illustrative US hiring scenario comes to about $195,000 annually, assuming a $136,300 base salary and benefits equal to 30% of total compensation. This is not a verified DevRel salary average.
SaaSHero estimates DevRel agency retainers at $8,000–$28,000 per month. Actual quotes depend on scope, staffing, and contract terms.
An in-house hire suits ongoing ownership and close product collaboration. An agency can provide specialist expertise and additional execution capacity.
A hybrid setup combines an internal owner with external support for agreed projects or ongoing work.

Stack Overflow's 2025 survey found that 84% of developers use or plan to use AI tools, up from 76% the year before. The same survey found that 46% of developers do not trust what those tools tell them, up from 31%. These findings show a gap between AI adoption and trust in its accuracy. They do not establish how often developers check original sources.

That changes what you need from developer relations. Someone has to make your docs, tutorials, and community answers good enough to be quoted, and good enough to survive a double-check. The question is who that someone should be: a person on your payroll, or an agency on a retainer.

This guide compares the cost and timeline of each option, and tells you when to pick which.

What do the numbers look like side by side?

Factor	In-house hire	DevRel agency
Annual cost	Illustrative US scenario: about $195,000 in salary and benefits	$96,000 to $180,000 at $8,000 to $15,000 a month
Additional costs	Recruitment, travel, events, tools and program expenses	Onboarding, travel, tools and out-of-scope work, depending on the contract
Time to start	Allow for recruitment, notice period and onboarding	Depends on team availability and onboarding requirements
Commitment	Ongoing employment	Monthly, project-based or longer-term agreements
Best fit	Dedicated ownership and close product collaboration	Specialist support, defined projects and additional capacity

These figures are budgeting references, not equivalent service packages. Compare the responsibilities, hours, and deliverables included in each option.

How much does an in-house DevRel hire cost?

Salary data for DevRel is messy. Titles overlap, and some sources report base pay while others report total pay. Here is what the main ones say.

Source	Role	Reported pay
Payscale	DevRel manager	$100,000 average base, middle half between $64,000 and $148,000
Refonte Learning	Developer advocate	About $136,300 average, senior about $171,300
Refonte Learning	Developer relations engineer	About $143,000 average, senior about $170,200
SkillScouter	Mid-level developer advocate	$135,000 to $180,000 total pay
Jobrise	DevRel manager (US)	$150,000 to $230,000 base
Jobrise	Head of DevRel (US)	$190,000 to $300,000 or more base

For the math below, we use $136,300, the average for a developer advocate. If your market pays less, scale the numbers down.

The salary is not the real cost

The US Bureau of Labor Statistics says that in June 2026, wages were 70% of what private employers spend on a worker, and benefits were the other 30%. That puts benefits at roughly 43% on top of salary.

Mid-level advocate: $136,300 in salary becomes about $195,000 a year.
Senior advocate: $171,300 in salary becomes about $245,000 a year.

Then come the extras:

Recruiter fees. 15 to 25% of first-year pay is common for agency placements. On $136,300, that is roughly $20,000 to $34,000.
A program budget. Events, travel, swag, community tools, and hosting for demos.
Gaps. One person has one set of strengths and one calendar. If they quit, the hiring clock starts over.

How much does a DevRel agency cost?

Agency pricing is just as scattered. Here are the ranges:

Type of help	Monthly price	Typical contract	Source
Solo DevRel consultant	$2,000 for 5 hours a month, or $3,000 for a one-time audit	Monthly	Yalla DevRel
One defined problem (content, docs or DevRel)	From $5,000	Fixed scope and deadline	Hackmamba
Technical content retainer	From $8,000 a month	Most clients start with a 3-month pilot	Draft.dev
One-channel retainer (content, SEO or DevRel)	$8,000 to $20,000	3 to 6 months	MarketerHire
Several workstreams at once (content, docs, DevRel, paid media)	From $15,000 a month	Month to month, or a longer contract	Hackmamba
Multi-channel growth retainer	$25,000 to $50,000	6 to 12 months	MarketerHire

A fair warning. These prices come from companies that sell the service, so treat them as ballparks and get your own quotes. At Studio1, we do not publish a price list, so we are not in the table. We start with an audit of your existing developer programs, then scope the work. If you want to see what that looks like for your product, you can book a call with us.

What does the quote usually leave out?

Two things often sit outside the retainer. MarketerHire's devtools guide lists paid channel spend of $5,000 to $30,000 a month and conference sponsorships of $10,000 to $50,000 per event as separate costs. And most agencies start with a trial or a minimum term. Draft.dev says most clients begin with a 3-month pilot, and Infrasity asks for a 3- to 6-month minimum.

Ask what is excluded before you sign. Ask whether the person you meet on the sales call is the person who does the work.

Where is the break-even?

One fully loaded advocate at $195,000 a year works out to about $16,200 a month. If an agency retainer stays under that, year one is cheaper than hiring. Above it, you are paying more than a hire for what is often a shorter, narrower commitment.

How do a DevRel agency and an in-house hire compare?

Factor	In-house hire	DevRel agency
First-year cost	About $195,000 plus extras	$96,000 to $180,000 at the starting prices above, plus any paid channels and events
Time to start	Months	Weeks
Product knowledge	Deep, and it grows	Shallow at first, depends on your briefing
Output volume	One person's capacity	A team's capacity, if the right people are on your account
Community trust	Strong, people get to know a real face	Weaker, since people can tell when a voice is borrowed
Flexibility	Hard to scale down	Easy to pause or stop at contract end
Risk if it fails	Costly, slow exit	Limited to the contract length
Product feedback	Goes straight to your team	Needs a deliberate process
Best fit	Sustained ownership, close product collaboration and ongoing community work.	Additional expertise, defined projects, launches or support while building an internal team.

How long until each option starts working?

Nobody publishes a clean time-to-hire number for DevRel roles, so we use engineering hiring data, which is the closest match. Sourced numbers are linked. The rest are our own estimates and are marked.

In-house timeline

Write the role and get it approved: 1 to 2 weeks.
Hire: about 9 weeks. Proxify reports 62 days as the global average for engineering roles. Recruiting from Scratch says 47 days from opening a role to an accepted offer for senior engineers.
Notice period: two weeks is the usual custom in the US. In India, 60 to 90 days is common at tech companies.
Learning your product: 2 to 4 weeks.
First public work: depends on what you focus on. A docs fix or a tutorial can go live in the first few weeks, while community and event work takes longer.
Results you can measure: often 3 to 6 months out. Stackmatix says to expect roughly one to two quarters before meaningful activation results appear.

Agency timeline

Kickoff and audit: 2 to 4 weeks. Ask for dates in writing.
First content live: within 1 to 2 weeks of kickoff. Infrasity lists 7 days for a technical video.
Early signals: around 90 days. Stateshift says most programs show early impact within 90 days if you track the right things, such as how many people finish a quickstart.
Community trust: longer. An agency can ship tutorials fast, but trust in a community still builds slowly.

When does an in-house DevRel hire make sense?

Hire in-house when most of these are true:

Your product is complex and changes often. Someone has to sit in engineering conversations and understand why things work the way they do.
You have a real community to look after. A Discord, a GitHub project, or a forum needs someone who shows up every day.
You can wait 3 to 6 months for proof. Set early milestones for onboarding and delivery, alongside longer-term goals for adoption and community development.
You can protect a budget line. A person with no budget has little to work with and is easy to cut.
You want developer feedback to reach your product team. An employee can participate directly in product planning. External practitioners need agreed access and a clear feedback process.

When does a DevRel agency make sense?

An agency is the better choice when:

You need docs, tutorials, or comparison pages in weeks. Waiting for a hire means waiting for the content too.
You are not sure DevRel will work for you. A 3- to 6-month contract is a cheaper experiment than a $195,000 hire.
You have a short push. A launch, a new SDK, a hackathon.
You cannot find or afford a senior person. In the Draft.dev 2026 developer marketing survey, 42% of teams said they outsource content creation.
You want steady routine work done well. Checking docs for gaps, refreshing old posts, tracking what AI tools say about you.

Agencies have weak spots too. They do not know your product the way an employee does, and some put junior staff on your account after a senior pitch. MarketerHire argues that one senior fractional hire can beat an agency that spreads junior people across your work.

Can you use both?

Yes, and this is where many teams land. One person inside the company owns strategy, community, and product feedback. An agency handles production: tutorials, docs fixes, sample apps, and comparison pages.

Agencies sell this setup too. Hackmamba, for example, offers a marketing leader from $10,000 a month to set strategy, priorities, and reporting for your existing team. We agree with the idea. The person who knows your product decides what to make. The agency makes more of it, faster. At Studio1, we work as an embedded partner for product teams, handling docs, tutorials, open-source upkeep, and community replies.

How does AI search change the decision?

A developer who used to search Google for "best error tracking tool for Rails" now often asks ChatGPT, Claude, or Gemini and reads one answer. HackerNoon's dev tool checklist describes the moment when that answer names your competitor and not you. Getting named inside the answer is called answer engine optimization, or AEO.

A few facts worth knowing:

Sourced, specific writing gets picked up more. Researchers from Princeton, Georgia Tech, and IIT Delhi found that adding citations, quotes from credible sources, and statistics raised a page's visibility in AI answers by up to 40%. That is a lab result, not a promise for your site.
Each AI tool answers differently. One agency's research found only 12% of citations overlap across ChatGPT, Perplexity, Gemini, and Claude. Check each one yourself.
Answers change between asks. The same question can produce a different answer an hour later, so be wary of anyone who guarantees a ChatGPT ranking.
Search itself is shifting. In 2024, Gartner predicted that traditional search volume would fall 25% by 2026 as people move to AI chatbots. We have not seen a final measurement, so treat it as a prediction.
A plain-text docs file may help coding tools. The HackerNoon checklist says Google does not use llms.txt and most of those files see no crawler traffic, but it is still worth shipping for developer docs.

Most AEO work for developer tools comes down to three jobs:

Clear docs, comparison pages, and tutorials on your own site, with real numbers and sources. An agency can produce a lot of this quickly.
Honest answers where developers already talk, like GitHub, Reddit, and community forums. This needs real credibility, which leans toward an in-house hire.
Regular checks on what each AI tool says about you, then fixing the gaps. A junior teammate or an agency can own this.

So AEO does not push you hard in either direction. It makes the hybrid setup more attractive.

Which option fits your stage?

These are our opinions, built on the cost data above.

Pre-seed or seed

Budget: About $2,000 to $5,000 a month for part-time help.
Best fit: A solo DevRel consultant or a small content retainer. Jozu was at an early stage when we started working with them in October 2024. We began with developer content, community work, and events for their open-source project, KitOps, and kept going for just over a year. You can read the Jozu case study.
First 90 days: Fix your quickstart, write five tutorials that answer real questions, and check what AI tools say about you.

Series A

Budget: One hire at about $195,000 a year, or a retainer of $8,000 to $15,000 a month.
Best fit: An agency if you need output now. A first hire if you already have a community and a clear owner.
First 90 days: Pick one number to move, such as how many new signups make their first successful API call. Check it every week and fix the step where most people drop off.

Series B and later

Budget: An in-house lead plus a retainer in the $8,000 to $15,000 range, more if several channels are involved.
Best fit: The hybrid model.
First 90 days: Set up reporting that ties DevRel work to signups and revenue, so the program survives the next budget round.

Open source projects

Budget: Usually small, often tied to a company sponsor.
Best fit: Someone in-house who is already part of the project. Bring in an agency only for docs or specific pushes. We help open source teams with this kind of work. Our Memori case study covers a launch that went from 0 to 12,000+ GitHub stars, and our Corsair case study covers developer experience, demos, and community growth.
First 90 days: Cut the time it takes a new contributor to get a first pull request merged.

What mistakes do teams make when choosing?

Hiring before defining success. In the 2024 State of Developer Relations survey, 33.5% of practitioners could not state their pro gram budget, and another 17.8% had no set budget. A role with no goal and no budget is the first one cut.
Judging too early. Reviewing a new hire at month three punishes the work that pays off at month nine.
Counting vanity numbers. Followers and page views look good and prove little. Quickstart completions and signups are harder to fake.
Signing a long agency contract with no exit. Ask what leaving after three months costs.
Giving an agency nobody to talk to. Without an internal owner, the agency guesses at your product, and the work shows it.
Treating DevRel as a support desk. Answering tickets matters, but it is not a strategy.

What should you ask before you sign or hire?

If you are choosing an agency:

What proof do you have from a company like mine? Ask for numbers you can check.
What is not in the monthly price? Get the exclusions in writing.
Who owns the content and code when we stop? Settle this before the first invoice.

If you are hiring a person:

Can they write and code? Many are strong at only one.
Can they build a community and create content? Developers expect good docs, tutorials, and quick replies on Discord or GitHub. Ask to see examples of each.
Have they built something developers still use? A public track record beats a polished resume.
What budget and goals do they get in writing? And does their manager understand the job?

Frequently asked questions

How much does a DevRel agency cost?

Pricing depends on scope, seniority, and allocated capacity. SaaSHero estimates DevRel agency retainers at $8,000–$28,000 per month, but this is a vendor estimate rather than an industry-wide average. Get a quote that specifies deliverables, exclusions, and contract terms.

How much does it cost to hire a developer advocate?

Costs vary by location, experience, and responsibilities. In our illustrative US scenario, a $136,300 base salary becomes approximately $194,700 when applying the BLS private-industry compensation ratio. This is a budgeting example, not a verified average. Recruitment and program expenses are additional.

Is a DevRel agency cheaper than hiring in-house?

It can be, depending on scope and total costs. Our illustrative $195,000 hiring scenario equals $16,250 per month before recruitment and program expenses. Compare this with the agency’s total cost over the same period, including excluded expenses and internal oversight.

How long does it take to see results from DevRel?

Timelines depend on the product, starting point, and goals. Use the first 90 days to assess delivery, onboarding improvements, and initial developer responses. Set separate milestones for longer-term outcomes such as retention, community participation, and revenue contribution.

Can an agency replace a Head of DevRel?

An agency or fractional leader can provide strategy, program leadership, and product-feedback coordination if those responsibilities are included in the engagement. Your company still needs an accountable decision-maker for priorities, budget, and internal access.

Does DevRel help your product show up in ChatGPT and Claude answers?

Yes, indirectly. Clear docs, honest comparisons, sourced numbers, and real answers in developer communities give AI tools better material to quote. Nobody can promise a specific ranking, because AI answers change from one ask to the next.

How to Measure Your Devtool's Visibility in AI Answers

Nancy Garg — Thu, 15 Oct 2026 19:53:08 +0000

TL;DR

You can find out how often AI tools recommend your devtool with a free spreadsheet audit that takes about two hours. You don't need paid software or code.

Write 12 questions a developer would really ask about your category, then ask each one three times in three AI tools. That gives you 108 answers to count.
Count five things: how often you're named, how often you're in the first three, your share of all brand mentions, how often you're linked, and how often the AI gets you wrong.
Ignore your exact position in the list. AI tools almost never give the same list twice, so position is mostly noise.
Fix your biggest gap first, then run the same audit again next month.

A lot of developers now ask an AI before they ask Google. JetBrains surveyed more than 10,000 professional developers in January 2026 and found that 90% regularly used at least one AI tool at work. Stack Overflow's 2026 survey, with more than 30,000 responses from 169 countries, found that only 17.2% of developers don't use AI tools. Its own history shows how fast that happened: 44% used AI tools in 2023, 62% in 2024, and 79% in 2025.

When one of those developers asks which tool to use, they don't get ten blue links. They get a short list of names. If yours isn't on it, they never see your docs, your pricing page or your launch post. And once the answer is on the page, fewer people click through. Pew Research tracked 900 US adults and found that in regular Google search, users clicked a result link in 8% of visits when an AI summary appeared, versus 15% when it didn't. That's general search, not developer search, but the direction is clear.

Most devtool teams have no idea whether this is happening to them. Dashboards show traffic, GitHub stars, and signups. None of them show what an AI says when someone asks about your category. This guide gives you a simple way to find out.

What is AEO for developers?

Answer engine optimization, or AEO, is the work of making your product easy for AI tools like ChatGPT, Claude, Gemini, Perplexity, and Google's AI Overviews to find, understand, and name when someone asks a question. You'll also see it called GEO or LLM SEO. They all mean roughly the same thing.

For devtools, that mostly means clear docs, honest comparison pages, consistent facts and a real presence in the places developers talk. But you can't fix what you haven't looked at, so measuring comes first. That's what this guide covers.

If you want the full fix list after your audit, Studio1 has a separate guide on how to get your tool recommended by ChatGPT, Perplexity, and Google.

Why can't you check AI answers just once?

You might be tempted to ask ChatGPT one question, see your name, and call it a day. Don't.

SparkToro and Gumshoe.ai had 600 volunteers run 12 prompts through ChatGPT, Claude, and Google's AI nearly 3,000 times. The odds of getting the same list of brands twice were under 1 in 100, and the odds of the same order were closer to 1 in 1,000. Two fair warnings: the study wasn't peer-reviewed, and Gumshoe sells AI tracking. Still, it matches what you'll see yourself in ten minutes of testing.

The useful part is what stayed steady. The three most mentioned brands in each category showed up in about 64% of ChatGPT answers, 73% of Claude answers, and 68% of Google AI answers. The order bounces around, but the same names keep coming back. That gives us the rule for this whole audit: count how often you appear, not where you appear.

The tools also disagree with each other. Ahrefs found that Google's AI Mode and AI Overviews cite different sources 87% of the time for the same query. A BrightEdge analysis found the overlap between the sources two engines cite can be as low as 16%. So a good score in one tool tells you very little about another. Test each one on its own.

They also read different places. Profound looked at 30 million citations between August 2024 and June 2025:

Engine	What it leaned on most
ChatGPT	Wikipedia, at nearly 48% of its top citations
Perplexity	Reddit, at almost half of its citations
Google AI Overviews	Reddit (21%), then YouTube (18.8%), Quora (14.3%) and LinkedIn (13%)

Source: Profound study, as reported by The Daily Star. That data is more than a year old, so don't treat the exact percentages as current. The pattern is the point: your docs are not the only thing these tools read about you.

How to audit your devtool's AI visibility: a 5 step playbook

Here's what you need before you start:

A spreadsheet.
Free or paid access to ChatGPT, Gemini, and Perplexity. Add Claude if you want a fourth. Free tiers are fine, but note which plan you used, since answers can differ.
About two hours. That's my estimate for 108 answers at roughly a minute each.
Optional: a teammate who runs the same list, so you can compare notes.

Set up each tool the same way. Open a fresh chat for every prompt. If the tool has a memory or personalization setting, turn it off so your past chats about your own product don't tilt the answer. If web search is optional, turn it on, because that's how most people get current answers. Write down the date and the tool name in your sheet.

1. Write 12 prompts developers would actually type

Sort them into four buckets, three prompts each. This follows the category, comparison, validation, and branded split that audit teams like Percepture use.

Bucket	Template	Example for a job queue library
Discover	What's the best [category] for [language or framework]?	What's the best job queue for Node.js?
Discover	Which [category] should a small team use for [use case]?	Which job queue should a small team use for email sending?
Discover	I need to [job to be done]. What tools can I use?	I need to retry failed background tasks. What tools can I use?
Compare	[Your tool] vs [competitor]: which is better for [use case]?	Acme Queue vs BullMQ: which is better for scheduled jobs?
Compare	What are good alternatives to [competitor]?	What are good alternatives to BullMQ?
Compare	[Category] tools compared: pros and cons	Node.js job queues compared: pros and cons
How-to	How do I [task] with [framework]?	How do I retry failed jobs with Express?
How-to	What's the easiest way to [task] without [pain]?	What's the easiest way to run cron jobs without a separate server?
How-to	Show me an example of [task] in [language]	Show me an example of a delayed job in TypeScript
Check	Is [your tool] good for [use case]?	Is Acme Queue good for high volume?
Check	What are the downsides of [your tool]?	What are the downsides of Acme Queue?
Check	How much does [your tool] cost, and is there a free plan?	How much does Acme Queue cost?

A few tips:

Write like a person talks. Pew found that longer searches and searches phrased as questions or full sentences trigger AI summaries more often.
Spend your effort on Discover and How-to. That's where someone hasn't picked a tool yet. Check prompts mostly test whether the AI describes you correctly.
Swap the placeholders for your real category, languages, and rivals. The same template works for any devtool, and it makes it easy to repeat the audit for each language or framework you support.

2. Run every prompt three times in three tools

That's 12 prompts × 3 tools × 3 runs = 108 answers. Set up one row per answer with these columns:

Date
Tool
Prompt and bucket
Run number (1, 2, or 3)
Mentioned? (yes or no)
In the first three names? (yes or no)
Linked to your site, docs, or repo? (yes or no)
Competitors named
Anything wrong? (pricing, features, versions, supported languages)
Notes

Why three runs? The SparkToro team ran each prompt 60 to 100 times, and they said it's still an open question how many runs are enough to get reliable data. Three is a floor, not a science. If you have the energy for five, do five. They also left open whether results from an API match what you see in the chat window, so run these by hand in the apps your customers use.

Paste each answer into a second tab as you go. You'll want to reread a few of them later.

3. Score the answers

You only need five numbers.

Mention rate. Answers that name you, divided by all answers.
Top-three rate. Answers where you're among the first three names, divided by all answers. HubSpot's guide calls this recommendation rate.
Share of voice. Your mentions divided by every brand mention in all the answers, yours and your rivals combined. Triple Whale gives the same formula: your mentions ÷ total category mentions. Think of it as your slice of the pie.
Link rate. Answers that link to your own site, docs, or repo, divided by all answers. This matters because 78.7% of developers say source attribution matters when they judge an AI answer, and only 6.6% would trust AI with an important decision.
Accuracy. How many of the answers that name you get something wrong?

Calculate each one per tool and per bucket, not just overall. The overall number hides the useful stuff.

A note on position: skip it. If you came here wanting to know whether you're “number two” in ChatGPT, the research says that number is close to meaningless, because the order shuffles on almost every run.

A worked example with made-up numbers. Here's what a finished audit might look like for Acme Queue, a pretend job queue library. These numbers are invented to show the math.

Tool	Answers	Mentioned	Mention rate
ChatGPT	36	12	33%
Perplexity	36	9	25%
Gemini	36	6	17%
All three	108	27	25%

Acme Queue was in the first three names in 14 answers (13%), linked in 9 (8%), and got something wrong in 4 of the 27 answers that named it (15%). Across all 108 answers, there were 270 brand mentions in total, so its share of voice was 27 ÷ 270 = 10%.

Now split it into buckets. Each bucket has 27 answers.

Bucket	Mentioned	Mention rate
Discover	3	11%
Compare	8	30%
How-to	4	15%
Check	12	44%

That's a very common shape. People who already know the product get a decent answer. People who don't know it basically never meet it. The fix for that is different from the fix for wrong facts, which is why the bucket split matters.

4. Read the results

What you see	What it probably means	Your first move
Rarely named, even in Check prompts	The AI barely knows you exist	Get your product described in more places: your docs, comparison pages, community threads
Named when asked by name, missing in Discover prompts	People who know you find you, strangers don't	Publish pages that match category questions, and earn mentions on third-party sites
Named, but details are wrong	Old or conflicting info is out there	Fix your docs, pricing page and changelog first, then the outdated third-party posts
Rivals win the Compare prompts	Nobody has written your side of the comparison	Publish an honest comparison page and join the comparison threads
Named, but the link goes to a forum or blog, not you	The AI trusts other people's write-ups more than yours	Put a clear, direct answer at the top of the matching docs page
Strong in one tool, weak in another	Normal, because they read different sources	Look at what the strong tool cites and learn from it

When a tool shows its sources, click through them. That list is a to-do list. It tells you which pages the AI trusts on your topic, and whether you're on them.

5. Fix the biggest gap first

Pick one gap and work on it for a month. Here's the short version of what to do next.

Let the right bots in. AI tools can only use what their crawlers (the bots that read websites) can reach. OpenAI says its OAI-SearchBot is for search and isn't used to train its models, while GPTBot is used for training, and each is controlled separately in robots.txt. OpenAI recommends allowing OAI-SearchBot if you want to appear in ChatGPT search, and says changes can take about 24 hours to show up. Your robots.txt file is a small text file at the root of your site. A simple version looks like this:

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

Whether to allow training crawlers like GPTBot is a separate decision, and it's yours. Other companies publish their own bot names too, and they change, so check each one's docs. This crawler guide is a decent starting list. Also check your hosting firewall or bot protection, since those can block unfamiliar bots even when robots.txt says yes.

Answer the question in the first lines of the page. If someone asks, “How do I retry failed jobs in Express?”, your docs page should open with that answer and a short code sample, before any backstory. One analysis of Perplexity found that for technical questions, its citations lean toward official documentation, GitHub issue threads, and posts from the engineers behind the tools. That's one source, so treat it as a hint, but it fits the Profound data above.

Publish an honest comparison page. Say who your tool is great for and who should pick something else. Pages like that are easy for an AI to quote and easy for a developer to trust.

Show up where developers already talk. Given how much Reddit, YouTube, and community content the tools lean on, a helpful answer in a real thread can matter more than another blog post. Be honest about who you are, and answer the actual question.

Keep your facts consistent and dated. Pricing, versions, supported languages, and limits should match on your site, your docs, your repo README and your changelog.

Re-run the audit every month. Same prompts, same sheet. Because answers shift from run to run, a change of a few points is probably noise. Look for movement that holds for two or three months. That last bit is my advice, not a research finding.

For the full playbook on each of these, read Studio1's guide on getting your tool recommended by ChatGPT, Perplexity, and Google.

What mistakes ruin an AI visibility audit?

Only testing prompts with your name in them. You'll feel great and learn nothing.
Running each prompt once. One answer is a coin flip.
Using your logged-in chat with years of history. Your past conversations can tilt the answer.
Blending all tools into one number. Keep a score for each tool.
Chasing position. Count appearances instead.
Ignoring accuracy. Being named with the wrong price or an old API is sometimes worse than not being named.

Frequently asked questions

What is AEO for developers?

AEO, short for answer engine optimization, is the work of making sure AI tools like ChatGPT, Claude, Gemini, and Perplexity find, understand, and recommend your developer product. For devtools, that mostly means clear docs, honest comparisons, consistent facts, and a real presence in the communities developers use.

How do I check whether ChatGPT recommends my devtool?

Write 12 questions a developer would ask about your category, ask each one three times in a fresh chat, and count how often you're named. The playbook above walks through it, and the whole thing takes about two hours.

How many times should I run each prompt?

At least three. Researchers who ran prompts 60 to 100 times saw almost no two answers match, and nobody has settled on how many runs are enough. More runs give you steadier numbers.

Should I track my position in the list?

No. In SparkToro's study, the same list in the same order came up closer to 1 time in 1,000. Track how often you appear instead.

Do I need a paid AI visibility tool?

Not to start. A spreadsheet is enough for a first baseline. Paid tools save time later by running prompts on a schedule, but ask any vendor how many times they run each prompt before they report a number.

How often should I re-run the audit?

Monthly works well for most small teams. Keep the prompts the same so the numbers are comparable.

Should I block GPTBot?

That's a separate choice from showing up in ChatGPT search. Per OpenAI's docs, GPTBot is used for training, and OAI-SearchBot is used for search, and you can allow one and block the other.

llms.txt Explained: What It Is, Whether Developer Tools Need One, and a Template

Nancy Garg — Mon, 12 Oct 2026 12:32:01 +0000

TL;DR

llms.txt is a plain Markdown file that tells AI tools what to do and which pages matter most. Jeremy Howard proposed it in September 2024. It's a community proposal, not an official standard.
It won't get you recommended. Google says its search ignores it, a study of about 300,000 domains found no link to AI citations, and Ahrefs found 97% of files got zero requests in May 2026.
Developer tools should still add one to their docs. It takes about an hour; developers do point coding assistants at these files, and Chrome's Lighthouse now checks for one.

A developer pastes your docs link into a coding assistant and says, "set this up for me." The assistant has to dig the useful text out of menus, scripts, and banners. Sometimes it grabs an old page and writes code for a version you retired two years ago. llms.txt tries to fix that.

It's cheap, it's useful in one specific place, and it won't do what most blog posts promise. For the bigger picture, see our guide on how to get your tool recommended by ChatGPT, Perplexity, and Google. This post goes deep on one file.

What is llms.txt?

llms.txt is a Markdown file at /llms.txt on your website. It gives AI tools a short description of your product and a hand-picked list of links, each with a one-line note. Think of it as a table of contents written for software.

Jeremy Howard, co-founder of Answer.AI and fast.ai, proposed it on September 3, 2024, and published a rewrite (v2) in August 2026. The AI labs use it too: the spec points to llms.txt files for the developer docs of OpenAI, Anthropic, and Gemini.

Why it exists: web pages are built for people, so an AI tool gets the content plus a pile of layout code. A short index with links to clean pages saves it time.

Version 2 changed three things:

Links should point to Markdown pages. A page at /docs/api can have a plain-text twin at /docs/api.md (or page.html.md).
Pages can point to their llms.txt. Use link tags or an HTTP header: rel="alternate" type="text/markdown" for the Markdown copy, rel="describedby" for the llms.txt.
A file can live in a subfolder. /docs/llms.txt covers everything under /docs/, and the most specific file wins.

What does an llms.txt file look like?

According to the spec, a file has these parts, in this order:

An H1 with your project or site name. The only required part.
A blockquote with a short summary of the key facts.
Optional paragraphs or lists (no headings) with extra detail.
Optional H2 sections, each a list of links: [Name](url): short note.

By convention, a section called Optional holds links a tool can skip when short on room. The smallest useful version:

# ExampleDB

> ExampleDB is a hosted Postgres database for small teams.

## Docs

- [Quickstart](https://docs.exampledb.com/quickstart.md): Create a project and run a first query.

No special syntax, nothing to install.

llms.txt vs robots.txt vs sitemap.xml: what's the difference?

They do different jobs. llms.txt replaces neither of the others.

File	What it does	Who reads it	Can it block anyone?
robots.txt	Says which bots may visit which pages	Search and AI crawlers	Yes, if the bot follows the rules
sitemap.xml	Lists every page you want indexed	Search engines	No
llms.txt	A short, curated guide to your best pages	AI tools and coding assistants, when they choose to fetch it	No

A sitemap lists everything and is usually too big for an AI tool to read in one go. The spec calls llms.txt a curated overview. To keep a bot out, use robots.txt.

Does AI actually read llms.txt? What the data says

Mostly no, and several independent looks agree.

Study	What they looked at	What they found
Ahrefs, May 2026	137,210 domains	28% published a valid file. 97% of those got zero requests all month. About 96% of requests that did arrive came from bots.
SE Ranking	About 300,000 domains	10.13% had the file. No measurable link to how often a domain was cited by AI tools.
EZY Research, 12 weeks	The same valid file on 83 sites	OpenAI's crawler fetched llms.txt 7 times vs 3,990 for robots.txt. ClaudeBot: 9 vs 3,120. PerplexityBot: 0 vs 775. Meta's crawler: 193 vs 172.
Dejan.ai, 27 July to 15 August 2026	One site's server logs	Google, Anthropic, and OpenAI crawlers fetched robots.txt 1,150 times and llms.txt 4 times.
ProGEO.ai, March 2026	The Fortune 500	37 of 500 (7.4%) had an llms.txt. 92.8% had a robots.txt.

What stands out:

Adoption numbers differ because samples differ. Ahrefs measured sites using its analytics, which skew technical. Don't quote one number as "the" rate.
Busy crawlers mostly skip the file. In the EZY test, big crawlers read robots.txt thousands of times and llms.txt almost never. Meta's crawler was the lone exception.
AI bots don't go hunting for it. Requests for llms.txt files that didn't exist drew no AI bot traffic. Of requests to real files, about 19.5% came from named AI tools and 12% from tools that scan or audit these files.
Google is clear about search. Its generative AI search guide (updated July 10, 2026) lists llms.txt as something you can ignore. Keeping one neither helps nor hurts. John Mueller has compared it to the old keywords meta tag.
Yet Google built a check for it. On May 5, 2026, Chrome added an llms.txt audit to Lighthouse under "Agentic browsing audits." It only fails if your server errors on the request. No file means "Not Applicable." Search ranking is one job. Helping an AI agent browse for a user is another.
One caution. Per Search Engine Journal's summary, Ahrefs saw a research crawler studying llms.txt as a way to slip instructions to AI tools. Stick to your own plain facts and links.

Do developer tools need an llms.txt file?

Need? No. Should you make one? For your docs, yes.

It won't help you rank or get cited. If someone says a 30-minute llms.txt will get you into ChatGPT's answers, ask for their data. What moves the needle is in our AEO playbook for developer tools.

It does help people using coding assistants. Developers already point their tools at these files:

Google's Agent Development Kit docs show how to point Gemini CLI, Claude Code, and Cursor at their llms.txt.
Bright Data's docs tell developers to save its llms.txt into their project, in a Cursor rules file or an AGENTS.md.
Vercel publishes an llms.txt and an llms-full.txt and explains how to use them with Claude Code.

Howard says in v2 that coding assistants now use these files reliably. That's a smaller audience than "all of AI search," but it's the one a developer tool cares about.

It costs almost nothing. An hour of work, plus keeping it current.

Put it where your docs live. A file at docs.yourtool.com/llms.txt or yourtool.com/docs/llms.txt can cover just the docs, and a second one at the root can cover the marketing site.

A worked example: the llms.txt file we use at Studio1

Here is our own file, trimmed to show the shape (first item kept in each section).

# Studio1

> Technical content and developer growth partner for devtool, SaaS, and AI teams.

Studio1 helps developer-focused companies grow adoption through technical content
marketing, developer documentation and DX audits, developer video production, and
developer relations growth campaigns. [...]

## Services

- [Technical Content Marketing](https://studio1hq.com/technical-content-marketing): Developer tutorials, integration guides, SEO articles, and code-rich content written by engineers.
- [...]

## Key Pages

- [Homepage](https://studio1hq.com/)
- [Client Work](https://studio1hq.com/work): Tutorials, guides, and developer content Studio1 creates for client teams.
- [...]

## Products

- [Raah](https://raah.dev): Web analytics and real-user observability for developers and SaaS teams.
- [...]

## Blog

- [How to Get Your Tool Recommended by ChatGPT, Perplexity, and Google](https://studio1hq.com/blog/how-to-get-your-tool-recommended-by-chatgpt-perplexity-google): AEO, GEO, LLM SEO, crawler access, documentation strategy, comparison pages, community mentions, schema, and llms.txt guidance for developer tools.
- [...]

## Team

- **Arindam Majumder**: Co-founder and Content Lead. [...]

## Contact

- Email: contact@studio1hq.com
- [...]

What it gets right:

The H1 and quote answer "who is this?" in one sentence.
Every link has a note saying what's behind it, so a tool can pick the right page.
The order follows what people ask: services, then proof, then the blog.
It's short. One or two screens.

What we'd tighten (use it as a checklist for your own file):

Point links at Markdown pages. Ours link to HTML pages. We tested one post URL with .md added and it returns a 404, so the Markdown twins don't exist yet. This is the biggest gap.
Use one hostname. The file is served from www.studio1hq.com, the links use studio1hq.com. It redirects, so nothing breaks, but one hostname is cleaner.
Move low-value links under Optional. Terms, Privacy, and Careers don't belong in Key Pages.
Keep list sections as links. Our Team and Contact bullets are plain text. Make them links or fold them into the intro.
Add new posts as you publish. Our Blog section is hand-picked, which is fine if someone owns it. A stale file sends tools to pages that moved.

An llms.txt template for developer tools

Copy this and swap in your details. "ExampleDB" and "RivalDB" are made up.

# ExampleDB

> ExampleDB is a hosted Postgres database for small teams. It works with Prisma and Drizzle, and a new project takes about five minutes to set up.

Things to know before answering questions about ExampleDB:

- It runs Postgres 16. Standard Postgres SQL works.
- The free plan pauses a project after 7 days with no activity. Paid plans never pause.
- The Node package is `@exampledb/client`. Older tutorials that use `exampledb-js` are out of date.
- ExampleDB does not support MySQL.

## Start here

- [Quickstart](https://docs.exampledb.com/quickstart.md): Create a project and run your first query.
- [Connect with Prisma](https://docs.exampledb.com/guides/prisma.md): Connection string, pooling, and migrations.
- [Connect with Drizzle](https://docs.exampledb.com/guides/drizzle.md): Setup and a working schema example.

## API reference

- [REST API](https://docs.exampledb.com/api.md): Every endpoint with request and response examples.
- [Node SDK](https://docs.exampledb.com/sdk/node.md): Install, auth, and common calls.
- [Error codes](https://docs.exampledb.com/errors.md): Each error with its cause and fix.

## Guides

- [Migrate from RivalDB](https://docs.exampledb.com/migrate/rivaldb.md): Export, import, and what changes.
- [Backups and restore](https://docs.exampledb.com/backups.md): Schedules, retention, and point-in-time restore.

## Pricing and comparisons

- [Pricing](https://exampledb.com/pricing.md): Plans, limits, and what counts as usage.
- [ExampleDB vs RivalDB](https://exampledb.com/compare/rivaldb.md): Features, pricing, and where RivalDB is the better fit.

## Optional

- [Changelog](https://docs.exampledb.com/changelog.md): Release notes by version.
- [Status page](https://status.exampledb.com): Current uptime and incidents.
- [Privacy policy](https://exampledb.com/privacy.md)

How to fill it in:

Write the quote like an answer to "what is ExampleDB?"
Add a "things to know" list. The most useful part for developer tools. Include renamed packages, retired versions, limits, and what you don't support. The spec's own FastHTML example does this.
Write each note as the question the page answers. "Connection string, pooling, and migrations" beats "Prisma guide."
Link to Markdown pages where you can. If not yet, link to normal pages and add Markdown copies to your to-do list.
Put legal links in Optional. Keep pricing and comparisons near the top.
Test it. Per the spec, give an assistant only your llms.txt and ask it five real questions. If it can't answer, the file is missing something.

Do you need llms-full.txt too?

Probably not at first. llms.txt is the table of contents. llms-full.txt is the whole book in one Markdown file.

Bright Data's docs give a sensible rule: for a live assistant session, load llms.txt first and fetch single pages as needed. Use the full file for pipelines and tools that need everything at once. It can be very large. Suppose your docs platform generates both; great. If you write by hand, start with llms.txt.

How to add llms.txt to your site

Your setup	Easiest way
Mintlify docs	Generated automatically, along with Markdown versions of every page
GitBook	Serves one for published docs
Docusaurus	The docusaurus-plugin-llms plugin
VitePress	The vitepress-plugin-llms plugin
WordPress	Yoast SEO or AIOSEO generate and update it
Wix	Generated for every site
Drupal 10.3 and up	The LLM Support recipe
Next.js, Astro, or any static site	Write it by hand and drop it in your public folder so it serves at `/llms.txt`

If you write it by hand, serve it as plain text with a 200. Lighthouse only complains about server errors.

How to check if anyone is reading your llms.txt

Normal analytics won't show it, because AI tools fetch files without running your scripts. Use server logs:

grep -i "llms.txt" /var/log/nginx/access.log | grep -iE "gptbot|oai-searchbot|chatgpt-user|claudebot|claude-user|perplexitybot"

Expect very little. A handful of hits a month is normal. Zero is common.
Check the status code. 200 means served. 404 or 500 means something's broken.
Check robots.txt first. If it blocks a crawler, that crawler never reaches your llms.txt. Our AEO guide covers which bots to allow.

The bigger win is the manual test: give an assistant your llms.txt and a docs question, and see if the answer is right.

Common llms.txt mistakes

Dumping every URL into it. That's a sitemap's job. Pick pages you'd show a new customer.
Setting it up once and forgetting it. Update it with your changelog.
Linking to pages behind a login. Tools can't read them.
Using it to block bots. It can't. Use robots.txt.
Expecting traffic. Judge it by whether assistants answer your docs questions correctly.
Skipping the "things to know" list. It stops tools from repeating old, wrong advice about your product.

FAQ

What is llms.txt in simple terms?

A plain text file at the root of your site with a short summary of your product and links to your best pages. It's Markdown, so people and software can both read it.

Is llms.txt an official standard?

No. It's a community proposal from Jeremy Howard (September 2024, v2 in August 2026). No standards body has adopted it, and the big AI companies haven't publicly confirmed that their search tools rely on it.

Does llms.txt help SEO?

No. Google says its search ignores it, and a study of about 300,000 domains found no link between having one and being cited by AI tools.

Does ChatGPT or Claude read llms.txt?

Not reliably, per the logs. In a 12-week test on 83 sites, OpenAI's crawler read it 7 times, and Anthropic's 9, against thousands of robots.txt reads. Coding assistants do read it when a developer points them at it.

What's the difference between llms.txt and llms-full.txt?

llms.txt is a short index of links with notes. llms-full.txt is the full text of your docs in one Markdown file. Use the index for live questions and the full file for tools that need everything.

Where do I put llms.txt?

At your site root, such as https://example.com/llms.txt. Under v2, you can also add one in a subfolder like /docs/llms.txt, covering pages under that path.

Can llms.txt block AI crawlers?

No. It can't allow or deny anything. Use robots.txt.

How often should I update llms.txt?

Whenever key pages change: a new doc section, a renamed package, a new pricing page.

Should I use a generator or write it by hand?

If your docs platform makes one (Mintlify, GitBook, and others), use it and edit the intro. Otherwise, use the template above. Read the result once, since generated files often list too many pages.

Developer Docs as Your Best AEO Asset: How to Get AI to Cite Your Content

Nancy Garg — Fri, 09 Oct 2026 14:20:34 +0000

TL;DR

Developers now ask AI assistants before they open your docs, and machines already read a large share of doc pages.
Assistants cite single passages, so each docs section needs to answer one question on its own.
Plain HTML, answer-first writing, working code, visible versions, and fresh dates beat special files and extra markup.
Authority from outside your site still decides who wins, so earn links and real mentions.

A lot of developers now ask an assistant before they search Google. In the 2025 Stack Overflow Developer Survey, 50.6% of professional developers said they use AI tools every day, and another 17.4% use them weekly.

That changes what your docs are for. They are no longer only a place people visit. They are the source an assistant reads, quotes, and cites when someone asks how to use your product.

This guide shows how to structure developer documentation so assistants find it, trust it, and cite it. Every number below links to its source.

What is answer engine optimization (AEO) for developer docs?

Answer engine optimization is the work of making your content easy for AI tools to retrieve, quote, and credit. For docs, that means writing pages so an assistant can pull out one correct, complete answer.

It builds on normal SEO. The difference is the unit of competition. In classic search, the page ranks. In AI answers, a single passage gets picked. A clear section can win even when the page around it is average.

Some people call this GEO, short for generative engine optimization. The tasks are the same.

How do AI assistants decide which docs to cite?

There are two kinds of readers hitting your docs, and they behave differently.

	Search style assistants	Coding assistants
Examples	ChatGPT search, Google AI Overviews and AI Mode, Gemini, Perplexity	Cursor, Claude Code
What they do	Answer a question and attach links	Fetch docs in the middle of a task so the code is right
Who sees your page	Sometimes a person who clicks	Often nobody
What helps most	Authority, clear passages, fresh pages	Clean text, working code, easy to find pages

Both follow a similar path. SE Ranking describes four steps: the system finds candidate pages, breaks each page into passages, picks the passages that answer most directly, and credits some of them.

The data on what gets cited is useful. SE Ranking studied more than 2 million pages. These are links between traits and citations, not proof of cause, so read them as strong hints.

What they measured	What they found
Page depth (ChatGPT)	Pages over 2,900 words averaged 5.1 citations. Pages under 800 words averaged 3.2.
Freshness (ChatGPT)	Pages updated in the last three months averaged 6 citations. Older pages averaged 3.6.
Section size	About 120 to 180 words between headings beat very short sections.
Authority (ChatGPT)	Sites with over 32,000 referring domains were 3.5 times more likely to be cited than sites with 200 or fewer.
Google overlap	92.36% of AI Overviews linked to at least one domain already in Google's top 10.

Ahrefs adds that 44.2% of citations came from the first 30% of a page.

Google says the same thing in plain terms. Its guide to AI features in Search says there are no extra requirements to appear in AI Overviews or AI Mode, and no new machine readable files or special markup are needed. A page just has to be indexed and eligible to show with a snippet.

How to structure developer docs so AI assistants cite them: an 8 step playbook

1. Let the right crawlers in

You cannot write your way out of a page the crawler can't see. Start with access.

Here is a simple robots.txt that allows the bots that fetch pages to answer questions, and leaves the choice on training bots to you:

# Bots that fetch pages to answer live questions
User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Googlebot
Allow: /

# Bots that collect data for training (your call)
# User-agent: GPTBot
# Disallow: /
# User-agent: ClaudeBot
# Disallow: /

Four details trip up a lot of teams:

Render on the server. Vercel and MERJ found that none of the major AI crawlers they measured ran JavaScript. Gemini is the exception because it uses Google's crawling setup. That study is from December 2024, so check your own logs, but build as if it still holds.
Check your firewall and CDN. Many sites block AI bots by accident with a security rule.
Do not hide public docs behind a login or cookie wall. A crawler will not sign in.
Keep code samples and tables in the HTML. Do not load them with a script after the page opens.

A September 2026 sample of 95 sites found training crawlers get blocked about twice as often as retrieval crawlers. If you want citations, block training bots by name if you wish, and keep the fetching bots allowed.

2. Put the answer in the first two sentences

Give every page one question and answer it straight away. Name the page after the task, in the words a developer would type.

Here is the difference.

A weak opening: Webhooks are a way for our platform to notify your application when events happen. Our system sends HTTP POST requests to a URL you configure. For security reasons, it is important to make sure requests are genuine.

A strong one: To verify a webhook, compute an HMAC SHA-256 hash of the raw request body with your signing secret, then compare it to the value in the X-Signature header. If they match, the request is genuine. The full code is below in Node.js, Python, and Go.

The strong version can be lifted out of the page and still be a correct answer. That is what an assistant looks for.

Then write the page in this order: the answer, the working steps or code, the edge cases, and two or three links to the next likely questions. Title it "How to verify webhook signatures in Node.js," not "Webhooks."

3. Make every section stand on its own

An assistant does not read your page top to bottom. It pulls out one section. If that section says "as mentioned above," it falls apart when copied.

Name the thing. Write "the Acme Payments API," not "it."
Repeat key facts where they matter. If a rate limit applies to three endpoints, say it on all three pages.
Link for more, but do not link for meaning. The section should make sense without a click.
Use question style headings. "What happens when a request is rate limited?" matches how people prompt.

Do not chop everything into tiny pieces. SE Ranking's data favored roughly 120 to 180 words between headings over very short fragments. Short paragraphs help readers, but a section still needs enough context to be understood alone.

4. Show code that works the first time

A good code block is often the most citable part of a docs page. Make it complete, with imports, setup, and the call. No "..." in the middle.

Then add four things:

The language and the SDK or API version it works with.
The expected output, so the reader can confirm it worked.
The exact text of the common error, right under the example. People paste error messages straight into assistants, and exact text is a strong match.
The same example in each language your users use, as separate labeled blocks.

A table of error codes is one of the best things you can publish. It is dense, exact, and easy to quote.

5. Offer a clean text version of every page

A page full of menus, banners and scripts is noisy. A plain text version is cheaper for an assistant to read and easier to quote correctly.

Several developer companies already do this. Stripe lets you add .md to a docs URL to get a markdown version. Vercel's guide covers serving markdown through the Accept: text/markdown header and a link tag in the page head. Fastly serves markdown automatically to known AI user agents.

Now the honest part about llms.txtthe proposed file that lists your key pages for AI tools:

For search citations, no evidence it helps. SE Ranking checked about 300,000 domains. Only 10.13% had the file, and it found no link to citation counts.
Few files get read. Ahrefs studied 137,000 domains and found that 28% published the file and 97% of those got zero requests in May 2026.
For coding assistants, it can help. Mintlify ran 2,400 test runs across 20 docs sites and found that one link to llms.txt removed most of the 404 errors agents hit while guessing page addresses.

Treat llms.txt as a helper for coding tools, not a ranking trick. It costs almost nothing, so if your docs platform makes it for you, leave it on.

6. Show versions and update dates

Fresh pages get cited more. In SE Ranking's data, pages updated in the last three months averaged 6 ChatGPT citations against 3.6 for older ones. Ahrefs reports that AI-cited URLs are on average 25.7% fresher than normal search results.

For docs, freshness is also about being right. An answer that uses a retired endpoint hurts the developer and then hurts you.

Show "Last updated" and the API or SDK version at the top of each page.
Keep old version pages, clearly marked, with a link to the current one.
Set redirects when a page moves.
Publish a dated changelog. It answers "what changed in version 3?"
Review your top 20 pages every quarter, and only change the date when you really changed the page.

7. Publish comparison and migration pages

Developers ask assistants to compare options and plan moves. "Acme vs Provider X for webhooks." "How to migrate from Provider X to Acme."

Write these pages in the open. State what each option does well, show real numbers, and say who each one fits. Pages that read as an honest guide get used. Pages that read as an ad get skipped.

If you want the broader playbook for getting any developer product recommended, Studio1 covers it in How to Get Your Tool Recommended by ChatGPT, Perplexity, and Google.

8. Earn mentions outside your docs

On page work gets you into the race. Authority decides who wins it. In SE Ranking's study, referring domains were the strongest signal for ChatGPT citations. For Google AI Mode, domains with over 24,000 referring domains averaged 6.8 citations against 2.5 for sites with fewer than 300.

The same study found domains with a strong presence on Reddit and Quora had roughly four times the citations of domains with little. That is a correlation, since bigger brands get mentioned everywhere. Still, developers trade answers in communities, and assistants read those places too.

Publish original data. Benchmarks and usage numbers give others a reason to link to you.
Answer questions in public. Stack Overflow, GitHub discussions and forums, with honest answers that link to the exact docs page when it helps.
Get listed where developers look. Package registries, integration directories and "awesome" lists on GitHub.
Make your docs easy to link to. Stable URLs and heading anchors let people point at the exact section.

Can templated pages help your docs get cited?

Yes, if each page has real data behind it. Docs are well suited to programmatic SEO, which means building many pages from one template and a set of real facts. You probably have hundreds of items that each deserve a page.

Page type	Question it answers	Data you need
Error code	What does error 429 mean and how do I fix it?	Exact message, causes, fix, working code
Endpoint or SDK method	How do I call this and what comes back?	Parameters, example request and response, limits
Integration	How do I use Acme with Next.js?	Setup steps, tested code, known issues
Migration	How do I move from Provider X to Acme?	Concept mapping, code before and after
Comparison	Acme vs Provider X for webhooks?	Real limits, pricing, and honest trade offs

A simple rule: do not publish a templated page until you can answer four questions with facts unique to that page. What exactly goes wrong or is needed? Why does it happen? What is the working fix or example? Which real numbers apply?

If a page would read the same with one word swapped, search engines and assistants will skip it.

How do you know if AI assistants are citing your docs?

Normal analytics miss most of this. Mintlify notes that coding agents rarely show up in Google Analytics because they fetch pages without running the tracking script. Use three checks instead.

Read your server logs. Filter by user agent: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, Googlebot. You will see which pages they fetch and which they miss.
Run a fixed prompt test. Write 20 real questions your users ask. Ask each in ChatGPT, Gemini, Perplexity, Claude, and one coding assistant. Record whether your docs are cited, whether a competitor is, and whether the answer is correct. Repeat monthly with the same list.
Watch search and referrals. Search Console includes AI features in its reports. Track AI referral visits as their own group. SE Ranking found these visitors spent 68% more time on site than organic search visitors.

Read the answers, not only the links. Being cited is not the same as being recommended.

What mistakes keep developer docs out of AI answers?

Docs that only render in the browser. The crawler sees an empty page.
A long warm up before the answer. The useful part sits too far down.
Sections that depend on other sections. They fall apart when quoted.
Code with gaps. Snippets with "..." and no output cannot be trusted or copied.
Old versions with no label. Assistants repeat outdated answers, and developers blame you.
Betting on special files. FAQ schema showed no lift in SE Ranking's data: pages with it averaged 3.6 citations, pages without averaged 4.2.
Thin templated pages. Same text, one word changed.
No presence outside your own site. Authority is still the biggest signal.

Frequently asked questions

Does llms.txt help my docs get cited by ChatGPT or Google?

Not according to current data. SE Ranking found no link between llms.txt and citation counts across about 300,000 domains, and Ahrefs found 97% of the files in its 137,000 domain study got no requests in May 2026. It may help coding assistants find your pages, so it is fine to publish. Just do not count on it for citations.

Do I need FAQ schema or special markup?

No. Google says no special schema or markup is required for AI Overviews and AI Mode. A visible FAQ section can still help readers, and pages with FAQ content averaged slightly more citations in AI Mode (4.9 against 4.4), but the markup itself did not matter.

How long should a developer docs page be?

Long enough to fully answer the task. In SE Ranking's ChatGPT data, pages above 2,900 words averaged more citations than pages under 800 words. Do not pad to hit a number. Cover prerequisites, steps, code, output, errors, and limits, and stop there.

Will AI assistants read docs that rely on JavaScript?

Often not. Vercel and MERJ found that major AI crawlers such as GPTBot and ClaudeBot did not run JavaScript in their study. Render your docs on the server so the full text is in the HTML.

How often should I update my docs?

Review your most important pages at least every three months. Pages updated in that window averaged 6 ChatGPT citations in SE Ranking's data against 3.6 for older pages. Update when facts change, and show the date.

Is AEO different from SEO?

It is the same foundation applied to a new place. Crawlability, authority, helpful content, and freshness matter for both. The change is writing so single passages can be quoted, and measuring citations and mentions alongside clicks.

10 Projects You Should Build with Jev

Nancy Garg — Tue, 06 Oct 2026 19:25:08 +0000

JEV is getting a lot of attention right now.

People are excited about it, and developers are already experimenting with ways to use it inside real applications.But there is a common mistake when trying a new AI model like JEV: treating it like another general-purpose LLM.

JEV becomes much more interesting when you use it for decisions rather than generation. Instead of asking it to write an email or generate a long answer, you give it some context, define the decisions it can make, and let your application act on the result.For example, a support system could use JEV to decide whether a ticket belongs to billing, engineering, or sales. A browser agent could use it to choose which button to click next. An AI application could use it to decide which model should handle a particular request.The model makes the decision, while your code handles the action.That simple pattern opens up a lot of interesting use cases. Here are 10 projects worth building with JEV.

1. Build a smart support ticket router

Support teams spend a lot of time reading incoming tickets and deciding where each one should go. A ticket might be a billing question, a technical issue, a feature request, or an urgent complaint from an unhappy customer.JEV can handle the first layer of that workflow.You can give it the ticket and ask which team should handle it, how urgent the issue is, whether the customer appears frustrated, and whether the ticket needs immediate human attention. Your application can then use those decisions to route the ticket automatically.A technical issue can go to engineering, a refund request can go to billing, and an urgent issue can be moved to the top of the queue.The important part is that JEV does not need to write the customer response. A generative model can handle that later if needed. JEV only needs to make the decision that determines what happens next.

2. Build an inbound lead scorer

The same approach works well for sales.A typical website can receive a mix of serious prospects, students, competitors, and people who are simply exploring a product. Sales teams often have to spend time sorting through these submissions before deciding which ones deserve attention.You can use JEV to score each lead based on information such as the person's job title, company, form submission, and other available context.The model can determine whether the lead fits your ideal customer profile, whether they appear ready to buy, whether they are likely to be a decision-maker, and how the lead should be prioritized.Your application can then route high-priority leads directly to sales while sending lower-priority leads into other workflows.This turns JEV into a lightweight decision layer for your sales pipeline.

3. Build a comment moderation system

Moderation is another problem that can be expressed as a set of decisions.For a community, social platform, or Discord server, you can give JEV a comment and ask whether it is spam, harassment, unsafe content, or something that requires human review.Your application can then use those results to decide what happens to the comment. Clearly safe content can be published automatically, while potentially harmful or uncertain content can be sent to a moderator.You can also introduce confidence thresholds so that the system only automates decisions when JEV is sufficiently confident.This creates a useful balance between automation and human review instead of assuming that every AI decision should be acted on automatically.

4. Build an AI citation checker

AI-generated content often includes claims that sound convincing but are not actually supported by their sources.A simple JEV application could check whether a specific source supports a specific claim.Give the model the claim and the relevant source, then ask whether the source supports the claim, contradicts it, or does not contain enough information to determine the answer.For example, if an AI-generated report says that a company grew its revenue by 40% while the cited source says it grew by 12%, the application can flag the mismatch before the report reaches the user.This could be useful for research tools, education platforms, content workflows, and AI agents that work with external sources.The key is to keep the question narrow. You are not asking JEV to research the entire internet. You are asking it to make one specific judgment about a piece of evidence.

5. Build a smarter RAG context picker

RAG systems often retrieve several documents and pass them directly into the context of a larger language model. The problem is that not every retrieved document is useful.Some documents may be irrelevant, outdated, contradictory, or contain instructions that should not be passed into the final context.JEV can sit between retrieval and generation as a filtering layer.For example, your search system could retrieve 20 documents and JEV could decide which ones are relevant to the user's question, which ones are outdated, whether any documents conflict with each other, and whether a document should be included in the final context.The main LLM can then focus on generating the answer using a cleaner set of information.In this architecture, the LLM handles generation while JEV helps decide what information the LLM should see.

6. Build a semantic code review bot

Traditional linters are good at catching problems that can be expressed as explicit rules, such as formatting issues, type errors, and missing imports.Engineering teams also have rules that are much harder to express through traditional static analysis.For example, does a new API expose private customer information? Does a pull request bypass an important approval step? Does a change introduce a risky pattern? Did the developer add tests for the new behavior?These are questions that can be handled by a decision model.You can give JEV the changed code along with the relevant project rules and ask it to evaluate a small set of specific conditions. When it identifies a likely problem with high confidence, your GitHub workflow can flag the pull request or request human review.This does not replace human code review. Instead, it adds another layer that can catch potential issues before an engineer spends time reviewing the entire change.

7. Build an AI model router

Modern AI applications often have access to several models, and sending every request to the most expensive model is rarely necessary.A simple question might be handled by a small model, while a complex coding task could require a more capable model. Some requests may need retrieval, a tool, a business workflow, or even a human instead of another model.\
\
Give it the user's request and ask it to classify the task based on the characteristics that matter to your application. Your code can then choose the appropriate model or workflow.A simple FAQ can go to a cheaper & faster model like GLM 5.3 Flash through @nebiustf , a difficult coding task can go to a stronger model like GLM 5.3, and a refund request can be handled by your existing business logic.JEV does not need to answer the user's question. It only needs to decide where that question should go.

8. Build an AI agent safety firewall

AI agents can now browse websites, send emails, modify records, call APIs, and perform other actions on behalf of users. That makes it important to evaluate an action before allowing an agent to execute it.Imagine an agent wants to delete hundreds of customer records. Before executing the action, you could use JEV to evaluate whether the action is irreversible, whether it involves sensitive information, whether it matches the user's request, and whether it should be allowed, confirmed by the user, or blocked.Your application can then enforce that decision.Low-risk actions can proceed automatically, medium-risk actions can require confirmation, and high-risk actions can be blocked.JEV should not be treated as a replacement for permissions, access controls, validation, or other security measures. It can instead provide an additional semantic layer between an AI agent and the actions it wants to perform.

9. Build a browser agent reflex layer

Browser agents spend much of their time making small decisions. They need to decide which button to click, which search result to open, whether to scroll, whether to go back, or which tab to select.These decisions do not always require a large generative model.You can give JEV a compact representation of the current browser state along with a limited set of possible actions. It can then choose the action that best moves the agent toward its goal.Your browser automation system executes that action, the page changes, and JEV makes the next decision.A larger model can still handle tasks that require generation or more complex planning, such as writing an email or filling out a long form.This creates a clean architecture where a larger model handles planning, JEV handles fast decisions, and your automation code handles execution.

10. Build a real-time game AI

One of the most interesting ways to experiment with JEV is to use it as the decision-maker for a small game.Instead of giving the model a huge screenshot and asking it to play the entire game, represent the game state in a compact format. You might tell it that an enemy is nearby, the player's health is low, an obstacle is ahead, and the available actions are attack, jump, retreat, heal, or block. JEV chooses an action, the game executes it, and the updated state is sent back for the next decision.This creates a simple loop where the application provides the state, JEV selects an action, and the game executes it.The same architecture can work for a platformer, driving game, tower defense game, or almost any environment with a relatively small action space.

The bigger idea behind JEV

Although these projects look very different, they all follow the same basic architecture. Your application has some state that needs to be interpreted. JEV makes a small, specific decision about that state, and your code takes the resulting action.That makes JEV less interesting as a replacement for a general-purpose chatbot and more interesting as a decision layer inside software.The best use cases are often the decisions that happen repeatedly throughout a product: which ticket should be escalated, which model should handle a request, which document belongs in the context, whether an agent action is safe, or which browser action should happen next.Once you start looking at software through that lens, you can find many places where a fast decision model can fit.So instead of building another chatbot with JEV, look for a workflow where information comes in, your application needs to make a decision, and that decision triggers an action.Let JEV make the decision, and let your code handle everything that happens after it.

Gemini 4 Argon: What's New, What It Costs, and Whether to Switch

Nancy Garg — Tue, 06 Oct 2026 19:13:43 +0000

Google DeepMind recently launched Gemini 4 Argon, with a big benchmark table and a small guest list. Google's own numbers have it winning or tying 13 of 18 tests against Opus 5.5, Fable 5.1 and GPT-6 Astra. But for now it's only open to a group of cyber defenders.

So the useful question isn't whether it's the best model. It's what you should check before you switch, and what it'll cost you when you do. Here's what we know so far.

TL;DR

Argon wins or ties 13 of 18 benchmarks in Google's table, mostly knowledge work, long context, and DeepSWE. It loses on FrontierSWE and Terminal-bench.
The output limit jumps from 64K to 1M tokens. It also writes a lot: 62k tokens per task against 27k for GPT-6 Astra in one independent test.
Launch price is $2 per million input tokens and $10 per million output. It doubles to $4 and $20 later.

What is Gemini 4 Argon?

Argon is Google's new flagship model. It's the first Gemini above the Flash tier in more than seven months, and it quietly replaces the Gemini 3.5 Pro that Google teased at I/O in May and never shipped.

Google built it for long, multi-step work: real-world software engineering, enterprise knowledge work like legal and finance, and cyber defense. Two details stand out for developers. The output limit is now 1M tokens, up from 64K. And it was trained to find, validate and patch software vulnerabilities on its own.

Then there's access. Argon went to trusted cyber defenders in Google's Fairwind Program on September 30. Google says paid API customers and Google AI Ultra subscribers come next, then developers, enterprises and consumers, once the guardrails have been tuned with early testers. It also says it's taking part in the US government's voluntary pre-release access process while it widens the rollout.

How it differs from the other models

As compared to the previous versions, the big change is the 1M-token output limit and the cyber training. Google says Argon makes clear leaps over Gemini 3.8 Flash Cyber, its previous security-focused model.

Against the rest of the field, the pattern in Google's own table is easy to read. Argon leads on knowledge work, long context, and DeepSWE. The other models keep the shell-and-terminal benchmarks.

Model	Leads on (in Google's table)	Reading
Gemini 4 Argon	Vals Index, AutomationBench, Vals Finance Agent v2, Harvey's Legal Agent, DeepSWE, Vibe Code Bench, RiemannBench, both GraphWalks tests, Agent's Last Exam, Chartography, LVBench	Best on document-heavy and long-context work
GPT-6 Astra	FrontierSWE v2, Terminal-Bench Science 0.1, OSWorld-2.0	Best on harder agentic and computer-use tasks
Claude Opus 5.5	Terminal-bench 4.0, PostTrainBench	Best on shell agents and ML engineering
Claude Fable 5.1	None	Never first in the table

On cybersecurity, Argon and GPT-6 Astra tie at 68% on CWE-bench v1.

For a neutral check, Artificial Analysis says Argon matches GPT-6 Astra on its Intelligence Index and sits one point ahead of GPT-6.1 Sol.

The test scores

Treat these as best cases. They're Google's chosen benchmarks, mostly from its own runs, as tabulated by The New Stack.

Three caveats on reading it.

First, several leads are narrow. On the Vals Index and Vibe Code Bench, the gap is under two points. Vibe Code Bench is a tie in practice, since all four models score above 89%.

Second, the harness matters. On CWE-bench v1, the OpenAI and Anthropic models ran in their own agent harnesses, Codex and Claude Code, so that score reflects model plus tooling. And Artificial Analysis ran Terminal Bench 4 separately and put Argon at 57%, behind Claude Sonnet 5.5 (64%), Opus 5.5 (60%), and GPT-6 Astra (59%).

Third, the biggest gaps are in knowledge work and long context. The legal result looks huge next to Fable 5.1, but 19.6% still means about one task in five completed.

What it will really cost you

Price per token is the wrong number to compare. Artificial Analysis measures cost per task, and that's where Argon's chattiness shows up.

Scenario	Cost per Intelligence Index task
Gemini 4 Argon, launch price ($2 in, $10 out)	$1.99
Gemini 4 Argon, full price ($4 in, $20 out), my estimate	about $3.98
GPT-6 Astra, max effort	$3.26

The first and last rows are Artificial Analysis's figures. The middle row is mine. The launch discount is a 50% promotion, so if Argon keeps using the same number of tokens, doubling the price doubles the cost. Astra's price could change too, so treat that row as a rough guide, not a forecast.

A few other anchors. Opus 5.5 charges $20 per million output tokens, the same as Argon's post-launch rate. GPT-6.1 Sol's newly discounted price matches Argon's launch price. One maxed-out 1M-token response costs $10 now and $20 later. Cached input tokens get 95% off the input price, which should help if you resend the same repo-sized prompt.

What to check before you switch

I didn't find any migration notes in Google's announcement or the coverage, so this isn't a changelog of breaking changes. It's a checklist of what the launch details imply.

You can't switch yet. Access is gated, and the model ships without cyber guardrails only for Fairwind participants and Google's own teams. Google is still tuning the safeguards before a wider release, so security-heavy prompts may behave differently once you get access.
Revisit your output settings. The limit went from 64K to 1M tokens. If you cap max output, set timeouts, or stream into something with size limits, those choices were made for 64K. Raise the ceiling on purpose, not by default.
Expect a chattier model. Artificial Analysis measured 62 K output tokens per task for Argon against 27 K for GPT-6 Astra at max effort. Watch latency and bills, not just quality.
Plan for the price change. $2 and $10 per million tokens is an introductory rate. It becomes $4 and $20.

What Google has built with it

Everything below comes from Google's own announcement and describes internal use. Read it as a demo reel, not a benchmark.

C/C++ to Rust migrations. Argon agents are porting code across Google, from tens of thousands of lines in libraries like re2 and libgav1 up to 800K+ lines for the Fuchsia Zircon kernel. Google says these rewrites are still going through automated and manual audits, emulation testing, and review before production.
libgav1. Starting from an existing Rust port, agents replaced 32K lines of SIMD code with safe Rust that the compiler vectorizes on its own. Google reports a memory-safe video decoder that runs 2.7x faster than the port, with identical video output.
Data center memory. A team of agents analyzed fleet-wide profiling data and applied memory optimizations, freeing over 300 TiB once rolled out. Google estimates 500 TiB to 1 PiB in total.
Quantum. Argon beat a published baseline by 40% on the qubits-times-gates cost of one subroutine, in a matter of minutes.
Security. Wiz, which Google acquired in March, is using Argon in its Scan for Good program. Google says it found a critical flaw in healthcare software used by hospitals worldwide that earlier frontier models missed.

The libgav1 story is the one worth stealing. The loop is profile, run an experiment, read what the compiler produced, repeat for many rounds. You can run that loop with any capable model today. Google's claim is that Argon stays on it without losing the thread.

Where it still loses

This is the part the launch post skips.

FrontierSWE v2. Argon scores 55.0% to GPT-6 Astra's 65.5%, and it's last of the four models.
Terminal-bench 4.0. Opus 5.5 leads with 66.4% against Argon's 57.4%, a nine-point gap.
Other agentic and science tests. Astra beats it on Terminal-Bench Science 0.1 (68.1% to 57.6%) and OSWorld-2.0 (72.6% to 69.2%). Opus 5.5 beats it on PostTrainBench (49.3% to 45.3%).
Cyber comparisons. Google compares its security results only with its own Gemini 3.8 Flash Cyber: 85.8% against 71.0% on its internal vulnerability benchmark, and 70.9% against 58.2% on Wiz's penetration testing benchmark. That shows progress, not rank.
Independent testing. Very few people outside Google have had hands-on time. Bloomberg reported before launch that some people inside Google worry Argon isn't as strong as the Anthropic and OpenAI models. Google disputes that and says employees have been testing versions for weeks.
Cost per task. Once the launch discount ends, Argon may not be the cheap option (see above).

One more loose end. Google's post doesn't state a context window, and one outlet reports 2M tokens. I'd wait for the docs.

Wrapping up

Argon looks strongest where the work is long and document-heavy: finance, legal, automation, big inputs, big outputs. It looks weaker in shell-driven agent work, where GPT-6 Astra and Opus 5.5 still hold the lead in Google's own table.

The public benchmarks also disagree with each other. DeepSWE says one thing, FrontierSWE and Terminal-bench say another. So don't switch on a headline number. Pull 20 or so real tickets from your own repo, run them through whatever you use today, and run them through Argon once you have access.

When you do, log two things: cost per task and whether a long output is still coherent at the end. Neither has been independently checked yet.

How to Get Your Tool Recommended by ChatGPT, Perplexity, and Google

Nancy Garg — Tue, 06 Oct 2026 19:10:55 +0000

TL;DR

Getting your tool recommended by AI search isn't just about traditional SEO. You need to build the signals that ChatGPT, Perplexity, and Google use to understand, trust, and surface your product.

AI recommendations depend on more than keywords. Clear positioning, authoritative content, technical depth, and consistent mentions all matter.
Your documentation and technical content need to answer the exact questions developers are asking before they ever reach your website.
Being mentioned across trusted websites, communities, GitHub, Reddit, and developer publications can strengthen your product's discoverability.
The goal isn't to game AI search. It's to make your tool genuinely useful, easy to understand, and easy for AI systems to discover and cite.

A lot of developers nowadays ask ChatGPT before they ask Google. In Stack Overflow's 2025 survey, 47.1% said they use AI tools every day, and another 17.7% use them every week. That adds up to about 65%. And when someone asks which tool to use, they don't get ten blue links. They get a short list of names, with a line or two on each.

So the question for any developer tool is how to land on that list. Ranking well on Google used to be most of the answer. It covers less now: Ahrefs found that 76% of AI Overview citations came from pages in Google's top 10 in July 2025, and by January 2026 only 38% did. Google says this is still SEO at heart. But studies of what AI tools cite, like this one from Peec AI, show that being talked about on Reddit, YouTube, and review sites matters too. This guide covers both sides.

What is answer engine optimization (AEO)?

Answer engine optimization, or AEO, is the work of making your product easy for AI tools to find, understand, and name when someone asks a question. You will also see it called GEO (generative engine optimization) or LLM SEO. These all mean roughly the same thing.

The goal is different from classic SEO. SEO tries to get your link ranked on a results page. AEO tries to get your product's name inside the answer itself.

Google sees it a little differently. Its own guide to generative AI search says that optimizing for these features is still SEO, because AI Overviews and AI Mode are built on its normal ranking and quality systems. When a question comes in, those features can run several related searches at once, which Google calls query fan-out, and then pull from the pages they find.

Two things follow from that. First, basic SEO still matters, because the AI has to find your page before it can use it. Second, ranking is not the whole story. In an Ahrefs study of the 1,000 pages ChatGPT cited most in September 2025, 28% had no organic search keywords at all. A page can be quoted by an AI tool without ranking anywhere in Google.

How do ChatGPT, Perplexity, and Google AI Overviews choose what to recommend?

Each one finds pages in its own way, so your first move is a little different for each.

Engine	How it finds your pages	What studies say it leans on	Your first move
ChatGPT	Its own search crawler, OAI-SearchBot	Wikipedia, Reddit, and editorial sites like Forbes	Allow OAI-SearchBot, and make your homepage say plainly what the product does
Perplexity	PerplexityBot, plus Perplexity-User when a person asks a question	Reddit, LinkedIn, and G2 for business software questions	Allow PerplexityBot, and earn real reviews and discussions
Google AI Overviews and AI Mode	Google's normal search index	Pages that are indexed and can show a snippet. Google lists no extra requirements	Get basic SEO right, and watch the AI report in Search Console

Sources for the table: OpenAI's crawler page, Perplexity's crawler page, Google's AI features page, and the Peec AI study of 30 million cited sources as reported by Search Engine Land.

Two patterns show up across the studies.

Community sites carry a lot of weight. Peec AI's analysis found Reddit was the most cited domain across ChatGPT, Google AI Mode, Gemini, Perplexity, and AI Overviews. YouTube, LinkedIn, Wikipedia, and Forbes also made the top five. Review sites like G2 and Yelp appeared often when people asked for recommendations.

Most of what ChatGPT cites is not yours to edit. In Ahrefs look at ChatGPT's top 1,000 cited pages, Wikipedia made up 29.7%, homepages and landing pages 23.8%, and how-to and explainer pages 19.4%. Ahrefs counted only 32.3% as pages a company could realistically get into: explainers, reviews, news, and blog posts. Ahrefs says its sorting of page types is a rough guide, so treat the exact split loosely. The useful part is the homepage number. You cannot pitch your way onto someone else's homepage, but your own is a page you fully control.

How to get your product recommended by AI: an 8 step playbook for developers

Work through these in order. The first four are about your own site. The next four are about the rest of the web.

1. Let the right crawlers in

If a crawler cannot read your site, nothing else in this guide matters. OpenAI says that to appear in ChatGPT search results, you should allow OAI-SearchBot. Perplexity says the same about PerplexityBot. Google's AI features page says crawling has to be allowed in robots.txt and by any CDN or hosting setup you use.

A simple robots.txt that allows all three looks like this:

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Googlebot
Allow: /

Four details trip up a lot of teams:

GPTBot is a separate bot. OpenAI treats it as its own setting, used for training. You can block GPTBot and still allow OAI-SearchBot, so blocking one does not have to hide you from ChatGPT search.
Your firewall can block them even when robots.txt says yes. Perplexity asks you to allow its published IP ranges and walks through the setup for Cloudflare and AWS.
Changes are not instant. Perplexity says it can take up to 24 hours for a robots.txt change to show up.
Docs that only appear after JavaScript runs, or that live inside images or videos, are easy to miss. Google says important content should be available as text. A quick test: open your docs with JavaScript turned off and see what is left.

2. Put the answer in the first few lines

Start every page with a plain answer to the question it exists for. Search Engine Land reported a study finding that 44% of ChatGPT citations come from the first third of a page's content. If your best sentence is in paragraph six, it may never get used.

Here is the difference. A weak opening spends three paragraphs on how fast software is changing. A strong one looks like this (ExampleDB is made up for this guide):

ExampleDB is a hosted Postgres database for small teams. It costs $15 a month, works with Prisma and Drizzle, and takes about five minutes to set up.

Then write your headings as the questions people really type. "How do I connect ExampleDB to Next.js?" beats "Connecting". Keep paragraphs short, and put the answer first before the explanation.

3. Publish the comparison pages people ask for

Recommendation questions are comparison questions: "best tool for X", "X vs Y", "alternatives to Y". If you do not have a page for those, someone else writes it, and AI tools quote them instead.

Write these pages yourself, and write them fairly. Put pricing in a table. Name the limits. Say who each tool suits, and where the other tool wins. A fair page is more useful to readers and easier to quote. If you run benchmarks, say how: the machine, the version, the date, and the code.

Google's guide to generative AI search describes the content that holds up best as non-commodity: material built on first-hand experience that goes beyond what anyone could copy from other pages. Your own tests and your own numbers are exactly that.

4. Make your docs the best answer on the web

For developer tools, docs do the job that blog posts do for other products. Developers ask "how do I add X to Next.js" or paste an error message straight into a chat. Cover those questions:

A quickstart that works when copied, with version numbers.
One page per common error, with the exact error text in the heading, the cause, and the fix.
Migration guides from the tools people are leaving for yours.
Pricing, limits, and supported languages written out as text, not tucked into an image or a pricing widget.
Everything public. Docs behind a login cannot be read by a crawler.

5. Get talked about where AI tools already look

This is the step most teams skip, and the data says it matters most. Ahrefs studied 75,000 brands and found that how often a brand is mentioned across the web had the strongest link to showing up in Google's AI Overviews. It scored 0.664, on a scale where 1 would be a perfect match. Backlinks scored 0.218. Brands in the top quarter for web mentions averaged 169 AI Overview mentions, against 14 for the next quarter down. Brands in the bottom half barely appeared at all.

Two cautions. This is correlation, and Ahrefs says so itself. It also covered established brands (domain rating above 40), so for a new tool it shows direction, not a target.

What to do about it:

Answer questions on Reddit and Stack Overflow when your tool is a fair answer. Say that you work on it.
Make your GitHub README clear enough to quote: what it is, the install command, and a minimal example.
Record tutorial videos with real transcripts. YouTube was in the top five most cited domains in the Peec AI data.
Get into roundups, newsletters, and community lists that cover your category.
Ask happy users for honest reviews on sites like G2, which showed up often for recommendation questions.

Do not fake any of it. Google's guide says chasing inauthentic mentions is not as helpful as it looks, and that its systems are built to catch spam.

6. Say the same thing everywhere

Use the same product name, one-line description, price, and supported languages on your site, your GitHub page, your package pages (npm, PyPI, and so on), LinkedIn, and your docs. This one comes from common sense, not a study. If an AI tool reads three different prices, it may quote the wrong one or skip you.

A short facts page helps: name, what it does, pricing, languages, license, and a last updated date. Every other page can then match it.

7. Keep key pages fresh, and be honest about dates

AI tools lean toward newer pages. In the same Ahrefs look at ChatGPT's top 1,000 cited pages, Ahrefs could find an update date for just over half. About 90% of those had been updated in 2025, and with Wikipedia removed, it was still about 82%. The sample is small, but the direction is clear.

So update pricing, version numbers, and screenshots when they change, and show a real last updated date. Change that date only when you changechanged the page.

8. Schema markup and llms.txt: nice to have, not a fix

Google says there is no special markup you need for AI Overviews, and that structured data should match the text people can see on the page. If your site setup makes FAQ or software markup easy, add it. Do not spend a sprint on it.

The same goes for llms.txt. Google says its search ignores those files, so they neither help nor hurt you there. It also says it is fine to keep one for other services that use them. Treat it as optional, not a fix.

Can programmatic pages help your product get recommended by AI?

Yes, but only when every page carries real information. Programmatic SEO means building many pages from one template and a set of data. For developer tools that can be a very good fit, because so many developer questions follow a pattern: "X with Next.js", "X vs Y", "error 502 in X".

The risk is real, though. Google's guide warns that making separate pages for every variation of a question, mainly to manipulate rankings or AI answers, violates its scaled content abuse policy. It also says a high number of pages does not make a site better. A template with the product name swapped in is the exact thing it describes.

Here are page types that work, and the real data each one needs:

Page type	Question it answers	Real data every page needs
Integration pages ("X with Next.js")	How do I use X with this tool?	Code you have tested, version numbers, known issues
Comparison pages ("X vs Y")	Which one should I pick?	Pricing, limits, benchmarks with the method shown, where the other tool wins
Error pages	What does this error mean in X?	The exact error text, the cause, a fix that works
Use case pages ("X for job queues")	Is X good for my situation?	A real example project or customer story
Language pages ("X in Go")	How do I use X in my language?	SDK version, a working snippet, language specific limits

A simple rule: start with 10 to 20 pages you would be proud to show a customer, not 10,000. Before you publish a page, check four things. Does it answer a question someone really asks? Does it have code or numbers you verified yourself? Does it say something the other pages on the web do not? Would a developer who lands on it leave with what they came for? If any answer is no, fix the data first. Do not publish the page yet.

How do you know if AI tools are recommending your product?

You can check this by hand in under an hour a month. Here is a simple routine:

Write down 20 questions real developers ask about your category. Pull them from support tickets, Reddit threads, and your Search Console queries.
Once a month, ask each question in ChatGPT, Perplexity, and Google (including AI Mode). Use the same wording every time. Answers can change from one ask to the next, so ask the important ones a few times.
For each answer, record four things: were you named, were you linked, which competitors were named, and which sites were cited.
Look at the cited sites. Those are the pages shaping answers in your category, and they are your outreach list for step 5.

Then add the numbers your tools already give you:

ChatGPT referrals. ChatGPT adds utm_source=chatgpt.com to links, so you can **filter for it in** any analytics tool, like Google Analytics or raah.dev, which tracks both web analytics and web observability.
Perplexity referrals. Look for perplexity.ai in your referrer reports.
Google. Search Console has a Generative AI performance report. Google also warns that no outside tool has access to its internal ranking or AI systems, so be careful with tools that claim otherwise.
A free check. Ahrefs offers a free AI Overviews tracker that shows how often AI Overviews mention your brand and which sites they cite.

Expect slow movement. Crawler access can change within a day or so. Mentions across the web take much longer to build, so judge your progress by the quarter, not the week.

What mistakes keep developer products out of AI answers?

Blocking every AI bot. Many teams block all of them to stop training and end up hiding from search too. Keep OAI-SearchBot and PerplexityBot allowed even if you block GPTBot.
Publishing hundreds of thin pages. Google treats this as spam, and volume does not make a site better.
Buying or faking mentions and reviews. Google says it is not as helpful as it seems, and fake reviews can hurt real trust.
Hiding docs. Login walls, JavaScript-only pages, and text inside images all make your best material hard to read.
Rewriting everything for robots. Google says you do not need to chop content into tiny pieces or write in a special style for AI. Write for the developer reading it.
Judging by one test. One answer on one day tells you very little. Track a fixed set of questions over months.

Frequently asked questions

How do I get my product recommended by ChatGPT?

Allow OAI-SearchBot in your robots.txt, put a clear answer at the top of your homepage and docs, and get your product mentioned on sites AI tools trust, like Reddit and review platforms. OpenAI says sites that opt out of OAI-SearchBot will not be shown in ChatGPT search answers, so access is the first thing to check.

How long does it take to show up in AI answers?

Nobody can promise a date. Perplexity says a robots.txt change can take up to 24 hours to show up, but building mentions across the web is slow. Plan in quarters, not weeks.

Do backlinks still matter for AI visibility?

They help, but less than mentions in the Ahrefs study of 75,000 brands: 0.218 for backlinks against 0.664 for brand mentions in AI Overviews. In Ahrefs' look at ChatGPT's most cited pages, the ones that did rank mostly sat on strong sites, with 65.3% on domains rated 81 or higher. Both findings are correlations, so read them as hints.

Do I need an llms.txt file?

Not for Google, which says its search ignores those files. Adding one will not hurt, and other services may use it, but it should not come before the basics in this guide.

Do I need schema markup?

Google says no special markup is required for AI Overviews or AI Mode. If it is easy to add, keep it matched to the visible text on the page. Do not expect it to decide your results.

Should I block GPTBot?

That is your call. OpenAI treats GPTBot, used for training, and OAI-SearchBot, used for search, as separate settings. You can block the first and still allow the second.

Is AEO different from SEO?

Mostly, it overlaps. Google calls optimizing for generative AI search a form of SEO. The extra work is off your site: getting discussed in trusted places, and making each page answer its question clearly in the first few lines.

Claude Opus 5.5: What Changed, What Breaks, and Whether to Switch

Nancy Garg — Tue, 06 Oct 2026 19:03:33 +0000

In September 2026, Anthropic's CEO Dario Amodei published an essay with this line in it: "We must slow the pace at which we improve the capabilities of AI models."

A week after, on September 22, 2026, Anthropic released Claude Opus 5.5.

It landed just three weeks after Fable 5.1, so people had jokes. But if you write code for a living, the actual questions are something else. What does it cost you, what will it break, and is it better at your actual work?

TL;DR

If you want the quick take, Opus 5.5 is what Opus 5 should have shipped as, and Anthropic finally listened.

It doesn't ramble anymore. Opus 5 used to pad every answer with fluff. This one gets to the point, and it's about 30% quicker to do so.
It's cheaper, and the savings actually hold up. $4 in and $20 out per million tokens, down from $5 and $25. Just don't crank the thinking effort all the way up, or the savings disappear.
It comes close to Fable 5.1 on coding work, which is Anthropic's priciest model, at less than half the cost.
A few things break if you're already using Opus 5. Nothing that ruins your day, but enough that you can't just flip the switch and forget about it.

If you're on Opus 5 right now, this is worth moving to. Try it on your own work first though, the real difference only shows up once you compare it against what you're actually building, not the benchmark charts.

What is Opus 5.5?

Claude has 3 families of Models. Haiku, Sonnet, and Opus. Then there's Fable, a separate tier above all three that costs the most.

Opus 5.5 is built for agents that run for hours. It has a 1M token context window and a 128K token output limit. Its knowledge runs up to June 2026.

It's the first model in a new 5.5 family. Sonnet 5.5 and Haiku 5.5 are due in the next few weeks.

How it differs from the other models

	Opus 5.5	Opus 5	Fable 5.1	Sonnet 5
API name	`claude-opus-5-5`	`claude-opus-5`	`claude-fable-5-1`	`claude-sonnet-5`
Input / output price (per 1M tokens)	$4 / $20	$5 / $25	$10 / $50	$2 / $10
Cache reads (per 1M tokens)	$0.20	$0.50	$0.25	not listed
Speed	Medium	About 30% slower than 5.5	Slower	Fast
Context / max output	1M / 128K	1M / not listed	1M / 128K	1M / 128K
Safety filters	Cyber and biology	Cyber	Cyber and biology	not listed
Terminal-Bench 4.0 (coding)	66.4%	52.3%	55.8%	not tested
Best for	Long coding jobs, big refactors, reports	Same jobs, wordier	The hardest reasoning	Quick, simple, high-volume work

Compared with Opus 5, the biggest change is how it talks. Opus 5 wrote long, twisty answers and did extra work nobody asked for. Opus 5.5 puts the main point first, writes about 30% faster, and costs less, with cache reads down from $0.50 to $0.20. That last part adds up when an agent re-reads the same files all day.

Against Fable 5.1, it holds its own for a lot less money. It costs 60% less and beats Fable on most coding tests, including Terminal-Bench 4.0 (66.4% to 55.8%). Fable is still the one to move up to when the hardest problems get past Opus.

Compared to Sonnet 5, it's the heavier tool. Sonnet is half the price and faster, so it's the better pick for small edits, summaries, and routing. Reach for Opus 5.5 when the job is long or tricky.

What breaks when you switch

Some requests that worked on Opus 5 now return errors. The full list is in the docs. These are the four you'll actually hit:

Thinking can't be turned off. Sending thinking: {"type": "disabled"} or a manual token budget returns a 400. Leave it out, or use adaptive, and control depth with effort.
Forced tool use is gone. tool_choice set to any or a named tool returns a 400. Use auto with strict tool use, and say in the prompt when the tool should run.
Progress messages can go quiet. The short notes the model writes between tool calls now arrive as thinking blocks, which are empty by default. A UI that streams them will look frozen, with no error.
The old computer use tool is rejected. On the Claude API and Google Cloud, computer_20251124 returns a 400. Use computer_toolset_20260801. Bedrock still accepts the old one.

There's one more, and it only affects newer accounts. Thinking blocks are tied to the conversation, so editing anything earlier in the conversation before replaying them returns an error. Keep conversations append-only.

What it will really cost you

Anthropic says the average job costs about 40% less than on Opus 5. That holds at the default effort, which is now medium.

At max effort it doesn't. An independent test found the model writes about 119,000 tokens per task there, against about 73,000 for Opus 5. The price cuts cancel that out, so the cost per task came out flat at roughly $6.

It also thinks harder at each effort level than Opus 5 did. So don't copy your old setting over. Re-run a sweep on your own tasks and compare cost per finished task, not price per token.

A few other prices, if you're budgeting:

Batch: half price, $2 in and $10 out.
Fast mode: up to 2.5x speed at $8 in and $40 out. Claude API only, and still a research preview.
OpenAI: GPT-6 Astra is reported at $10 and $50, the same as Fable. The cheaper GPT-6 Sol costs far less per task but scored well below Opus 5.5 in the same test.

The Test Scores

Benchmarks are standard exams for models. These are the ones that matter most for dev work (best score in bold):

Test	What it checks	Opus 5.5	Fable 5.1	Opus 5	GPT-6 Astra
Terminal-Bench 4.0	Multi-step tasks in a command line	66.4%	55.8%	52.3%	57.9%
FrontierCode	Would the code change get merged	54.4%	50.3%	48.0%	53.3%
CursorBench 4.0	Real tasks from Cursor users	57.8%	51.8%	46.6%	not reported
OSWorld 2.0	Using a computer by clicking and typing	81.8%	80.7%	74.0%	not reported
AutomationBench	Business tasks across many apps	40.0%	31.4%	26.9%	41.4%
Terminal-Bench-Science	Science research tasks	58.7%	52.6%	29.0%	64.6%

These are best-case scores, mostly from the maker's own runs. Even Anthropic says the real gap to Fable is smaller than the table looks.

What people have built with it

These are some great use cases built by people who got their hands on Opus 5.5 in the first two days. Most came from a single prompt.

Sketch to simulator. Ben Poole, formerly of Google Brain and DeepMind, drew a trebuchet on paper and sent Opus 5.5 a photo. It gave him a working 3D simulator where you change the weight and angle, fire at a stack of blocks, and replay the shot.
Minecraft in a browser tab. Noah Wachnik asked for a playable Minecraft with fancy shaders. At max effort it built a game called Lumen Vale in 1 hour 37 minutes. You can walk around, break and place blocks, and the water ripples while the lighting changes with the time of day.
Pixel art wizard from a strict spec. Majid wrote a tight prompt: one HTML file, 128x96 resolution, 24 colors, particle effects, and a state machine for idle, charge and cast. It followed the whole spec and runs at 60 fps.
An 80-second film with no libraries. Chris Riley wanted a film in one HTML file using only WebGL2 and plain JavaScript. No libraries, no images, no audio files. The result is a glass mosaic where the fish and birds are made of moving tiles.
A Blender castle, with the bill. Stefan Vaskevich had Opus 5.5 and GPT-6 Astra each build a 10-second Blender animation of a castle from one prompt. Opus took 35 minutes and cost about $13.30. Astra was faster at 28 minutes but cost $14.50. Stefan felt Opus handled more complexity.

These are demos people chose to post, so treat them as best cases.

Where it still loses

Not everything's better. A few real gaps before you switch:

Coding. Sonar found it writes about 27% less code, with 42% fewer issues overall. But bugs per line went up 12%, and problems in concurrent code went up 44%. If your codebase leans on threads, locks, or async, don't skip the review.
Motion graphics and creative work. Opus 5.5 is also being used for motion graphics and creative coding, with people generating animations from simple prompts. We have created one ourselves using a single prompt. The model goes beyond code generation into actually building visual experiences.
Business tasks and science. OpenAI's Astra still wins both. It beats Opus 5.5 on business tasks, and by a wider margin, on science.
Hard reasoning. Fable still wins here. If your evals fail at high effort, that's your next move, not a higher setting on Opus.
Speed. It's slow to start. One test clocked about 22 seconds before the first word at medium effort. Fine for a background job, bad for a chat window someone's watching.
Security and biology. Some work gets rerouted without asking. Most security tasks, like finding exploits, go to the older Opus 4.8. Flagged biology requests go to Opus 5. The filters read your files and search results too, so something already sitting in your repo can trigger a reroute. Worth checking if you build anything security or bio adjacent.
Simple, everyday tasks. Sonnet 5 is still the better call here. Cheaper, faster, no reason to reach for Opus.

Wrapping up

Opus 5.5 is basically Opus 5 with some parts fixed. Anthropic heard the complaints about Opus 5 and cheaper, faster, less bloated is the result.

It's not for everyone. Security, biology, or low-latency work still needs a second look, and a few breaking changes mean this isn't a plug-and-play swap.

Test it on your own tasks before you switch. That's the only benchmark that matters.

What is Jev? In 5 minutes

Nancy Garg — Tue, 06 Oct 2026 18:59:13 +0000

TypeSafe AI released a new model called Jev on September 15, 2026, and it works differently from most AI models you've probably used.

Instead of writing you an answer, it picks one from a list you give it, and tells you how sure it is about that pick. TypeSafe has named it System One model.

Most of the time when software uses AI to make a decision, like sorting a support ticket or flagging a transaction, it doesn't actually need a written answer, it need few outcomes.

But an LLM throws a full paragraph and then you have to write code to pull out the actual decision. But Jev skips all of that and gives you the decision directly.

TL;DR

Jev takes a piece of text (state) plus one or more typed questions, and returns a typed answer with calibrated probabilities. Never free-form text.
Three answer types: Choice (pick one of N options), Score (rate on an ordered scale), Noul (probability that a yes/no statement is true).
It's fast (well under a second in most cases) and cheaper $0.042 per million input tokens, output is free.

What exactly is Jev?

Jev is built by TypeSafe AI, started by Diogo Almeida, the person who worked on ChatGPT and RLHF at OpenAI, along with Erik Gafni and Sasha Sheng.

The way it works is pretty simple once you see it. You give it a piece of text, called the state, and then you ask it a question that has a fixed set of possible answers. It reads the text and answers the question, along with a number that says how confident it is. It gives a answer in 70 to 500 milliseconds.

There are three kinds of questions it can answer. You can ask it to pick one option out of a list, give a score on a scale, or answer yes or no as a probability. And you can send it several questions about the same piece of text, and it answers all of them together in one go.

A real example: asking it whether a support ticket needs a refund on a short message cost about $0.00002. Run that on a million similar tickets, and the total comes to around $19.

How Jev Is different

Jev doesn’t replace them. They do different jobs. Here is a quick comparison between Jev and standard LLM

	GPT / Claude	Jev
What it gives you	Written text	A picked answer with a confidence score
How fast	A few seconds	Under a second
Input cost	Around $10 per million tokens	$0.042 per million tokens
Output cost	You pay for every word	Free
Can it write essays or code	Yes	No
Can it have a conversation	Yes	No
Can it be wrong	Yes	Yes, but it can never give an answer outside the options you gave it

That last row is worth pausing on. Jev being unable to go outside the list of answers you gave it doesn't mean it's always right, it just means it can't get creative in a way that breaks your code. If you told it the answer has to be low, medium, or high, it will never hand you back something else, but it can still confidently pick medium when the real answer was low.

TypeSafe's own number is 193x faster and 444x cheaper on their internal benchmark, self-run and openly flagged as the high end.

One more practical detail: it can only read text, so no images or audio, and it can handle roughly 32,000 tokens per question, or about 64,000 tokens total once you count the input plus the question itself.

The pattern: Claude thinks, Jev decides

Once you actually sit with how Jev is meant to be used, a pattern shows up everywhere. You keep a model like Claude or GPT around for the parts that need thinking or writing, and you hand Jev the small decision sitting in between.

A task comes in. Claude or GPT reads it and works out what needs to happen, maybe drafts a reply, maybe explains something. Jev sits next to that, and every time there's a small decision in the road, which row is urgent, whether to brake, whether a tool call is even needed, Jev picks the answer in a fraction of a second, and the app acts on it.

The rule that falls out of this is simple: if you're making a model write out a full explanation just to arrive at one of three or four possible outcomes, you're paying for an essay when all you needed was a checkbox.

Usecase

Here are a few usecases that fit this shape well, the kind you'd normally build by prompting a chat model and parsing its reply.

Sorting leads. Feed it a form submission or a call summary, and let it sort into hot, warm, or cold. Nobody has to read through every lead by hand, and the hot ones get called first.
Routing support messages. Give it an incoming email or chat message, and have it decide whether it goes to billing, technical, refunds, or gets flagged urgent. The right team sees it immediately instead of after someone manually sorts the queue.
Flagging invoices for review. Pass in the invoice details and let it mark each one clean, suspicious, or needs review. Your team only has to actually look at the handful that came back flagged.
Triaging incoming customer messages. For a business getting messages through chat or WhatsApp, sort each one into booking, pricing question, complaint, or spam, so replies go out to the ones that matter first.
Choosing which model an agent should use. Instead of burning tokens on a big model deciding whether to search, calculate, query a database, or hand off to a human, let Jev make that pick and save the expensive model for the actual task.
Tagging comments and content. Sort incoming comments or reviews into positive, negative, question, or needs a reply, so nothing important gets buried in a pile you were never going to read in full anyway.

A quick way to check if your use-case need Jev : Can the answer be one item picked from a short list? If yes, it fits. If the answer actually needs a sentence or two of explanation, that's still a job for LLM.

How to start?

If you want to actually try it, the path is short:

Try Jev at typesafe.ai
Try it in the playground first, give it a situation and three or four options, and see what it picks
Move to the API once you've seen one decision work the way you expect
Start with something small and repetitive, not your hardest decision. Pick the boring one you make fifty times a day

At $0.042 per million input tokens with free output, testing this costs close to nothing.

For reference you can check what people are already building using Jev here.

When not to use Jev?

A few situations where you still have to use LLM:

You need actual text back. Emails, summaries, explanations, and other generated content are still better suited to LLMs.
You can't define the possible outputs. Jev works with predefined decisions such as yes/no, choices, or scores, so the decision needs to be structured ahead of time.
The decision is genuinely high stakes. For money, health, or legal outcomes, use Jev to sort, score, or prioritize, but keep a person involved in the final decision.
You haven't tested it on your own data. Before relying on Jev in production, test it against real examples from your use case and see where it gets decisions right or wrong.

Conclusion

Jev isn't trying to replace GPT or Claude. LLMs are still the better fit when you need writing, explanation, or open-ended reasoning.

Jev targets a different problem: decisions that software needs to make repeatedly. For true/false checks, classification, routing, scoring, and verification, returning a typed decision and confidence score can be more useful than generating text that your code then has to parse.

It won't outperform LLMs at every decision task, but its combination of structured outputs, speed, cost, and calibrated confidence makes it an interesting new primitive for building AI-powered software.

Build a Real-Time Excalidraw-like Collaborative Canvas using Velt MCP and Antigravity🎉

Astrodevil — Thu, 21 May 2026 16:43:40 +0000

In this tutorial, we’ll build an Excalidraw-style collaborative whiteboard using Next.js, HTML5 Canvas, and Velt. You’ll add real-time features like live cursors, comments, presence, and huddles directly into your app. Instead of wiring everything manually, we’ll use Velt MCP and AI agents to handle the integration. We’ll also look at how CRDT-based sync keeps everything in real time.

By the end, you’ll have a fully working multi-user canvas app with production-ready collaboration built in.

What we are building

Excalidraw-style infinite whiteboard
Real-time collaboration with cursors, comments, huddle, notifications, and presence
Multi-user canvas with shared state

Why add collaboration to Canvas apps

Single-user by default: Most canvas apps work locally and don’t support multiple users out of the box
Real-time sync is complex: Handling state sync, conflicts, and updates across users is not trivial
Lack of shared context: Without comments, cursors, and presence, collaboration feels disconnected

Why use Velt

Velt is a collaboration SDK that lets you add real-time, multi-user features directly into your app without building the backend infrastructure yourself. It handles presence, syncing, communication, and UI components out of the box, so you can focus on your product.

Drop-in collaboration layer: Add features like comments, cursors, and presence without building from scratch
Real-time features built in: Cursors, comments, presence, notifications, and huddles
CRDT-based sync support: Enables conflict-free real-time state updates for multi-user apps
AI-powered setup with MCP: Use Velt MCP and agent skills to automatically install and configure features
No infra needed: No need to manage WebSockets, sync engines, or backend services
Customizable UI components: Easily integrate collaboration UI into your existing design system

Prerequisites

Node.js 18+
Velt API key (from Velt dashboard)
AI coding editor (Anitgravity is used in this demo)
Basic React and TypeScript knowledge

Setting up the project

Clone the repository - https://github.com/Studio1HQ/Velt-Demos/tree/main/excalidraw-velt-demo
Run npm install
And then run npm run dev
Now, open http://localhost:3000

Tutorial: Building Velt-powered Excalidraw-like App

Step 1: Set up Velt MCP

Velt MCP lets your editor (Antigravity) run the Velt installer and guide the integration.

Now, add the Velt MCP installer to Antigravity using the command below:

npx -y @velt-js/mcp-installer

Add it to the Antigravity MCP server configuration with command: "npx" and args: ["-y", "@velt-js/mcp-installer"].

Also, Velt Agent Skills guides the AI on what to implement using best practices, while MCP gives it access to the tools needed to actually execute those changes. Together, they make the integration accurate, structured, and reliable. We have both installed and will be used accordingly.

Get your Velt API key:

Go to the Velt Dashboard
Create a project
Copy your API key

Add it to your .env:

NEXT_PUBLIC_VELT_API_KEY=your_api_key_here

Step 2: Start Velt installation using AI

Now that MCP is set up, we can let the AI agent handle the Velt integration for us.

Open your editor (Antigravity) and type:

install velt

This triggers the Velt MCP installer, which runs as a guided setup inside your editor.

Instead of manually adding SDKs and wiring things, the agent walks you through the setup step by step.

It will ask you for a few inputs:

Your project directory
Your Velt API key and auth token
The features you want to enable (comments, presence, cursors, CRDT, etc.)
Where to place the VeltProvider (recommended: app/page.tsx)
UI placement preferences (like corner position)

You can answer each step directly in chat. The flow is simple and guided.

Step 3: Provide the prompt for MCP

At this point, we already have a working whiteboard built manually. Now, instead of integrating Velt step by step ourselves, we use Velt Agent Skills to analyze this existing app and plan how collaboration should be added.

In your editor, after running install velt, provide the following prompt:

I want to start the Velt integration. Review my project structure and use your Velt Agent Skills to plan the CRDT store implementation.

Once you provide this, the agent starts analyzing your codebase. It looks at how your canvas is structured, how state is managed, and where real-time sync can be introduced. Based on this, it generates an integration plan tailored to your whiteboard.

Instead of manually deciding how to structure CRDT or where to wire Velt, the agent uses its skills to plan it correctly for your app.

After reviewing the plan, you can approve it, and the agent will apply the changes step by step.

Step 4: Understand the existing project structure

Before we look at what MCP added, let us understand how this project is structured. Since the agent analyzes your codebase before integrating Velt, this gives context for what it is working with.

The project is organized into three main folders: app, components, and lib.

The app/ folder contains the core application logic. This is where the whiteboard is rendered and all canvas interactions like drawing, selecting, and updating elements are handled.
The components/ folder contains UI elements and collaboration integrations. This is where Velt features are connected to your app, including user identity, comments, and UI-level controls.
The lib/ folder handles state management and shared logic. It manages canvas data, document context, and sync-ready state, making it easier to extend the app with real-time collaboration.

Step 5: Add real-time collaboration features (Using MCP)

Now that the whiteboard is working, we layer Velt on top to make it collaborative. This is where users start seeing each other, interacting in real time, and sharing context.

After you provide the prompt and approve the plan, the MCP installer integrates Velt into your project. It sets up the foundation required for collaboration to work correctly with your existing whiteboard.

Presence and cursors

In app/layout.tsx, the VeltProvider enables real-time awareness across your app. Then in VeltSetup.tsx, each user is identified using. This is what allows Velt to track who is online.

Learn more here

'use client'
import React, { useEffect, useState, Suspense } from "react";
import {
  VeltProvider,
  useSetDocument,
  VeltCursor,
  useVeltClient,
} from "@veltdev/react";
import { useCurrentDocument } from "@/lib/useCurrentDocument";
import { TEST_USERS } from "@/lib/users";
import { useSearchParams } from "next/navigation";

function VeltIdentity({ children }: { children: React.ReactNode }) {
  const { documentId } = useCurrentDocument();
  useSetDocument(documentId ?? "default-whiteboard");
  return <>{children}</>;
}

function VeltProviderInner({ children }: { children: React.ReactNode }) {
  const searchParams = useSearchParams();
  const [user, setUser] = useState(TEST_USERS[0]);

  useEffect(() => {
    const userIndex = searchParams.get("user");
    if (userIndex) {
      const index = parseInt(userIndex);
      if (!isNaN(index) && TEST_USERS[index]) {
        setUser(TEST_USERS[index]);
      }
    } else {
      // Fallback or default behavior
    }
  }, [searchParams]);

  return (
    <VeltProvider
      apiKey={process.env.NEXT_PUBLIC_VELT_API_KEY!}
      authProvider={{
        user: user,
      }}
    >
      <VeltIdentity>
        {/* <VeltCursor /> */}
        {children}
      </VeltIdentity>
    </VeltProvider>
  );
}

export function VeltSetup({ children }: { children: React.ReactNode }) {
  return (
    <Suspense fallback={null}>
      <VeltProviderInner>{children}</VeltProviderInner>
    </Suspense>
  );
}

Once identity is set, Velt automatically shows:

Active users (avatars)
Live cursor positions

You don’t have to manually sync cursor movement. Velt handles that internally based on user sessions.

Canvas comments

Comments are one of the most important parts of a canvas app.

"use client";

import { useCommentAnnotations, VeltCommentPin } from "@veltdev/react";
import { Point } from "@/lib/types";
import { useWhiteboardStore } from "@/lib/useWhiteboardStore";

interface CanvasCommentLayerProps {
  zoom: number;
  pan: Point;
}

In CanvasCommentLayer.tsx, comments are rendered as an overlay on top of the canvas. Instead of attaching comments to DOM elements, we attach them to canvas coordinates.

 {
              // Use bounds or specific fields
              // Normalized rect provided by normalizeRect helper? not available here easily.
              // Just use raw coords if available, or approximate.
              // Rect/Ellipse/Diamond have x1,y1,x2,y2 usually?
              // Wait, types.ts says DrawingElement...
              // Let's assume standard shape properties
              if (
                "x1" in element &&
                "y1" in element &&
                "x2" in element &&
                "y2" in element
              ) {
                worldX = (element.x1 + element.x2) / 2;
                worldY = (element.y1 + element.y2) / 2;
              }
            } else if (element.type === "line" || element.type === "arrow") {
              worldX = (element.x1 + element.x2) / 2;
              worldY = (element.y1 + element.y2) / 2;
            }
          }
        }

        if (typeof worldX !== "number" || typeof worldY !== "number") {
          return null;
        }

        const screenX = (worldX + pan.x) * zoom;
        const screenY = (worldY + pan.y) * zoom;

        return (
          <div
            key={annotation.annotationId}
            style={{
              position: "absolute",
              left: `${screenX}px`,
              top: `${screenY}px`,
              transform: "translate(-50%, -100%)",
              zIndex: 50,
              pointerEvents: "auto",
            }}
          >
            <VeltCommentPin annotationId={annotation.annotationId} />
          </div>
        );
      })}
    </div>
  );

From app[/page.tsx](https://github.com/Studio1HQ/Velt-Demos/blob/main/excalidraw-velt-demo/app/page.tsx), you trigger comments like this:

Capture the (x, y) position on click
Pass context to Velt
Optionally attach to a specific element using elementId

This enables:

Freeform comments anywhere on the canvas
Context-aware discussions linked to shapes

This is very similar to how tools like Miro or Figma handle comments.

Sidebar and UI controls

These files handle user-facing UI around collaboration.

ProfileMenu.tsx shows user identity and active participants
ThemeToggle.tsx syncs your app theme with Velt UI

ProfileMenu.tsx

"use client";

import React, { useEffect, useState } from "react";
import { ChevronDown, User, Check, LogOut, RefreshCwIcon } from "lucide-react";
// import { useVeltClient } from "@veltdev/react";
import { TEST_USERS } from "@/lib/users";

export function ProfileMenu() {
  const [isOpen, setIsOpen] = useState(false);
  const [currentUser, setCurrentUser] = useState(TEST_USERS[0]); // Default to first user

  // Initialize from URL on mount
  useEffect(() => {
    const params = new URLSearchParams(window.location.search);
    const userIndex = params.get("user");
    if (userIndex) {
      const index = parseInt(userIndex);
      if (!isNaN(index) && TEST_USERS[index]) {
        setCurrentUser(TEST_USERS[index]);
      }
    }
  }, []);

  const handleUserSelect = (user: (typeof TEST_USERS)[0], index: number) => {
    setCurrentUser(user);
    setIsOpen(false);

    // Update URL and reload to ensure clean session isolation via VeltProvider authProvider
    const url = new URL(window.location.href);
    url.searchParams.set("user", index.toString());
    window.location.href = url.toString();
  };

Velt components (like comments sidebar) automatically adapt to your app’s theme. This keeps the experience consistent across your UI and Velt overlays.

Notifications and huddle

Velt also provides built-in tools for:

You can add these as UI buttons in your toolbar. Once added:

Notifications show real-time updates (comments, mentions, etc.)
Huddle lets users start live audio/video sessions inside your app

No extra backend setup is needed. These features are already part of the Velt SDK.

You can see this here in page.tsx

 <div className="mx-1 h-6 w-px bg-slate-200 dark:bg-neutral-800" />
        <div className="flex items-center gap-1">
          <VeltCommentTool darkMode={isDark} />
          <VeltHuddleTool darkMode={isDark} />
          <VeltNotificationsTool darkMode={isDark} />
        </div>
      </section>

Step 6: CRDT-based state sync

Up to this point, the whiteboard works, and collaboration features like comments and presence are in place. But for a real collaborative canvas, the most important piece is shared state. Every shape, line, or text element needs to stay in sync across all users in real time.

This is where CRDT comes in.

In a typical canvas app, state lives locally. When a user draws something, it updates only their view. To make this collaborative, we need a shared state that all users can read and write to.

In useWhiteboardStore.ts, instead of using local state, we use Velt’s CRDT hook:

This creates a shared store that is automatically synced across all connected users.

The id acts as a unique identifier for this piece of state. As long as users are in the same document, they are all connected to this store. The map structure is used to store canvas elements, where each element is indexed by its ID.

"use client";

import { useCallback, useEffect, useMemo, useRef } from "react";
import { useVeltCrdtStore } from "@veltdev/crdt-react";
import type { DrawingElement } from "./types";

type ElementMap = Record<string, DrawingElement>;

export function useWhiteboardStore() {
  const { value, update } = useVeltCrdtStore<ElementMap>({
    id: "whiteboard-elements",
    type: "map",
    initialValue: {},
  });

  const elements: DrawingElement[] = useMemo(
    () => Object.values(value ?? {}).sort((a, b) => a.id.localeCompare(b.id)),
    [value],
  );

  const valueRef = useRef<ElementMap>(value ?? {});

  useEffect(() => {
    valueRef.current = value ?? {};
  }, [value]);

When a user draws a new shape or updates an existing one, the change is not stored locally. Instead, it is written to the CRDT store.

Functions like adding or updating elements internally call the update function provided by useVeltCrdtStore. Once updated, the change is automatically propagated to every other user connected to the same session.

const addElement = useCallback(
    (el: DrawingElement) => {
      update({ ...valueRef.current, [el.id]: el });
    },
    [update],
  );

  const updateElement = useCallback(
    (el: DrawingElement) => {
      update({ ...valueRef.current, [el.id]: el });
    },
    [update],
  );

  const deleteElement = useCallback(
    (id: string) => {
      const next = { ...valueRef.current };
      delete next[id];
      update(next);
    },
    [update],
  );

  return { elements, addElement, updateElement, deleteElement, rawMap: value };

There is no need to manage WebSockets, events, or manual syncing. Velt handles all of that behind the scenes.

The storageProxy.ts file acts as a thin abstraction layer between your canvas logic and the shared store. Instead of directly interacting with the CRDT store everywhere, this layer helps keep the code clean and organized.

It separates:

Canvas logic
State update logic

This makes the system easier to maintain and extend.

"use client";

/**
 * Validates if the code is running in a browser environment
 */
const isBrowser = typeof window !== "undefined";

/**
 * Proxies localStorage to redirect specific keys to sessionStorage
 * This allows Velt to have isolated sessions per tab (using sessionStorage)
 * while the rest of the app continues to use localStorage.
 */
export function initStorageProxy() {
  if (!isBrowser) return;

  // Store the original localStorage implementation
  const originalLocalStorage = window.localStorage;
  const originalSessionStorage = window.sessionStorage;

  // Keys that should be redirected to sessionStorage
  // Velt uses keys starting with 'velt', 'snippyly', or '_v' (e.g., _viu, _vv)
  // Also proxying firebase keys as Velt likely uses them for auth/presence
  const isVeltKey = (key: string) => {
    const k = key.toLowerCase();
    return (
      k.startsWith("velt") ||
      k.startsWith("snippyly") ||
      k.startsWith("_v") ||
      k.startsWith("firebase")
    );
  };

Step 7: Multi-user simulation

The user setup lives in lib/users.ts. This file defines a small set of users with basic details like name, color, and avatar. These are used by Velt to represent each participant across features like cursors, comments, and presence.

In components/velt/VeltSetup.tsx, one of these users is selected when the app loads. A random user is picked and passed to Velt. This is what establishes the session.

export const TEST_USERS = [
  {
    userId: "user1",
    name: "Robin",
    email: "robin@velt.dev",
    photoUrl:
      "https://images.unsplash.com/photo-1500648767791-00dcc994a43e?w=800&auto=format&fit=crop&q=60&ixlib=rb-4.1.0&ixid=M3wxMjA3fDB8MHxzZWFyY2h8Mnx8cG9ydHJhaXR8ZW58MHx8MHx8fDA%3D",
    color: "#F97316", // Orange
    organizationId: "excalidraw-demo",
  },
  {
    userId: "user2",
    name: "Alicia",
    email: "alicia@velt.dev",
    photoUrl:
      "https://images.unsplash.com/photo-1531746020798-e6953c6e8e04?q=80&w=1364&auto=format&fit=crop&ixlib=rb-4.1.0&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D",
    color: "#3B82F6", // Blue
    organizationId: "excalidraw-demo",
  },
];

Every time the app loads, a different user can be assigned. From Velt’s perspective, each session is now a unique participant in the same document.

Step 8: Run and test the app

Now let’s run the app and see everything working together.

Start the development server:

npm run dev

Once the app is running, open it in your browser at http://localhost:3000.

To test collaboration, open the same app in another window. You can use an incognito tab or a different browser. Each session will act as a different user.

As you interact with the canvas, you’ll start noticing the real-time behavior. Drawing a shape in one window reflects instantly in the other. You’ll see users appearing in presence, and comments syncing across both sessions.

At this point, your whiteboard is fully collaborative, with multiple users interacting on the same canvas in real time.

Here is the deployed link for you to explore the demo.

Wrapping up

We started with a simple canvas and turned it into a fully collaborative whiteboard. Along the way, we added real-time cursors, presence, comments, notifications, and even voice huddles using Velt. Instead of building sync logic and infra from scratch, we used Velt MCP and agent skills to handle the heavy lifting and get everything working quickly.

The key takeaway here is simple. You don’t need to spend weeks building real-time systems to make your app collaborative. With the right tools, you can focus on your product and let the platform handle sync, presence, and communication.

From here, you can extend this further:

Connect real authentication instead of simulated users
Improve CRDT logic for more complex canvas operations
Customize Velt UI components to match your product

If you’re building any product where users need to collaborate, this is a pattern worth exploring.

What would your app look like if it supported real-time collaboration from day one?

Try Velt and start adding features like comments, presence, cursors, CRDT sync, notifications, and huddles to your app.

Building a Zulip Style Collaborative Chat App with Next.js and Velt

Astrodevil — Tue, 05 May 2026 17:43:33 +0000

Zulip is known for keeping conversations organized. Topic-based threads, clear context, and async-friendly discussions make it a favorite for technical and distributed teams. Unlike traditional chat apps, conversations in Zulip stay readable even as teams scale.

Recreating this experience can be a bit difficult. Real-time messaging, user presence, inline comments, and notifications usually require a complex backend and real-time infrastructure.

In this tutorial, we will build a Zulip-style collaborative chat application using Next.js, Tailwind CSS, and Velt. Next.js powers the UI and application structure, while Velt adds collaboration features like presence, comments, and notifications without writing backend code.

By the end, you will have a working chat interface inspired by Zulip, with real-time collaboration built in and ready to extend.

Why Zulip’s Approach Works

Zulip’s design solves a problem most chat tools struggle with: conversations getting messy over time.

Instead of long, linear message streams, Zulip organizes discussions into topics. Each message belongs to a clear context, so conversations stay focused and easy to follow even days or weeks later.

Three ideas make this work especially well:

Real-time collaboration: Messages, comments, and updates appear instantly for everyone in the channel.
Context-rich discussions: Replies stay tied to a specific topic or message, so feedback does not get lost in the noise.
Visible presence: You always know who is online and actively participating, which makes collaboration feel immediate and shared.

What makes this challenging to build in a SaaS product is not the UI, but the infrastructure behind it. Real-time messaging, presence tracking, comments, and notifications typically require WebSockets, backend event systems, data synchronization, and careful handling of concurrent users. Building and maintaining this reliably can take significant engineering effort.

In this tutorial, we recreate Zulip’s collaborative behavior without building that infrastructure ourselves, by using Velt as the collaboration layer.

What We’re Building With

Before we dive into the code, let’s quickly look at the tools we’ll use and why they fit this project well.

Next.js: Next.js gives us a solid foundation for building interactive applications. With the App Router, we get a clean layout structure and client-side interactivity that works well for chat-style interfaces.
React: React handles the UI composition and state updates. The chat interface, message list, and user interactions all rely on simple, predictable React patterns.
Tailwind CSS: Tailwind helps us build a clean and modern UI quickly. It keeps styling close to the components and makes it easy to adjust layouts, spacing, and themes without writing custom CSS.
shadcn ui (powered by Radix UI): These provide accessible, reusable UI primitives like buttons, dropdowns, and avatars. They give us a polished look without locking us into heavy component libraries.
Zustand: Zustand is used for lightweight state management. In this project, it manages demo users and allows us to switch between them to test real-time collaboration.
Velt: Velt is the key piece. Instead of building real-time infrastructure ourselves, Velt provides presence, comments, notifications, and collaboration out of the box. Once integrated, features like reactions, read status, and threaded comments work automatically without writing extra backend or real-time code.

Together, this stack lets us focus on the chat experience and UI, while Velt handles the collaboration layer behind the scenes.

Prerequisites

To follow along with this tutorial, you’ll need:

Node.js (v16 or later) installed on your machine
Basic familiarity with Next.js, React, and TypeScript
A Velt account (you can sign up for free at velt.dev)
Working knowledge of Tailwind CSS fundamentals

You do not need:

Prior experience with Velt
Any backend or database setup
Experience building real-time systems

We’ll walk through the collaboration setup step by step, and the app runs entirely on the frontend.

Project Setup

Instead of scaffolding a new project from scratch, we’ll start from an existing Zulip style chat app that already has the UI and collaboration logic wired up. This lets us focus on understanding how the pieces fit together.

Clone the Repository

Begin by cloning the project and moving into the directory:

gitclone https://github.com/Studio1HQ/zulip-velt
cd zulip-velt

Install Dependencies

Install all required dependencies using npm:

npm install

This will install Next.js, Tailwind CSS, shadcn ui components, Zustand for state management, and the Velt SDK used for collaboration features.

Configure the Velt API Key

Velt requires a public API key to enable collaboration features like presence, comments, and notifications.

Create a .env.local file in the root of the project and add:

NEXT_PUBLIC_VELT_ID=your_velt_api_key_here

You can generate this key from the Velt dashboard after creating a free account.

Once the key is added, restart the development server if it is already running.

Run the App Locally

Start the development server:

npm run dev

Open your browser and visit:

http://localhost:3000

You should now see a Zulip-style chat interface with channels on the left, a message area in the center, and collaboration controls in the header.

At this point, the UI is already functional. In the next sections, we’ll break down how the app is structured and how Velt is integrated to power real-time collaboration without any backend setup.

Project Setup

At a high level, the project is divided into five main parts:

app: Handles routing, layouts, and global configuration using the Next.js App Router
components: Contains all reusable UI and chat-related components
helper: Manages demo user data and user switching logic
hooks: Stores custom React hooks such as theme management
lib: Holds small utility functions used across the app

Let’s take a closer look at the most important folders we’ll work with in this tutorial.

Understanding the App Router and Layout Setup

This project uses the Next.js App Router, which organizes the application using layouts and pages instead of traditional route files. If you are new to the App Router, don’t worry. We’ll focus only on what matters for this app.

The key idea is simple: layouts wrap pages, and this is where we place Velt and theme handling.

In this project, there are two layout files, each with a different responsibility.

layout.tsx is the root layout for the entire application. It defines the HTML structure, metadata, and global styles.

"use client";

import { ThemeProvider } from "@/hooks/use-theme";
import { VeltProvider } from "@veltdev/react";

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <VeltProvider apiKey={process.env.NEXT_PUBLIC_VELT_ID || ""}>
      <ThemeProvider>{children}</ThemeProvider>
    </VeltProvider>
  );
}

page.tsx - This file renders the main chat interface. You’ll see it importing layout and chat components and placing them on the page.

"use client"

import { useState, useEffect } from 'react'
import { Header } from '@/components/layout/header'
import { Sidebar } from '@/components/layout/sidebar'
import { ChatArea } from '@/components/chat/chat-area'

export default function Home() {
  const [isSidebarOpen, setIsSidebarOpen] = useState(true)
  const [isSidebarCollapsed, setIsSidebarCollapsed] = useState(false)
  const [isMobile, setIsMobile] = useState(false)

  useEffect(() => {
    const checkMobile = () => {
      const mobile = window.innerWidth < 768
      setIsMobile(mobile)
      if (mobile) {
        setIsSidebarOpen(false)
        setIsSidebarCollapsed(false)
      }
    }

    checkMobile()
    window.addEventListener('resize', checkMobile)
    return () => window.removeEventListener('resize', checkMobile)
  }, [])

  const toggleSidebar = () => {
    if (isMobile) {
      setIsSidebarOpen(!isSidebarOpen)
    } else {
      if (isSidebarCollapsed) {
        setIsSidebarCollapsed(false)
      } else if (isSidebarOpen) {
        setIsSidebarCollapsed(true)
      } else {
        setIsSidebarOpen(true)
      }
    }
  }

  const closeSidebar = () => {
    if (isMobile) {
      setIsSidebarOpen(false)
    }
  }

  return (
    <div className="h-screen flex flex-col bg-background">
      <Header 
        onToggleSidebar={toggleSidebar}
        isSidebarOpen={isSidebarOpen}
        isMobile={isMobile}
      />
      <div className="flex-1 flex overflow-hidden">
        <Sidebar 
          isOpen={isSidebarOpen}
          isCollapsed={isSidebarCollapsed}
          isMobile={isMobile}
          onClose={closeSidebar}
        />
        <ChatArea />
      </div>
    </div>
  )
}

app/layout.tsx is the global shell
app/(app)/layout.tsx is where Velt is initialized
page.tsx is where the chat UI begins
Providers are placed at layout level so all components can access them

Building the Chat Interface with Components

Most of the Zulip-style experience in this app is built using reusable React components. Each part of the interface has a clear responsibility, which makes the code easier to read and extend.

We’ll focus on three areas:

The chat area where messages appear
The message component itself
The layout components that shape the overall UI

Chat Area:

chat-area.tsx - This component is responsible for rendering the list of messages and attaching collaboration features to them.

message.tsx - Each message in the chat is rendered as its own component. This keeps the UI modular and makes it easy to attach collaboration features at the message level.

Layout Components:

The layout of the app is built using two main components: a header and a sidebar.

The sidebar represents Zulip style channels and navigation.
The header is where collaboration controls live.

Inside the header, you’ll see Velt components like:

<VeltPresence />
<VeltNotificationsTool />
<VeltCommentsSidebar />
<VeltSidebarButton />

What these do:

VeltPresence shows who is currently online
VeltNotificationsTool displays collaboration notifications
VeltCommentsSidebar Opens a panel with all comments
VeltSidebarButton toggles the comments sidebar

All of these work automatically once Velt is initialized at the layout level.

import {
  VeltPresence,
  VeltNotificationsTool,
  VeltSidebarButton,
  VeltCommentsSidebar,
  useVeltClient,
} from "@veltdev/react";
import { names, userIds, useUserStore } from "@/helper/userdb";

interface HeaderProps {
  onToggleSidebar: () => void;
  isSidebarOpen: boolean;
  isMobile: boolean;
}

export function Header({
  onToggleSidebar,
  isSidebarOpen,
  isMobile,
}: HeaderProps) {
  const { theme } = useTheme();
  const { user, setUser } = useUserStore();
  const { client } = useVeltClient();
  const prevUserRef = useRef(user);
  const isInitializingRef = useRef(false); // Prevent overlapping initialization calls

Client Initialization, User Identification, and Document Setting

 // Handle Velt client initialization, user identification, and document setting
  useEffect(() => {
    if (!client || !user || isInitializingRef.current) {
      console.log("Velt init skipped:", {
        client: !!client,
        user: !!user,
        initializing: isInitializingRef.current,
      });
      return;
    }

    const initializeVelt = async () => {
      isInitializingRef.current = true;
      try {
        // Detect user switch
        const isUserSwitch = prevUserRef.current?.uid !== user.uid;
        prevUserRef.current = user;

        console.log("Starting Velt init for user:", user.uid, { isUserSwitch });

        // Re-identify the user (handles initial and switches)
        const veltUser = {
          userId: user.uid,
          organizationId: "organization_id",
          name: user.displayName,
          email: user.email,
          photoUrl: user.photoUrl,
        };
        await client.identify(veltUser);
        console.log("Velt user identified:", veltUser.userId);
        await client.setDocuments([
          {
            id: "zulip-velt",
            metadata: { documentName: "zulip-velt" },
          },
        ]);
        console.log("Velt documents set: zulip-velt");
      } catch (error) {
        console.error("Error initializing Velt:", error);
      } finally {
        isInitializingRef.current = false;
      }
    };

    initializeVelt();
  }, [client, user]); // Re-run on client or user change

Reusable UI Components

To keep the chat interface clean and consistent, this project uses a set of reusable UI components. These components handle common UI patterns like buttons, inputs, avatars, and scroll areas.

Instead of building these from scratch, the project uses shadcn ui, which is a collection of accessible, unstyled components built on top of Radix UI. This approach gives us flexibility while keeping the UI consistent.

All reusable UI components live inside the components/ui folder.

Reusable UI primitives: Shared building blocks like buttons, inputs, avatars, and dropdowns used across the app to keep styling consistent.
Built with shadcn ui (powered by Radix UI): Accessible, unstyled components that provide behavior and keyboard support without locking the design.
Scroll handling for chat: The ScrollArea component manages smooth scrolling for long message lists in the chat view.
Separation of concerns: UI components handle appearance and interaction, while chat and layout components focus on structure and logic.
Easy to extend and customize: Updating a UI component in this folder automatically updates its usage across the entire app.

User Management for Collaboration Testing

To test real-time collaboration features like presence, comments, and notifications, we need a way to simulate multiple users. Instead of setting up a full authentication system, this project uses a simple and beginner-friendly approach with predefined users.

User state is managed using Zustand, a lightweight state management library.

import { create } from "zustand";
import { persist } from "zustand/middleware";

export type User = {
  uid: string;
  displayName: string;
  email: string;
  photoUrl?: string;
};

export interface UserStore {
  user: User | null;
  setUser: (user: User) => void;
}

export const userIds = ["user001", "user002"];
export const names = ["Nany", "Mary"];

export const useUserStore = create<UserStore>()(
  persist(
    (set) => ({
      user: null,
      setUser: (user) => set({ user }),
    }),
    {
      name: "user-storage",
    }
  )
);

Theme Management with `useTheme`

Modern apps usually support both light and dark themes, and this project follows the same pattern. Theme state is managed using a custom React hook, which keeps the logic reusable and easy to maintain.

The theme logic lives inside a single file.

The theme is:

Stored in React state
Loaded from localStorage on page load
Saved back to localStorage when changed

This ensures the user’s theme preference persists across page refreshes.

Syncing Theme with Velt

The theme value is also passed to Velt components, allowing them to automatically switch between light and dark modes.

This means:

The app UI and Velt UI stay visually consistent
No extra styling logic is required for collaboration components
Once the hook is set up, theme changes propagate everywhere.

Utility Functions

The lib folder contains small helper utilities that are shared across the application. In this project, it mainly exists to support reusable UI components and keep common logic out of individual files. The utilities in this file are primarily related to class name handling. When working with Tailwind CSS and reusable components, it’s common to conditionally apply multiple class names.

Running the App and Testing the Output

Now that we’ve walked through the project structure and key files, it’s time to run the app and verify that everything works as expected.

Seeing the app in action makes the collaboration features easier to understand in the next sections.

From the project root, run:

npm run dev

Once the server starts, open your browser and navigate to:

http://localhost:3000

You should see a Zulip style chat interface with:

A sidebar for channels
A header with user controls
A central chat area for messages

To test collaboration features, open the app in two browser windows or one normal window and one incognito window.

Use the user switcher in the header to change between demo users such as Nany and Mary.

Each window should represent a different user.

Try the following actions:

Presence: Notice user avatars appear in the header when multiple users are online.
Comments: Hover over a message and add a comment. The comment should appear instantly in both windows.
Notifications: Add a comment in one window and check the notification bell in the other.
Theme Switching: Toggle between light and dark mode and observe that both the app and Velt components update correctly.

How It Works

Here’s a simple view of what happens when the app runs:

The app loads and initializes Velt using the API key in the layout
A demo user is selected using the Zustand store
Velt identifies the active user and associates them with the app
A shared document context is set for collaboration
Messages render in the chat area
Comments, presence, and notifications are automatically tracked by Velt
Updates sync instantly across all connected clients

The key idea is that the app focuses on UI and user flow, while Velt handles real-time synchronization and collaboration logic.

Collaborative Features You Get Automatically

Once Velt is integrated, collaboration features start working without writing additional backend or real-time code.

These features are available out of the box:

Inline comments: Add comments directly on chat messages and view them in context.
User presence: See who is currently online and active in the chat.
Notifications: Get notified when someone comments or interacts.
Reactions and comment status: React to comments and mark them as resolved or active.
Read awareness: See when comments have been viewed by other users.

All of these features work automatically once Velt is set up.

Things to Note Before Shipping to Production

Before using this setup in a real product, keep the following in mind:

Replace demo users with a real authentication system
Identify users using real user IDs and metadata
Use dynamic document IDs instead of a hardcoded value
Add permissions to control who can view or comment
Handle error states when collaboration services are unavailable
Review Velt customization options to match your product UI
Test performance with multiple concurrent users

These steps ensure the app scales safely beyond a demo environment.

Demo Video

You can see the completed Zulip style chat app with real-time collaboration in action here:

Live Demo:

https://zulip-velt-chat.vercel.app/

This demo shows user switching, comments, presence, notifications, and theme support working together.

Conclusion

Zulip demonstrates how powerful chat can be when collaboration is built into the experience. Organized conversations, clear context, and real-time awareness turn chat from simple messaging into a system teams can rely on.

For builders, the real challenge is not the UI. It is the collaboration layer behind it. Features like real-time sync, presence tracking, inline comments, notifications, and reactions usually require complex infrastructure and long development cycles. This is especially true when building a chat-based SaaS product.

In this tutorial, we focused on that exact problem. Instead of rebuilding collaboration from scratch, we showed how to add Zulip-style collaborative features inside a chat application using Next.js and a modern frontend stack, while delegating the hard real-time problems to Velt.

The result is a working chat app where collaboration feels native, but the code stays simple and frontend-focused.

Key Takeaways

Clean component structure makes complex apps easier to understand
Collaboration does not need custom real-time infrastructure
Velt enables comments, presence, notifications, and more out of the box
Frontend-focused development speeds up experimentation and iteration

If you are building a chat app, internal tool, or collaborative product, Velt lets you focus on your core experience instead of infrastructure.

Try building with Velt and add collaboration to your app in minutes at velt.dev.