DEV Community: Studio1

How to Write a Developer Tutorial That People Actually Finish

Nancy Garg — Mon, 09 Nov 2026 17:37:42 +0000

TL;DR

A developer tutorial gets finished when it has one clear outcome, a fast first win, and code that works the first time.

Pick one outcome, name it in the title, and show the finished result in the first screen.
Get readers to something visible in the first five minutes. Keep every step small enough to check.
Cut the theory and link to it. A tutorial teaches by doing, and explanations belong on another page.
Test the whole thing on a clean machine. Put the version and date at the top.
Measure drop-off by step, not by page views.

Why does tutorial quality matter more now?

Developers still learn from docs first, but they now have a faster option sitting next to them. In the Stack Overflow 2025 Developer Survey results, technical documentation was the top resource for learning to code at 68%. Yet 44% of developers now use AI tools to learn too, up from 37% the year before.

So your tutorial competes with a chatbot that answers in two seconds. If your reader has to guess, wait, or fix your typo, they close the tab and ask the bot.

This guide shows how to write a tutorial that people read to the end. Every number links to its source. One honest note: I could not find a trustworthy industry-wide completion rate for tutorials, so I won't make one up. What we do have is solid data on why developers get stuck, and it all points the same way.

What is a developer tutorial, and how is it different from a how-to guide?

A developer tutorial is a guided lesson where the reader builds one small, working thing and learns by doing it. A how-to guide is for someone who already knows what they want. Most weak tutorials are really a mix of both.

Diátaxis, a documentation framework many teams use, splits docs into four kinds:

Type	Reader's mood	Example title
Tutorial	"I want to learn"	Build a link shortener from scratch
How-to guide	"I have a job to do"	How to rotate an API key
Reference	"I need one fact"	POST /links parameters
Explanation	"I want to understand"	Why we use signed URLs

The Diátaxis tutorial page opens with a rule that sounds odd at first: don't try to teach. Your job is to give the reader an experience they can learn from. Once you write that way, the rest gets easier.

Why do developers quit tutorials?

Developers quit when something is missing, wrong, or slow, and they scan instead of reading. Here is what the data says.

What was measured	Result	Source
Teams reporting documentation gaps	55% of respondents	Postman 2025 State of the API (5,700+ developers)
Biggest frustration with AI tools	66% said "almost right, but not quite"	Stack Overflow 2025 survey
How people read a new web page	79% scan, 16% read word by word	Nielsen Norman Group (a 1997 study, but the behavior has held up)
Speed of a first API call	1.7x faster with a ready-made collection from the publisher	Postman

Three things follow from this.

Missing or sloppy docs are still common, so a tutorial that simply works stands out. AI answers that are almost right waste people's time, and a tested tutorial is the fix for that. And readers scan, so your headings, code blocks, and expected output carry more weight than your paragraphs.

Postman's team calls time to first call the most important API metric. The idea applies to any tutorial: the sooner someone sees something work, the more likely they are to keep going.

How to write a developer tutorial: a 9-step playbook

1. Pick one outcome and put it in the title

Name the thing the reader will build or do. "Build a background job queue from scratch" beats "Introduction to queues." If you can't say the outcome in one line, the tutorial is too big.

2. Show the finished result in the first two sentences

Tell people what they will have at the end, how long it takes, and what they need. Here is the difference.

A weak opening: In this tutorial, you will learn about queues, workers, and retries.

A strong one: By the end, you will have a small working app that runs a job in the background and prints "Job done" in your terminal. It takes about 20 minutes. You need a terminal and the language runtime you tested with, at the version you tested.

The strong version gives the reader a finish line. It also works as a standalone answer if a search engine or an AI assistant quotes it.

3. Keep prerequisites short and exact

List the tools and versions you tested with. Link to install pages instead of explaining installs. Every extra prerequisite loses a few readers before step one.

4. Make step one produce something visible

Don't spend the first five minutes on theory or config. Get a command running and a result on screen early. Diátaxis calls this delivering visible results early and often. Every step should produce a result the reader can see, even a small one.

5. One action per step, and say what they should see

This is the pattern to use for every step:

Step 3: Start the worker

Run this in a second terminal:

    [your start command]

You should see:

    Worker ready, waiting for jobs

The "You should see" line does most of the work. It lets readers catch a mistake right away instead of five steps later.

6. Cut explanations and link out

A tutorial is not the place for long explanations. Say what to do, say what happens, move on. Put the "why" in a separate explainer and link to it. Readers who want it will click. Readers who don't will keep going.

7. Give the full working code in one place

Link a repo or show the complete file at the end. Include imports and setup, with no "..." in the middle. If someone gets lost at step six, they can compare against the finished version and fix it themselves.

8. Show the errors people will hit

You can find where people get stuck by watching a few people test the tutorial. Put the exact error text in the tutorial with a one-line fix. People paste error messages straight into search and chat tools, so exact text also helps readers find you.

9. Test it on a clean machine, then date it

Run every step in a fresh container or a new user account. Your own laptop hides missing dependencies and old config. Then add the date and the tool versions at the top. A tutorial with no date reads like a risk.

How long should a developer tutorial be?

As long as the outcome needs, and no longer. If it can't be finished in one sitting, split it into parts, each with its own working result.

For search and AI answers, section size matters too. Studio1 pulled together data in its guide to developer docs and AEO showing that sections of roughly 120 to 180 words between headings did better than very short fragments. The same guide cites Ahrefs finding that 44.2% of AI citations came from the first 30% of a page, so put your best material up top.

How do you make a tutorial work for SEO and AI answers?

Keep it simple. Google's own guide to AI features and your website says there are no additional requirements to appear in AI Overviews or AI Mode. A page needs to be indexed and eligible to show with a snippet, and the usual SEO basics apply. The basics do the work:

Put the task in the title, in the words a developer would type. "How to build a webhook handler in Python" beats "Webhooks, Part 2."
Use question-style headings where they fit, like the ones on this page.
Answer first. The opening should still make sense if it is pulled out alone.
Keep code and output as plain text on the page, not in screenshots. Google also lists text availability as a basic.
Show an updated date, and keep it honest.

Studio1's data also showed pages updated in the last three months averaged 6 ChatGPT citations, against 3.6 for older pages. Those are links between traits and citations, not proof of cause. Still, it is a good reason to review your top tutorials every quarter.

Can you template tutorials for programmatic SEO?

Yes, with one rule: a template gives you the skeleton, not the content. "Build a job queue in Python," "in Go," and "in Ruby" can share the same structure. But each one needs its own tested code, its own errors, and its own output.

If two tutorials would read the same with one word swapped, don't publish both. Search engines and readers will skip the second one.

How do you know if people finish your tutorial?

Page views won't tell you. Track where people stop, not how many arrive. Try these instead:

Step-level drop-off. Track scroll depth or anchor clicks by heading. If half your readers vanish at step four, step four is broken.
Copy button clicks on your code blocks, by step.
Time to first success. If your tutorial ends in an API call, measure the gap between landing and that call. Postman's write-up on time to first call suggests using analytics for the objective number and usability tests for the human one.
Five real people. Watch five developers do it on a call, without helping. You will find problems in 20 minutes that analytics would take months to show.
Comments and issues. If the same error shows up twice, it belongs in the tutorial.

One warning: don't improve a time-to-success number by hiding the hard parts. You just move the friction to a later step.

What mistakes make developers abandon tutorials?

Starting with history, concepts, or architecture before anything runs.
Skipping the expected output, so readers can't tell if they're on track.
Code with gaps, or code that only works on your machine.
Mixing two goals, like teaching a concept and solving a task on the same page.
No versions and no date.
Offering three ways to do the same thing. In a tutorial, pick one.
Ending with nothing. Say what they built and link to the next page.

Pre-publish checklist

Does the title name one outcome?
Do the first two sentences say what the reader will have at the end?
Does step one show a visible result?
Does every step say what the reader should see?
Is the full working code in one place?
Did you run it on a clean machine this week?
Are the version and the date at the top?

FAQ

What is the best structure for a developer tutorial?

Outcome first, then prerequisites, then small steps that each end with visible output, then the full code and a pointer to what comes next. Keep theory on separate pages.

Should a tutorial explain why things work?

Barely. Diátaxis says a tutorial is for doing, and explanation belongs elsewhere. One sentence of context per step is plenty. Link to a deeper page for anyone who wants more.

Should I use video or text?

Text, with video as an extra. In the Stack Overflow 2025 survey, people learning to code leaned on YouTube more than working professionals did (70% vs 60%). But text can be searched, copied, and quoted, so the written version should stand on its own.

How often should I update a tutorial?

Check your most-read ones at least every three months, and any time a tool you use ships a major version. Only change the date when you actually changed the page.

Is a quickstart the same as a tutorial?

Not quite. A quickstart gets someone to a first success as fast as possible. A tutorial is a longer guided build. A good quickstart can lead into a tutorial, but they do different jobs.

How to Grow an Open Source Project: 12 Steps That Bring Real Users and Contributors

Nancy Garg — Thu, 05 Nov 2026 13:23:21 +0000

TL;DR

To grow an open source project, make it easy to understand in one minute, easy to try in five, and easy to contribute to in an afternoon. Then go to the places where your users already talk, reply fast, and share credit.

Most projects stall because people cannot tell what the project does or how to start, not because the code is weak.
A clear README, a short quickstart, and labeled beginner issues do more than any launch post.
A launch on Hacker News can bring a burst of stars, but replies, docs, and trust keep people around.
Plan for the maintainers too. Burnout ends more projects than bad code does.

Developers are building at a pace the world has never seen. GitHub's Octoverse 2025 report says a new developer joined GitHub every second on average, and about 230 new repositories were created every minute. It also says 63% of all repositories on GitHub are public or open source.

So your project is not just competing with other good ideas. It is competing with a flood of them, every minute of every day.

This guide walks through what actually helps an open source project grow, in plain steps you can start today. Every number links to where it came from.

What does it mean to grow an open source project?

Growing an open source project means more people use it, more people help build it, and a few of them stay long enough to share the load. Stars are a nice sign, but they are not the goal.

The Open Source Guides, written by GitHub, describe this as a funnel. People start as users, some become contributors, and a few become maintainers. Your job is to remove friction at every step so each person finds an easy first win.

Stage	What it looks like	What moves people forward
Visitor	Lands on your repo and decides in seconds	A clear one line pitch and a good README
User	Installs and tries it	A working quickstart and examples
Contributor	Files an issue or sends a fix	Labeled beginner tasks and fast replies
Maintainer	Reviews, releases, helps others	Trust, credit, and shared ownership

Keep that table in mind. Every step below fits into one of those rows.

How to grow an open source project: 12 steps

1. Say what it does in one sentence

Before anything else, you need a sentence a stranger can repeat. Who is it for, and what problem does it fix?

Open Source Guides suggest asking yourself what makes the project different and why you built it, then writing from the point of view of a user, not the builder. Try finishing this line: "My project helps X do Y without Z." If you cannot finish it, nobody else will be able to either.

Put that sentence at the top of your README, in your GitHub description, on your website, and in every post you write.

2. Make the README do the selling

Your README is your landing page. Treat it that way.

The numbers explain why. In GitHub's 2017 Open Source Survey, 93% of respondents said they had run into incomplete or outdated documentation. The same survey found that 60% of contributors say they rarely or never help with docs. That is a big gap, and it is your chance to stand out.

A README that works has:

The one-sentence pitch at the top.
A short code sample or screenshot showing the result.
Install steps that take under a minute.
A link to full docs.
The license.
A line on how to get help and how to contribute.

Open Source Guides has a simple walkthrough for writing a README if you want a starting point.

3. Add a license, a contributing file, and a code of conduct

These three files tell people it is safe to use your work and safe to join in. The same survey coverage notes that licenses are the most valued type of documentation for both users and contributors.

Without a license, many companies will not touch your code. Without a contributing guide, newcomers guess, and guessing is scary. Without a code of conduct, you have no clear way to handle bad behavior when it shows up.

4. Give the project one home

People need one link to remember. A GitHub repo works at the start. A small website works better as you grow.

Open Source Guides quotes Adrian Holovaty, co-creator of Django, saying the website was one of the best things the team did early on. You do not need anything fancy. GitHub Pages is free and fine. What matters is that the site has your pitch, the quickstart, examples, and docs in one place.

5. Make the first five minutes work

A visitor who cannot get a working result in five minutes usually leaves and does not come back.

Test your own quickstart on a clean machine. Better still, ask a friend who has never seen the project to try it while you watch silently. Fix every spot where they pause.

Then add:

A starter template or example repo people can clone.
Copy and paste code that runs without edits.
The exact text of the most common errors, with fixes.

Studio1 has written about why poor onboarding and thin docs sink developer products. The same lessons apply to open source.

6. Label good first issues

Most people who want to help do not know where to start. Show them.

Use the "good first issue" and "help wanted" labels on tasks a newcomer can finish. GitHub's own docs say it uses an algorithm to find approachable issues and show them in places across the site, and that adding the label can raise the chance yours get shown. The CNCF issue label guide adds a good test: a new person should be able to claim the task and send an acceptable pull request without having to ask for help.

Write each beginner issue so it stands on its own. Say why it matters, which files to look at, and what done looks like.

Also, keep a few easy bugs unfixed on purpose. Open Source Guides suggest using small, non-urgent bugs as a way to bring in new contributors instead of fixing them yourself.

7. Reply fast, especially to first timers

This one costs nothing and matters a lot.

Open Source Guides point to a Mozilla study showing that contributors who got a code review within 48 hours came back far more often. They also warn that if you leave an issue sitting for a month, people usually forget your project.

The numbers on why this matters are not pretty. One analysis by the team at Multitudes found that around 70% of contributors are one-time contributors. A friendly, quick reply is how you turn a few of them into regulars.

You do not need a full review in two days. A short note like "Thanks, I will look this week" counts. Track it, too. The Linux Foundation's Insights tool lists median time to first review as a health signal for exactly this reason.

8. Launch where developers already hang out

You do not have to launch loudly, but you do have to tell people. Open Source Guides say plainly that you have to spread the word instead of hoping others find you.

Researchers looked at how the 100 most starred GitHub projects promote themselves. The paper, How Do Developers Promote Open Source Projects?, found that Twitter (now X), user meetups, and blogs were the most common channels. It also showed that a successful Hacker News post gave projects a clear jump in stars.

More recent work agrees. A 2025 study of 1,814 AI repositories shared on Hacker News saw a significant rise in forks, stars, and contributors afterward. Another paper tracked 138 repository launches and found an average gain of 121 stars in the first day, 189 in two days, and 289 in a week. It also found the "Show HN" tag gave no statistical edge once other factors were counted, while the time of posting did matter.

Treat those as averages from AI and developer tool launches, not a promise. Your result depends on the idea and the post.

How to launch without being annoying:

Pick two or three places where your exact users hang out, not ten.
Say who it is for and what you want feedback on.
Show the working result first, then the story.
Stay in the thread and answer every comment.
If nobody notices, try a new angle in a month. Open Source Guides note that many launches take months or years to catch on.

9. Write content people actually search for

Most developers do not find projects by luck. They search for a problem, or they ask an assistant.

In the 2025 Stack Overflow Developer Survey, 50.6% of professional developers said they use AI tools every day. So your pages need to work for Google and for AI answers.

Write the pages your users would search for:

How-to guides for each main task ("How to add auth to a Next.js app with X").
Comparisons that are honest about where another tool fits better.
Migration guides for people leaving a competitor.
Error fixes with the exact error message in the title.

Put the answer in the first two sentences. Keep every section understandable on its own, so a search engine or assistant can lift it out. Studio1 goes deeper into Developer Docs as Your Best AEO Asset and How to Get Your Tool Recommended by ChatGPT, Perplexity, and Google.

10. Help other people before you ask for anything

The fastest way to be known is to be useful somewhere else.

Open Source Guides suggest answering questions in forums where your users ask for help, and mentioning your project only when it truly fits. They also suggest contributing to projects near yours. The guide shares a story from the maintainer of urllib3, who said the library became so popular largely because requests bundled it.

Practical ways to do this:

Answer questions on Stack Overflow, Reddit, and Discord with real fixes.
Send a pull request to a related project.
Thank people who write about your project, and share their posts.
Speak at a local meetup. It is a gentle way to start, and the people in the room are real users.

11. Share ownership and give credit

People stay where they feel their work counts.

Open Source Guides list several easy moves: keep a CONTRIBUTORS or AUTHORS file, thank people by name in release notes or a newsletter, give regular contributors commit access, and move the repo to a GitHub organization with at least one backup admin. They also note that most projects have only one or two maintainers doing most of the work, so the earlier you invite help, the better.

Public credit is cheap, and it works. Projects like Rust do it with a weekly newsletter that names contributors.

12. Protect the people who keep it running

A growing project means more issues, more questions, and more pressure. If you do not plan for that, you burn out.

Tidelift's 2024 survey of maintainers found that 60% describe themselves as unpaid hobbyists, and 60% have quit or thought about quitting. Tidelift's own breakdown also says 78% of unpaid maintainers spend ten hours or less a week on their projects.

That means your project probably runs on a few hours of someone's spare time. Build for that:

Move all help into public channels, such as issues or discussions, so answers help everyone, and you are not stuck in private messages.
Set office hours. The Kubernetes kops team does this every other week to help newcomers.
Write down what you will and will not accept, and say no kindly.
Add a second maintainer before you need one.
Look into funding early. Tidelift reports that income most often comes from donations such as GitHub Sponsors (25%) or from employers who include open source work in a salary (24%).

How do you know your open source project is growing?

Stars are easy to see, but they do not tell you whether anyone is using or helping. Watch a few numbers that do.

What to track	Why it matters
Installs or downloads per month	Shows real use, not just interest
New issues from people you do not know	A sign the project is being tried
First time contributors per month	Shows whether your doors are open
Contributors who come back	Shows whether they felt welcome
Median time to first reply	The number you control most
Visits to your docs from search	Shows your content is being found

Check them once a month and write the numbers down. Small, steady gains beat one big spike.

Can programmatic SEO help an open source project?

Yes, if you have real facts behind every page. Programmatic SEO (pSEO) means building many pages from one template and a set of true details. For open source, the natural pages are the ones you already have material for.

Page type	Example question it answers	What you need
Error page	What does "ECONNRESET" mean in our client and how do I fix it?	Exact message, cause, working fix
Integration page	How do I use our library with Express?	Tested steps and code
Migration page	How do I move from Library X to ours?	Side by side code, before and after
Comparison page	Ours vs Library X for caching	Honest numbers and trade offs
Release page	What changed in version 3?	Dated notes and upgrade steps

One rule keeps this safe. Do not publish a page until it has facts that only apply to that page. If a page would read the same with one word swapped, search engines and AI tools will skip it. Google also says there is no special markup needed to appear in its AI features. Pages just need to be indexed and useful.

What mistakes slow down open source growth?

Launching with a weak README. The visitor leaves before you can explain.
Hiding the best help in private chats. Nobody else can learn from it.
Ignoring first pull requests. Many first-timers never return after a silent reply.
Doing every easy fix yourself. You lose the chance to invite someone new.
Posting in ten places and following up in none. Two good threads beat ten ignored ones.
Chasing stars over use. Stars fade. Installs and contributors build a project.
Skipping docs updates. Old docs do quiet damage to trust.

A simple 30 day plan

Week	Focus	Done when
1	One sentence pitch, README rewrite, license, contributing file	A stranger can explain your project back to you
2	Quickstart test with a new user, starter template, error fixes in docs	Someone gets a working result in under five minutes
3	Ten labeled beginner issues, public channel for help, reply rules	A new contributor can pick a task without asking
4	Launch in two chosen communities, publish one how-to and one comparison	You answered every comment within a day

Then repeat the cycle. Growth comes from small habits you keep up.

Frequently asked questions

How long does it take to grow an open source project?

Often months or years. Open Source Guides say some of today's most popular projects took years to reach high activity. Plan for steady effort, and expect early progress to be small.

How do I get my first contributors?

Label beginner issues, write a clear contributing guide, and reply within a couple of days. Contributors rarely arrive on their own. Invite them in public and thank them by name.

Do GitHub stars matter?

They help people trust you at a glance, but they do not measure use. Watch installs, new issues from strangers, and returning contributors for a truer picture.

Where should I promote my open source project?

Go where your exact users already ask for help. For developer tools, that often means Hacker News, Reddit, relevant forums, and local meetups. Join the conversation first, then share your work where it fits.

How fast should I respond to issues and pull requests?

Aim for a first reply within 48 hours. A Mozilla study cited by Open Source Guides found that contributors reviewed within that window came back far more often. A short acknowledgement is enough when you cannot review right away.

How do I make my open source project show up in Google and AI answers?

Write pages that answer one question each, with the answer in the first two sentences. Keep docs fresh, readable in plain HTML, and easy to link to. Then earn mentions in the communities where developers talk.

How do open source maintainers get paid?

Tidelift's 2024 report says income most often comes from donations such as GitHub Sponsors, from employers that include open source work in a salary, and from Tidelift itself. Direct company payments, foundations, and government funding were each a small share.

What a DX Audit Covers, and 10 Common Problems a DX Audit Can Reveal

Nancy Garg — Wed, 04 Nov 2026 13:40:48 +0000

TL;DR

Developers who hit a wall with your product rarely tell you. They leave quietly, and a DX audit is how you find that wall before more of them walk into it.
The first hour matters most. If a new developer cannot get one working result quickly, nothing else you built gets a fair chance.
Weak docs are the most common cause. More than half of API teams call inconsistent documentation a major problem, and since developers now ask AI tools before opening your docs, unclear pages hurt you twice.
Most problems are small and cheap to fix: an old quickstart, a vague error message, too many steps to get access, a change nobody announced.
You can test this yourself in 30 minutes. Sign up like a stranger, follow your own quickstart, and time how long it takes to get a first working result.

Why Developers Leave Quietly

Most developers who try your product will never tell you what went wrong. They sign up, hit a wall, and go back to what they were using before. You see a drop in your funnel and nothing else.

A DX audit is how you find that wall. Someone who has never used your product goes through it the way a new developer would, writes down every point where they got stuck, and turns that list into a plan.

If you want the bigger picture on why developer products struggle, our post on common mistakes startups make when building developer-first products is a good companion to this one.

What Is a DX Audit?

A DX audit, also called a developer experience audit, is a review of how easy it is for a developer to learn, set up, build with, and get help for your product. It looks at real steps and real time spent, not opinions. The output is a ranked list of problems, with a clear fix for each.

You can audit an API, an SDK, a CLI tool, a developer platform, an open source project, or the internal tools your own engineers use.

Why It Matters: What the Data Says

Developer friction is expensive, and the numbers are bigger than most teams expect.

Time lost every week. Atlassian's 2025 State of DevEx report surveyed 3,500 developers in six countries. Half of them said they lose 10 or more hours a week to organizational friction, and 90% lose at least six. The same report found developers spend only 16% of their time writing code. Atlassian estimates a company with 500 developers could lose up to $7.9 million a year this way.
Self-serve answers pay off. LeadDev reports that developers who can find documentation and knowledge on their own are 4.4 times more productive.
Docs are a top complaint. In Postman's 2025 State of the API report, more than half of respondents named inconsistent documentation as a major stumbling block. A year earlier, 39% called it the single biggest roadblock to API work.
Maintenance eats the week. Stripe's Developer Coefficient study found the average developer spends more than 17 hours a week on maintenance, plus about four hours on bad code. The study is from 2018, but it is still the most quoted number on this topic.
AI makes bad docs more visible. In the 2025 Stack Overflow Developer Survey, 84% of respondents use AI tools, and 66% say their biggest frustration is AI answers that are close but not quite right. When your docs are unclear, those tools get your product wrong too.

What Does a DX Audit Cover?

A good audit follows the path a developer takes, from first visit to a working app and then to asking for help. Here are the eight areas we check.

Area	The question we answer	What we look at
1. The first hour	How long until a new developer sees something work?	Landing page, signup, quickstart, time to first API call
2. Documentation	Can someone learn the product without asking a person?	Tutorials, reference pages, concept guides, search, code samples
3. API, SDK and CLI design	Does it behave the way a developer expects?	Naming, defaults, consistency, language support
4. Errors and debugging	When something breaks, can they fix it alone?	Error messages, logs, status codes, troubleshooting pages
5. Setup and tooling	Can they run it on their machine without a fight?	Install steps, dependencies, sandbox, build and test speed
6. Auth and access	How many steps stand between signup and a real call?	API keys, OAuth, approvals, permissions, test data
7. Support and community	Does anyone answer, and how fast?	GitHub issues, Discord or Slack, forum replies, changelogs
8. AI readability	Can AI assistants find, read, and cite your docs?	Page structure, plain text content, llms.txt, answer-style headings

Most audits also add a ninth thread that runs through all of it: measurement. Without numbers, you cannot tell whether a fix worked.

How a DX Audit Works, Step by Step

Pick the developer. Decide who you are auditing for: a beginner trying your API for the first time, or an expert migrating from a competitor. Each one hits different walls.
Do a cold run. Someone who has never used the product starts from the homepage and tries to build the simplest useful thing. They write down every pause, every guess, and every tab they open to find an answer.
Read the evidence you already have. Support tickets, GitHub issues, community threads, and sales call notes usually repeat the same five complaints.
Talk to a few real developers. Five or six short conversations will confirm most of what the cold run found.
Check the numbers. Look at signup to first successful call, quickstart completion, and how long it takes to find an answer in search. A DEV Community guide on API analytics lists the onboarding metrics worth tracking, including support ticket volume during onboarding.
Score and rank. Every problem gets a rating for how many developers it hits and how badly. The fix list is sorted by that, so the team starts with the biggest win.

The 10 Problems We Find Most Often

These are patterns we see again and again. Where public research backs one up, we link to it.

1. The path to a first working result is too long

A developer who signs up wants to see one thing work, fast. Postman calls time to first call the most important metric for a public API. We often find the real number is far longer than the team thinks, because the team has never gone through signup with a fresh account.

What it looks like: a long signup form, a dashboard with no guidance, and docs that explain features before showing a single working call.

The fix: one page that takes a new developer from zero to a working response, with a ready-to-run example and a test key that works right away.

2. The quickstart is out of date

Docs drift. The product changes, the sample code does not, and the first copy-paste throws an error. The 2025 State of Docs report, as summarized by DigitalAPI, found that keeping docs current is the top challenge for over half of documentation teams.

What it looks like: old package versions, renamed endpoints, screenshots of a dashboard that no longer exists.

The fix: run your quickstart in a clean environment on a schedule, and treat a failing quickstart like a failing test.

3. Docs are written for people who already know the product

Reference pages are easy to write, so that is where most teams stop. New developers need tutorials that walk them through a real task and short explanations of how the system thinks. Postman's 2024 report found that 44% of developers read source code just to understand an API. That is a sign the docs left something out.

What it looks like: pages full of parameters with no story, and terms used before they are explained.

The fix: cover three layers, which are reference, tutorials, and concept guides. Then hand the docs to someone outside the team and watch where they stall.

4. Error messages do not tell people what to do

An error that says "Invalid request" sends a developer to a search engine, then to a forum, then to a support chat. Each step costs minutes and goodwill.

What it looks like: vague messages, error codes with no matching docs page, and failures that give no hint about which field was wrong.

The fix: say what went wrong, why it likely happened, and what to try next. Link each error code to a page that explains it.

5. Local setup and builds are painful

This one hits open source projects and internal teams hard. If setup takes a full day, people give up or wait for a teammate to help. It also feeds the bigger problem in the Atlassian data above: hours lost to friction that has nothing to do with writing code.

What it looks like: a README with missing steps, unlisted dependencies, "works on my machine" bugs, and tests that take too long to run.

The fix: one command to install, one command to run, and a README that a new hire can follow without asking anyone.

6. Getting access takes too many steps

Approval queues, sandbox requests, confusing OAuth flows, and keys hidden three menus deep are some of the most common reasons developers drop off before their first call.

What it looks like: a form that needs a human to approve it, auth docs that start with theory, and no test data to try things with.

The fix: give instant sandbox access, show the simplest auth method first, and move advanced options to a later page.

7. Changes arrive with no warning

Developers build on your product and then you rename a field. If you do not announce it, they find out when their app breaks. A JetBrains survey of plugin developers found that experienced developers want better API documentation notes far more than beginners do, 41% versus 17%. One of the clearest requests was a pointer to the new API whenever an old one is retired.

What it looks like: no changelog, silent deprecations, and breaking changes tucked inside a minor release.

The fix: keep a public changelog, mark deprecated items in the docs and in code, and always say what replaces them.

8. Developers cannot find the answer

Good content is useless if search cannot surface it. Docs hidden behind a login, pages with unclear titles, and search that returns the wrong page all push developers away. Remember the 4.4 times productivity gap for developers who can answer their own questions.

What it looks like: docs that need an account to read, a search box that misses obvious terms, and the same question asked again and again in the community.

The fix: make docs public, name pages after the task a developer is trying to finish, and use your most repeated support questions as a to-do list for new pages.

9. Support and community go quiet

Developers read your community channels before they commit. Unanswered questions and old threads say a lot about what life is like as your user.

What it looks like: a Discord with only announcements, GitHub issues that sit for weeks, and no visible team members.

The fix: set a reply time you can actually meet, answer in public so the next person finds it, and turn good answers into docs. We cover why this matters in why active developer communities matter for early-stage startups.

10. AI assistants cannot read or cite your docs

Developers now ask ChatGPT, Claude, Perplexity, and Copilot before they open your docs. Postman's 2025 report says 89% of respondents use generative AI tools in their daily work. If your docs are locked in scripts, buried in PDFs, or written with no clear headings, those tools give wrong answers or skip you entirely.

What it looks like: docs that load content with scripts, vague headings, no plain text version, and answers scattered across five pages.

The fix: use clear question-style headings, put the direct answer first, keep pages in plain text, and consider adding an llms.txt file. We cover this in depth in developer docs as your best AEO asset and llms.txt explained.

A 30-Minute Mini Audit You Can Run Today

You do not need a full audit to find the worst problems. Try this:

Open a private browser window and find your product from a search, as a stranger would.
Sign up with a new email address and start a timer.
Follow your own quickstart exactly as written. Note every error and every place you had to guess.
Trigger one error on purpose. Is the message clear enough to fix it alone?
Ask an AI assistant how to do the same task with your product. Check whether the answer is right and whether it cites your docs.
Write down the time to first working result and the three biggest blockers.

If the timer ran past what you expected, you have your first fixes. For help tracking results over time, read our post on measuring developer content ROI beyond pageviews.

Frequently Asked Questions

What is a DX audit?

A DX audit is a structured review of how easy your product is for developers to learn, set up, use, and get help with. It follows the real path a developer takes and ends in a ranked list of problems and fixes.

What does a developer experience audit include?

It usually includes the first-hour experience, documentation, API or SDK design, error messages, setup and tooling, authentication, support and community, and AI readability. It also sets up the measures you will use to track progress.

Who needs a DX audit?

Any team that ships something developers use. That includes API companies, SDK and CLI tool makers, developer platforms, open source projects, and internal platform teams. It helps most when signups are strong, but few developers reach a working integration.

What is time to first API call?

It is the time between a developer signing up and making their first successful request. It is one of the clearest signs of how good your onboarding is. Shorter is better, and the gap between what teams assume and what they measure is often large.

How is a DX audit different from a UX audit?

A UX audit looks at how end users move through an app. A DX audit looks at how developers move through the tools, docs, and systems they use to build. The questions are different: installation steps, error messages, and example code matter more than button placement.

How often should you run one?

Run a full audit before a major launch or after a big product change, and run the 30-minute mini audit every few months. Quickstarts and docs drift quickly, so regular small checks catch problems early.

Build Your Own Grok Bot: A Step-by-Step Guide

Nancy Garg — Thu, 29 Oct 2026 17:22:47 +0000

TL;DR

You can build your own Grok Bot-style team of AI bots with OpenCrewBot, a free, MIT-licensed app that runs on your own machine. You can explore the app without API keys using scripted demo replies. Add a Nebius API key when you’re ready for real model responses.

What you get: a chat app where every contact is a bot with its own model settings, tools, and memory. You can optionally enable a cloud browser through Browserbase. Put several in a room, and they split the work.
What you need: Node.js 22.13 or newer, pnpm, and five commands. Every API key is optional.
What it costs: the app is free. You pay only for the services you switch on, like open-source models on Nebius Token Factory.

SpaceXAI released Grok Bot as an early beta on August 11, 2026. It gives you named AI teammates that keep working in the cloud, hand tasks to each other, and ask before risky actions. Since October 12, 2026, new users get it through the X Subscription, which starts at $30 a month.

We liked the idea but wanted something we could run ourselves, on open models, with our data in files we can open. So we built OpenCrewBot and put it on GitHub. This guide walks you through the setup, your first tasks, the API keys, and the problems you might hit along the way.

What is OpenCrewBot?

OpenCrewBot is an open-source chat app for your own team of AI bots. It looks like a messaging app. Each contact in the sidebar is a bot with its own name, role, instructions, open-source model, tools, and memory. You can talk to one bot directly, or put a few in a room and let them share the work.

On first run, you get three bots and one room:

Scout (Research): searches the web and answers with its sources.
Quill (Writing): turns notes and research into posts, docs, and emails.
Atlas (Planning): breaks goals into steps and hands work to the other two.
Studio (a room): all three bots together, with Atlas as the lead.

It's built on Mastra, an open-source TypeScript framework for AI agents, and uses open models from Nebius Token Factory. It's a starting point you run yourself, not a hosted product.

OpenCrewBot vs Grok Bot at a glance

	Grok Bot	OpenCrewBot
Where it runs	SpaceXAI's cloud	Your own machine
Price	Included in paid plans (from $30/month)	Free app; you pay only the APIs you switch on
Models	Grok	Open models from Nebius Token Factory's live catalog (MiniMax, DeepSeek, Qwen, GLM, Kimi and more)
Source code	Closed	Open, MIT license
Group chats	2 to 6 Bots per chat (source)	Rooms with @mentions, @everyone and auto routing
Memory	Managed by the product	One plain MEMORY.md file per bot you can open and edit
Browser	One shared cloud computer for all Bots	One Browserbase cloud browser per bot
Approvals	Yes	Yes, Allow once or Deny cards in chat
Apps and MCP	Connectors, plugins, MCP	Composio (1,000+ apps) and your own MCP servers
Scheduled routines	Yes	Not yet
Multiple users	Yes	No, one local owner

The short version: Grok Bot is a polished product you rent. OpenCrewBot is a project you own, change, and run on your terms.

What do you need before you start?

You need two things on your computer and nothing else to begin:

Node.js 22.13 or newer. The project was built on Node 24. Check yours with node -v.
pnpm, the package manager the repo uses. Check it with pnpm -v.

That's it for the first run. API keys come later, and all of them are optional. Here is what each one turns on, so you can decide what you want:

Key	What it turns on	Where to get it
`NEBIUS_API_KEY`	Real open-source models. Without it, bots use a scripted mock model.	Nebius Token Factory
`TAVILY_API_KEY`	Web search, page reading and site crawls	Tavily
`BROWSERBASE_API_KEY`	A real cloud browser for bots with the Browser tool	Browserbase
`COMPOSIO_API_KEY`	Connected apps like Slack, GitHub, Gmail and Notion	Composio
`TYPESAFE_API_KEY`	Jev, which picks the right bot in Auto rooms	TypeSafe

If you only add one key, make it Nebius. That's the one that swaps the mock model for real ones.

How to build your own Grok Bot with OpenCrewBot, step by step

The whole install is five commands. Open a terminal and run them in order.

Step 1: Clone the repo

git clone https://github.com/Studio1-OSS/OpenCrewBot.git
cd OpenCrewBot

Step 2: Install the packages

pnpm install

Step 3: Create your settings file

cp .env.example .env

This copies the example file into a real .env. Leave it empty for now. Empty means mock mode, which is exactly what you want for a first look.

Step 4: Start the app

pnpm dev

Step 5: Open it in your browser

Go to http://localhost:3000. You'll see Scout, Quill, and Atlas in the sidebar, plus the Studio room. Scout and Studio are pinned to the top.

A small dot on the Settings icon means you're in mock mode. Hover it, and it says the app stays in mock mode until NEBIUS_API_KEY is set. Nothing is broken. It just means replies come from a scripted model while the tools, approvals, and streaming are all real.

Where your data lives

Everything stays in a data folder inside the project:

data/opencrewbot.db holds your bots, rooms, and chats (SQLite).
data/mastra.db holds each bot's model-side history.
data/workspaces/<botId>/MEMORY.md is each bot's memory, as a plain text file.

You can move the folder anywhere with OPENCREWBOT_DATA_DIR in .env. The app sends no telemetry of its own.

Your first tasks (no API keys needed)

Mock mode is worth five minutes of your time. The fake model only writes the replies. The memory tool, question cards, approval cards, and streaming are the same code that runs with real models. Open a chat with Scout and try these.

Task 1: Make a bot remember something

Type:

remember that I like short answers

Scout calls its memory_add tool and writes a dated line to its MEMORY.md file. Open the bot's Memory tab, and you'll see the line appear. That tab is the file itself, and it refreshes live when the bot writes to it. You can edit it there or in any text editor.

The first 200 lines of that file load into the bot's instructions on every turn, so it remembers across chats. Anything that looks like a password, token, or API key gets redacted before it's saved.

Task 2: Let a bot ask you a question

Type:

ask me something

A question card shows up in the chat with two buttons, Short and Detailed. The bot waits. Click one, and it picks up where it left off. With a real model, a bot uses this when it can't go on without a decision from you.

Task 3: See an approval card

None of the starter bots have the browser turned on, so switch it on first:

Open a bot's menu in the sidebar and click Edit profile. Its details panel opens.
Click Edit details and turn on Browser under Tools.
Keep Approval on Ask first and click Save changes.

Now type:

open https://example.com

The bot stops and shows a card asking to open the page. Allow once to run it. Deny skips it and the bot carries on. Nothing happens until you choose. (The browser itself needs a Browserbase key, so in mock mode the action will fail after you allow it. The point here is the card.)

Task 4: Talk to a room

Open the Studio room. Bots in a room decide who answers in this order:

@everyone (or @all) gets every bot to reply.
@scout, @quill, or @atlas gets that bot to reply.
With no mention, an Auto room asks Jev to pick the best bot. If Jev isn't at least 55% sure, or there's no Jev key, the room's lead answers. In Studio, that's Atlas.

A bot can also @mention a teammate in its reply to hand work off. Atlas is told to send research to Scout and drafting to Quill. Hand-offs stop after two hops, so bots can't keep passing work back and forth forever.

Two small things you'll notice: messages you send while a bot is busy wait in line until it finishes, and the Stop button cancels a reply midway.

How to add API keys (and what each one unlocks)

Once you've seen how it works, open .env and add keys one at a time. Restart pnpm dev after every change, because the app only reads the file on start.

1. Nebius Token Factory: real models

NEBIUS_API_KEY=your-key-here

This is the big switch. Bots stop using the mock model and start using open-source models from Nebius Token Factory. Each reply then shows its tokens and cost.

To pick a model, open a bot's details and click Change under Default model. The model sheet suggests three picks and lists every model in the live catalog, with search, context size, tool support, and price. These are the suggestions and prices from the app's built-in list (per million tokens, input/output):

Pick	Model	Context	Price per 1M tokens
Fastest	Nemotron 3.5 Lightning	1M	$0.06 / $0.24
Best all-rounder (default)	MiniMax M3	1M	$0.30 / $1.20
Strongest	Qwen3.5 397B A17B	262K	$0.60 / $3.60

Once your key is set, the live catalog from Nebius replaces these numbers, so check the sheet for current prices. A new model applies from the bot's next reply, with no restart.

2. Tavily: web search

TAVILY_API_KEY=your-key-here

Bots with Web search turned on can now search, read pages, and crawl sites. The sources show up under the answer. Try search for Nebius Token Factory with Scout.

3. Browserbase: a real browser

BROWSERBASE_API_KEY=your-key-here

Bots with Browser turned on get their own cloud browser for pages that need clicks, forms or JavaScript. Open the bot's Browser tab to watch it live, and click in to take over. Two optional settings sit next to it: BROWSERBASE_PROJECT_ID (worked out from the key if empty) and BROWSERBASE_SESSION_MINUTES (default 15), which caps how long one session runs. Sessions are released when you reset or delete a bot, so they stop billing.

4. Composio: your apps

COMPOSIO_API_KEY=your-key-here

Click the plug icon in the sidebar to open Connections. Click Connect on an app, sign in on that app's own page, and come back. Featured apps include Slack, GitHub, Gmail, Google Calendar, Notion, Linear, Google Drive, and Jira, and search finds the rest. Then switch each app on for the bots that should have it, in the bot's details.

In the same panel, you can add your own remote MCP server by URL and token. There's a preset for GitHub's official server. Add, and test connects right away and tells you how many tools it offers.

5. TypeSafe: smart room routing

TYPESAFE_API_KEY=your-key-here

This turns on Jev in Auto rooms. When you post without an @mention, Jev reads the room and picks the best bot in a few hundred milliseconds. Without it, the room's lead always answers.

How to make your own bots and rooms

The three starter bots are examples. The real fun starts when you build bots for your own work.

Create a bot

Click the + at the top of the sidebar and choose New bot. You'll fill in:

Name and role: up to 40 characters each, like "Scout" and "Research". The name also becomes its @handle in rooms.
Description: one line on what the bot does. Write this one carefully. In Auto rooms, Jev reads each bot's description to decide who should answer.
Instructions: how the bot should work, up to 8,000 characters.
Model: any model from the model sheet.
Tools: Web search, Memory, Code mode, Browser and Ask me questions. Turn on only what the bot needs.
Approval: Ask first makes browser actions wait for your OK. Full access acts without asking.

Changes apply from the bot's next reply, so you can tweak and test fast.

What Code mode does

With Code mode on, the bot can write one small TypeScript function that calls several tools at once, instead of calling them one by one. A question that needs five searches can take one round trip. The code runs in a locked sandbox with no access to your files or the internet, and its only reach is the bot's own tools. Scout has it on by default.

Create a room

Click + and choose New room. Give it a name and topic, add members, pick a lead, and choose how it answers:

Mode	Who answers
Auto	Jev picks the best bot (needs a TypeSafe key, otherwise the lead answers)
Lead	The lead bot answers
Everyone	Every bot answers

In Auto and Lead rooms, an @mention overrides the mode, so you can send any message to a specific bot. In an Everyone room, every bot replies no matter what.

What still asks for permission

Some actions always run on their own: web searches, page reads, memory updates, and lookups in connected apps. Anything that changes something in the real world asks first, unless the bot has Full access. That includes clicking or typing in the browser, sending a Slack message, or opening a GitHub issue.

Troubleshooting: common problems and fixes

Most problems come down to a missing key, a missing restart or an old Node version. Here's what you might see and what to do.

What you see	Why it happens	How to fix it
Every bot replies with "running on the mock model"	No `NEBIUS_API_KEY` is set, or the app wasn't restarted	Add the key to `.env` and restart `pnpm dev`
A key you just added does nothing	The app reads `.env` only when it starts	Stop `pnpm dev` and start it again
The install or start fails right away	Your Node.js may be older than 22.13, the minimum the project asks for	Update Node, then run `pnpm install` again
"Blocked: OpenCrewBot only answers on localhost"	You opened the app from another device or another host name	Open it on the same machine at `localhost:3000`. To serve another host name on purpose, add it to `OPENCREWBOT_ALLOWED_HOSTS` (only behind your own sign-in)
A bot says it can't search right now	Web search is on, but `TAVILY_API_KEY` is missing	Add the Tavily key and restart
Browser actions fail after you click Allow once	`BROWSERBASE_API_KEY` is missing	Add the Browserbase key and restart
A bot says connected apps aren't available	`COMPOSIO_API_KEY` is missing, or the app isn't connected yet	Add the key, then connect the app in Connections and switch it on for that bot
An Auto room always gets the same bot	No TypeSafe key, or Jev wasn't at least 55% sure	Add `TYPESAFE_API_KEY`, sharpen each bot's description, or @mention the bot you want
A reply shows "Interrupted by a server restart"	The server stopped while that bot was replying	Send the message again. Replies can't resume after a restart
Clicking an old approval or question card fails	The bot restarted and that request is no longer waiting	Ask the bot again to get a fresh card
Your MCP server won't save	The URL isn't `https://`	Use an https URL. Plain http only works for localhost
A bot can't take browser screenshots	Its model can't read images, so the app hides that tool	Pick a model with vision in the model sheet, or let it read the page as text

If something else breaks, the terminal running pnpm dev prints errors with an [opencrewbot] tag, which is the first place to look. You can also open an issue on GitHub.

FAQ

Is there a free, open-source alternative to Grok Bot?

Yes. OpenCrewBot is a free, MIT-licensed app that gives you a team of AI bots with their own models, tools, memory, and browsers. You run it on your own machine and pay only for the services you connect.

Can I build my own Grok Bot without writing code?

Yes. You need to run five commands in a terminal, and after that, everything happens in the app. Creating bots, rooms, and connections is all done with forms.

Do I need API keys to try OpenCrewBot?

No. With no keys, it runs in mock mode. A scripted model writes the replies, but memory, question cards, approvals, and streaming all work for real.

Which AI models does OpenCrewBot use?

Open-source models from Nebius Token Factory, including MiniMax, DeepSeek, Qwen, GLM, Kimi, Nemotron, and gpt-oss. The default is MiniMax M3. You can give every bot a different model and switch it any time.

How much does it cost to run?

The app is free. Model calls are billed by Nebius per token, and every reply shows its own tokens and cost. In the app's built-in list, the default MiniMax M3 costs $0.30 per million input tokens and $1.20 per million output tokens.

Is my data private?

Your bots, chats, and memory files stay in a local data folder, and the app sends no telemetry of its own. Data only leaves your machine for the services you set up. For example, Nebius receives the conversation, and Tavily receives your search queries.

Can I share it with my team or put it on a server?

Not as it is. It has no sign-in and assumes one owner, so it only listens on your own machine. Adding sign-in and multiple users is on the list of ways to extend it.

How do the bots remember things?

Each bot has one plain MEMORY.md file. The bot adds and fixes lines with two tools, and the first 200 lines load into every chat. You can read or edit the file in the app or in any text editor.

Can the bots use Slack, GitHub, or Gmail?

Yes, through Composio or your own MCP servers. Lookups run on their own, while actions like sending a message ask for your OK first. Chatting with the bots from inside Slack or Discord isn't there yet.

Is OpenCrewBot ready for real work?

It's an early release. On October 13 and 14, 2026, streaming, tools, memory, approvals, rooms, and hand-offs were tested with the mock model. Composio sign-in, live Browserbase sessions, Jev routing, and how well each open model handles tools still need testing with live services.

What to try next

You now have your own Grok Bot style team running on your machine. A good next step is to build one bot for a job you do every week, give it a clear description and the fewest tools it needs, and add it to a room with Scout and Quill.

If you want to take the project further, these are the extensions we've listed in the repo:

Let bots hand work to each other in direct chats, not just rooms.
Add scheduled routines, so a bot can run a task on a timer.
Let Jev pick the model for each message: a fast one for simple asks, a strong one for hard ones.
Talk to your bots from Slack or Discord.
Add sign-in and multiple users before you deploy it anywhere shared.
Add voice, so you can speak to a bot and hear replies.

The code is on GitHub. Issues and pull requests are welcome. Before you open a pull request, run pnpm exec tsc --noEmit and pnpm lint, and say whether you tested it with live services or the mock model.

In the next post, we'll open up the code and explain how we built it: why we used Mastra instead of writing our own agent loop, how rooms decide who answers, and why each bot's memory is a plain Markdown file.

Claude Duet: Features, Pricing, Early Reviews, and Limitations

Nancy Garg — Mon, 26 Oct 2026 12:57:16 +0000

TL;DR

If you want the quick take, Claude Duet is Anthropic's answer to OpenAI's dots and Meta's Muse, and the first outside reviews are warm but not blind. It suits Claude subscribers who do knowledge work. It does not suit anyone who needs it this week from outside the US.

Access is the catch. It is waitlist-only, for Pro ($20 a month) and Max (from $100) subscribers with a US Claude account. Team and Enterprise plans are not included.
It costs no extra money, but it does cost limits. Its background checks, which run every few hours, draw from the same five-hour and weekly limits as normal Claude chats.
Early verdict: Dan Shipper of Every spent about two weeks with it and called it the first personal agent he would call a pro tool. He also found weaker email drafts than ChatGPT's dot and scheduled runs that cannot reach custom connectors.
The biggest gap against rivals: you cannot watch or take over its browser yet, and it only checks your accounts every few hours. Do not hand it anything truly urgent.

Meta, OpenAI, and now Anthropic have each shipped an always-on agent within about two months. The useful question isn't which one has the best demo. It's which one is still useful in week three, after it has misread a thread or eaten into your limits. Anthropic says both can happen.

This post pulls together Anthropic's own pages, the first independent reviews, and price and access comparisons, so you can decide before you spend time on a waitlist.

What is Claude Duet?

Claude Duet is a separate Anthropic app where Claude works as a proactive agent. Anthropic opened a research preview on October 21, 2026. The company says it built Duet for professionals and small business owners who have more on their plate than they can track.

Here is what is actually in it, per Anthropic's announcement and its help center guide:

Model. It runs on Claude Opus 5.5. You cannot pick another model, and Duet decides how much effort a job needs.
A morning brief. Each morning it looks across your email and calendar, picks what needs you most, and can start the first steps, such as drafting replies.
Check-ins every few hours. It watches your connected accounts and messages you only when something needs a decision. Anthropic says checking nonstop would use up plan limits much faster.
Its own cloud computer. It has a virtual machine with its own browser, so it keeps working after you close the app.
Your Claude setup carries over. Memory, skills, and connected apps come from your Claude account. You talk to it by typing or by voice, in one main thread, with separate channels for different topics.
Two tabs for work. Tasks show what it is doing and what needs your input. Make it produce bigger outputs, such as a research brief, a financial model, a deck, or a dashboard.
Connections. It works with more than 6,000 connectors and plugins from the Claude Marketplace, and it can use its own browser for sites that have no connector.

It lives in its own iOS and Android apps, and on claude.ai in a browser. For now, it is separate from the main Claude app.

Anthropic's product page also shows a sample morning brief for a fictional café owner, pulling in a point-of-sale system, Shopify, a CRM, a support inbox, payroll, and a bank. That is a demo, not a customer result. The real-world stories come from the reviews below.

How does Claude Duet compare with OpenAI's dots and Meta's Muse?

All three give you an agent that has its own cloud computer, keeps working after you log off, and asks before it does anything consequential. Engadget and Tom's Guide covered dots and Muse before Duet arrived. Here is how the three line up on the facts those outlets and Anthropic have published.

	Claude Duet	OpenAI dots	Meta Muse
Model	Claude Opus 5.5	GPT-6 Astra	Muse Spark
Where it lives	Own iOS and Android apps, plus claude.ai	Inside ChatGPT	Own apps, the web, or WhatsApp
Cheapest way in	Claude Pro at $20 a month	ChatGPT Pro 100 at $100 a month	Free tier with a usage cap
Higher tiers	Max from $100 a month	Business Premium at $125 per user monthly ($100 billed annually)	$20 Power, $100 Maximum
Availability	US only, waitlist, Pro and Max	Eligible Pro and Business Premium users, outside the EEA, Switzerland, and UK	US and Canada
Connections	6,000+ connectors and plugins	4,000+ apps through ChatGPT plugins	Slack, Stripe, Shopify, QuickBooks, plus Facebook and Instagram business accounts
Approval controls	Asks before sending, paying, signing, or deleting	Custom rules and auto-review	Asks before sensitive actions, with read and write access kept separate
Usage limits	Shares your Claude plan limits, background work included	Does not count toward limits unless used inside ChatGPT Work or Codex	Capped on the free tier

Three differences stand out.

Price of entry. Duet is the cheapest paid way into this category if you already pay for Claude. Muse is the only one with a free tier. Dots start at $100 a month for an individual, which Tom's Guide reads as a pitch to professionals and developer teams.

The usage trade. Duet's background work eats into the limits you also use for chat. Per Engadget, dots mostly do not. That is a real point for OpenAI.

The browser. Flavio Copes, who read through the documentation, says that dots and xAI's Grok Bot let you watch and take over their browsers, while Duet's preview does not. He calls that Duet's main weakness.

What do early users say, and what have they built with Claude Duet?

It's only a few days old, so there isn't much yet. Here is what the people who actually used it say.

Dan Shipper at Every used it for about two weeks and calls it the first personal agent he would call a pro tool. He likes the channels, and that it keeps his docs, slides, and dashboards up to date. He doesn't like its email drafts, which he finds weaker than ChatGPT's dot, and scheduled runs can't use his custom connectors. Read his review.

Peter Yang built a morning brief, email triage, and a sponsor dashboard in his video, and calls Duet the most proactive agent he has tried. It hit a wall on things like Uber and the cloud browser. The video is sponsored by Wispr Flow.

Claire Vo tried it on inbox triage, her sales pipeline, and a sales deck. She loved the design, but it never nudged her and felt slow, so she still forgot to use it. Her post is worth a read, mostly because she and Yang disagree on whether it's proactive enough.

Phil Simon found that Notion worked with almost no setup and thinks Duet could replace Google Alerts.

Anthropic's own stories are company-picked, so take them as the best case. Amin Ebrahimi, who runs Shahs of Kabob with about 110 employees, used it to work through invoices store by store. Mya Dalton had it prep a client brief, and it offered to move a call that sat right before her flight.

Worth trying first

A morning brief and email triage, which is where Yang started.
Unpaid invoice reminders. Anthropic's example: "Check Stripe for unpaid invoices and draft reminder emails for me to approve." Nothing goes out without your yes.
"Pull together a brief on this company before my 2 pm meeting." Anthropic says Duet tells you which email or file each fact came from, so you can check it. Prompts from the help center.

How much does Claude Duet cost?

Anthropic says Duet is included in Pro and Max during the research preview at no extra cost. So the real price is the plan underneath it.

Plan	Price
Claude Pro	$20 a month, or $17 a month on annual billing ($200 up front)
Claude Max	From $100 a month, billed monthly
Claude Duet	No extra charge during the preview

Plan prices come from Claude's pricing page.

What it costs in limits

This is where the bill hides. Duet uses your plan's five-hour and weekly limits, at the same rate as chats, and its background work counts. That covers the morning brief and the check-ins. Bigger jobs like a financial model or a deck take more model turns and more background work. Anthropic's own wording is that you may hit your limits sooner than you would with chat alone.

The good news is a sweetener. When you are admitted, you get one full limit reset that clears both your five-hour and weekly limits, available until November 30, 2026.

A practical test, borrowed from Copes: after a normal week, check how much allowance is left for the rest of your Claude work. If Duet is taking too much, turn down what it watches.

What it costs per purchase

Duet can buy things for your business using Link, Stripe's digital wallet, or Shopify's Shop Pay. Per the help center, each purchase uses a one-time card that only works for that purchase, and Duet asks you first. Copes adds from the support docs that Link needs a US payment method, does not support recurring payments, and that a merchant can still block checkout after you approve.

How do you get access to Claude Duet?

You need a Pro or Max plan, a Claude account in the US, and an invitation from the waitlist. Invitations go out in waves.

Go to the Claude Duet product page and select Join the waitlist.
Enter your name and the email address on your Claude account.
Pick your plan and phone type, iPhone or Android. You can also say what you would hand off first.
Submit, then wait for the invitation email.
Open that email on your phone and follow the steps, using the Apple or Google account tied to the same email.
Sign in with your Claude account. It can take a few minutes for the app to appear.

Match your emails exactly. Anthropic says access is tied to the address you gave on the waitlist form.

What can you hand off to Claude Duet, and what should you keep?

Anthropic lists work tasks like invoices, payroll, and contracts. Here is how those hold up once you add the caveats from the reviews and the help center.

Task	Can Duet do it?	The catch
Chase unpaid invoices	Yes, with QuickBooks or Stripe, drafting reminders for your approval	The Stripe connector is separate from Link
Prepare payroll	Yes, with Gusto, for your review	You approve before anything runs
Prepare and send contracts	Yes, through Docusign, after your approval	Signing always needs your sign-off
Reply to missed email and Slack messages	Yes, as drafts	Shipper found its email drafts weaker than the dot's
Buy supplies	Yes, through Link or Shop Pay	US payment method, no recurring payments
Anything time-critical	Not a good fit	It checks only every few hours
Rules that never change	Probably not the best tool	A script may be cheaper and steadier, per Copes
Scheduled jobs using your own custom connectors	Reported not to work	Reported by Every and Superpower Daily
Personal errands, like booking tickets	Weaker	Anthropic says Duet is built around work

Two more things are listed as coming soon: signing in to sites with logins saved in 1Password, and a visual editor for designing a Shopify storefront before it goes live.

Is Claude Duet safe to connect to your email and money?

Anthropic puts safety near the top of its pitch, and the design choices are sensible. They are also still its own claims. The company says more detail is coming "in the coming days," so there is no full write-up to check yet.

What Anthropic says it has done:

Approvals. Before Duet sends a message, makes a payment, signs a document, or deletes anything, it shows you the action and waits. If you are not around, it finishes the rest and brings the approval back later.
Hard stops. Trading securities, moving money between accounts, and accessing someone else's account are off-limits even with your yes.
Passwords. Duet never directly sees your passwords or sign-in tokens. When a site asks for one, you type it into a separate form on your own device.
A data classifier. A new check reviews each message and is built to refuse sharing the strictest tier of data, such as credit card numbers and government ID numbers. Health and personal finance details go out only if you explicitly say so.
Outside testing. Red teams and an external firm ran penetration tests, and Duet is covered by Anthropic's public bug bounty program.

What Anthropic admits it cannot promise: Duet reads email and web pages written by other people, and those can hide instructions meant to fool it. This is called prompt injection. Anthropic says no defense is perfect, which is why consequential actions need your approval.

Two control details are worth knowing. Disconnecting an app stops Duet from reaching it, but Duet keeps memory of what it already learned. And Duet can search your past Claude chats, which you can turn off under Settings, then Memory, using the Search and reference chats toggle.

What should you check before you join?

Your location and plan. US account, Pro or Max. Team and Enterprise are out for now.
Your email match. Use the same address on the waitlist as on your Claude account, Apple ID, or Google account.
Your connectors. Microsoft 365 is not available yet. Slack works with limits. Custom connectors may fail inside scheduled tasks.
Your limit headroom. If you already hit your Claude limits most weeks, background work will make it worse.
How urgent your alerts are. A check every few hours is fine for a brief. It is not fine for a payment deadline.
Whether you need to watch the browser; if you do, Duet's preview will frustrate you.
Your first test job. Start with something low-risk, like invoice reminders you approve, and measure how often it gets them right.

Where does Claude Duet still fall short?

Anthropic is upfront about several of these. The rest come from reviewers.

It can misjudge urgency. Anthropic says it may misread a thread, and something can arrive between checks.
No browser view. You cannot watch Duet in its browser or take it over.
Checks only every few hours. By design, to protect your limits.
Weaker email drafts. Shipper preferred the dots.
Custom connectors and scheduled runs do not mix, per Every.
It cannot direct your Claude sessions. It can see sessions on your computers, but not run them.
Voice is transcription only, per Every.
Limited reach. It cannot see files on your computer, cannot change your work in Claude, and does not make calls or send texts.
US only, and its own app. It is not in the main Claude app yet.

Which one should you pick: Claude Duet, dots, or Muse?

There is no single winner, and nobody has published a fair side-by-side test yet. Here is how the facts point.

Pick Claude Duet if you already pay for Claude, have a US account, do knowledge work, and want Slack-style channels and finished docs, decks, and dashboards back. Shipper's pro-tool verdict is aimed at you.
Pick OpenAI's dots if you are on ChatGPT Pro or a business seat, want to watch and take over the browser, or want an agent whose usage does not mostly count against your limits.
Pick Meta's Muse if you want to try an agent without paying for another subscription. Tom's Guide leans this way, with a caution to read its permissions carefully.
Wait if you are outside the US, on Team or Enterprise, or mostly want help with personal errands. Those are the gaps right now.

Frequently asked questions

What is Claude Duet?

Claude Duet is an Anthropic app where Claude acts as a proactive agent. It sends a morning brief, checks your connected apps every few hours, finishes tasks you hand it, and asks for your approval before it acts for you.

When was Claude Duet released?

Anthropic opened a research preview on October 21, 2026. Access is through a waitlist, and invitations go out in waves.

Is Claude Duet free?

It is included with Pro and Max at no extra cost during the preview. You still need the plan, which starts at $20 a month, and Duet's background work counts toward your usage limits.

Who can use Claude Duet right now?

Pro and Max subscribers with a US Claude account who have received a waitlist invitation. Team and Enterprise plans are not included yet.

Is Claude Duet available outside the US?

Not during the research preview. It is limited to the US.

Does Claude Duet work on iPhone, Android, and the web?

Yes. It has standalone iOS and Android apps, and you can open it on claude.ai from a computer.

Which model does Claude Duet use?

Claude Opus 5.5. You cannot choose a different model, and Duet decides how much effort each job needs.

How is Claude Duet different from the Claude app?

The Claude app waits for you to start a chat. Duet comes to you with a morning brief and check-ins, and it works on its own cloud computer after you leave. It uses your Claude account, so memory, skills, and connectors carry over. For now, it lives in a separate app.

How is Claude Duet different from ChatGPT dots and Meta Muse?

All three have their own cloud computer and ask before consequential actions. Duet is the cheapest paid entry if you already have Claude Pro, but it shares your usage limits and cannot show its browser yet. Dots start at $100 a month and let you take over the browser. Muse has a free tier and runs in the US and Canada.

Can Claude Duet spend my money?

Only with your approval. For purchases, it uses Link or Shop Pay and a one-time card. Trading securities and moving money between accounts are blocked even if you approve.

Does Claude Duet see my passwords?

Anthropic says it never directly sees your passwords or sign-in tokens. When a site asks for one, you type it into a separate form on your device.

How often does Claude Duet check my accounts?

Every few hours. Anthropic says checking nonstop would use up your plan limits much faster. You can tell it what to flag and how often.

What is the limit reset for new Duet users?

When you are admitted, you get one full reset of your five-hour and weekly limits. It is available until November 30, 2026.

Fractional DevRel: What It Is, What It Costs, and Who It's For

Nancy Garg — Wed, 21 Oct 2026 14:51:25 +0000

TL;DR

Fractional DevRel means hiring a senior developer relations person part-time, for a monthly fee, instead of hiring a full-time employee. Most deals land between $4,000 and $15,000 a month. It fits teams that have a developer product and nobody senior steering developer adoption.

Typical price: $4,000 to $15,000 per month, depending on hours and how hands-on the person is. A full-time senior hire costs $180,000 to $250,000 or more per year once benefits and taxes are counted.
Hourly rates: One live benchmark shows an average of $278 an hour, with the middle half of rates between $200 and $350. The sample is small, so treat it as a rough guide.
Best for: Devtool and SaaS teams that need direction, a first program, or a low-risk test before committing to a full-time role.
Skip it if: You need daily output (events, constant content, an always-on community) or nobody inside your team can act on the advice.

Developers do their homework before they talk to anyone. Coverage of the 2025 Stack Overflow Developer Survey, which heard from more than 49,000 developers in 177 countries, reports that technical documentation is still the top learning resource, picked by 68% of them. The same survey found that 46% of developers do not trust the accuracy of AI tool answers, and only 3% highly trust them. So they keep going back to docs, tutorials, and other developers.

Someone has to own all of that. In a lot of small teams, nobody does. Founders answer GitHub issues between meetings, the docs go stale, and people sign up and then vanish. Hiring a full-time senior DevRel lead is a big bet for a team that is not sure what the role should do yet. Fractional DevRel is the middle path.

This guide explains what it is, what it costs, who it fits, and who should pass. Every number links to where it came from.

What is fractional DevRel?

Fractional DevRel means bringing in an experienced developer relations leader on a part-time basis. They set the plan, build the first programs, coach the people you already have, and report results to your leadership. You pay a monthly fee, which is often called a retainer, instead of a salary.

You will also see related offers called a part-time Head of DevRel, DevRel consulting, or DevRel as a Service. These labels can cover different scopes: some provide one senior leader, while others include a delivery team. Check who owns strategy and who does the hands-on work. Yalla DevRel, a consultancy that sells this, puts it as paying for ownership and direction, not for a high volume of tasks.

If DevRel itself is new to you, here is the short version. DeveloperRelations.com describes it as how a company builds real, two-way relationships with the developers who influence which tools get used. It groups the work into four areas:

Developer advocacy: speaking, writing tutorials and sample code, and carrying developer feedback back to the product team.
Developer marketing: reaching the right developers and making sure they understand what your product does for them.
Developer enablement: docs, SDKs, workshops, and starter templates that help someone get a first result quickly.
Developer community: forums, Discord or Slack groups, meetups, and open source support.

A full DevRel team covers all four. A fractional lead decides which one or two matter most for you right now and gets those moving.

Studio1 example: Studio1 brings together technical content, developer advocacy, video production, and documentation and developer experience audits. That illustrates the team-based support available alongside fractional leadership. A company might need a senior lead to choose its priorities, a partner to execute them, or a scope that combines both.

What does a fractional DevRel person do each month?

It depends on the tier you buy, but the work usually falls into five buckets.

Strategy. Pick the goal (more sign-ups, more people finishing setup, more integrations built by others) and decide which programs to run and which to drop.
Developer experience review. Sign up and build something with your product as a new user would, then write down every stumble. This is often called a friction log.
Content and docs direction. Decide what to publish, fix the getting-started path, and set a standard for tutorials.
Community and advocacy setup. Start the first programs, such as an office hours call, a champion group, or a conference plan.
Coaching and reporting. Mentor any advocates or writers you already have, and send leadership a short monthly update against agreed numbers.

When the real limit becomes capacity, a good fractional lead also writes the job description and helps you hire the full-time person.

What this could look like with Studio1: Imagine an API startup whose developers sign up but struggle to complete their first integration. A scoped Studio1 engagement could combine a developer experience audit, an integration guide, and a product walkthrough video. A fractional lead could set the activation goal and review the results, while the startup’s engineers fix product issues. This is an illustrative scope, not a claim about a specific client engagement.

How much does fractional DevRel cost?

Most fractional DevRel engagements cost between $4,000 and $15,000 per month. Part-time leaders working 10 to 20 hours a week usually sit at $8,000 to $15,000. Hourly rates run from about $200 to $350 for senior people.

Here is what published sources say. Most of these companies sell DevRel help themselves, so read these as ranges, not quotes.

Source	What it describes	Price
Yalla DevRel	Part-time Head of DevRel, three tiers (advice only, hands-on, embedded)	About $4,000, $8,000, and from $15,000 per month
Go Fractional	Live market benchmark, about 13 hours a week	$10,400 to $18,200 per month
MarketerHire	DevRel-only retainer with one senior person, 4 to 8 tutorials a month, 2 conference talks a quarter, and community work	$8,000 to $15,000 per month
Metaflow (citing SlashDevRel and DevRel Collective)	Part-time DevRel leadership, 10 to 20 hours a week	$8,000 to $15,000 per month

The numbers agree more than they disagree. The low end is advice only, a few calls a month. The middle is a senior person doing real work alongside your team. The top is someone who owns the whole roadmap.

What the hourly numbers look like

Go Fractional's page, last updated on October 14, 2026, shows an average rate of $278 an hour and a median of $250. The middle 50% of rates fall between $200 and $350. A typical scope is about 13 hours a week, which is roughly a third of a full-time week.

The monthly math is simple: 13 hours a week, times 4 weeks, times the hourly rate.

At $200 an hour, that is $10,400 a month.
At $278 an hour, about $14,400 a month.
At $350 an hour, that is $18,200 a month.

Two honest warnings. First, Go Fractional says the sample is small, based on 2 job posts and 5 candidate profiles from the last 90 days, and calls the figures directional. Second, there is a gap between sides of the market. Employers in live listings offered about $100 an hour on average, while candidates asked for about $300. If you are shopping, expect some room to talk.

Why the hourly rate looks high

Compare it with a salary and the hourly number looks steep. A $200,000 full-time hire works out to roughly $96 an hour across a 2,080-hour work year (that is 40 hours times 52 weeks). A fractional lead costs more per hour. You save because you buy far fewer hours, and you do not pay for the months it takes to find and onboard someone.

What moves the price

Go Fractional lists four things:

Scope of ownership. Running the whole program costs more than helping with one piece.
Stage and urgency. Rush work and turnaround jobs cost more.
Location rules. Remote-first widens the pool of people you can pick from.
Specialty. Deep experience in your kind of product, such as AI or security, pushes rates up.

Some providers, like Yalla DevRel, price by how much the person owns instead of by hours logged. Ask which way you are being quoted.

For a Studio1 proposal, define the deliverables first: A docs audit and two technical tutorials are a different scope from an ongoing program that includes strategy, videos, community work, and distribution. Ask for a quote against the work you need. The market benchmarks in this article are not Studio1 prices.

A rough guide by company stage

This table is our reading of the ranges above, not a quote from any one source.

Stage	What usually fits	Rough monthly budget
Early, founders still do most things	Advice-only retainer or a short audit	$4,000 to $8,000
Growing, a few developers using the product	One senior part-time lead who also does some hands-on work	$8,000 to $15,000
Scaling, several channels to run	Embedded lead or a small fractional team	$15,000 to $50,000

How DevRel compares with other fractional roles

Go Fractional publishes rates for other part-time roles too, which helps you sanity check a quote.

Fractional role	Average hourly rate
Developer Relations	$278
Chief Technology Officer	$210
Chief Marketing Officer	$174
Senior Software Engineer	$174
Content Creator	$153
Marketing Manager	$119

DevRel sits at the top because few people can write code, teach, and speak to a crowd. Keep in mind the DevRel figure rests on a much smaller sample than the others.

Fractional DevRel vs full-time hire vs agency: what does each cost?

A full-time senior DevRel hire costs $180,000 to $250,000 or more per year fully loaded, meaning salary plus benefits, taxes, and equipment, according to Yalla DevRel. SaaSHero puts a senior hire at $200,000 to $260,000 all in.

The salary alone is already high. A 2026 career guide from SkillScouter lists total pay in the US at $135,000 to $180,000 for a mid-level advocate, $165,000 to $220,000 for a senior one, and $200,000 to $260,000 for staff or principal level. Jobrise shows a similar picture for base pay alone.

Here is how the options stack up.

	Fractional lead	Full-time senior hire	DevRel agency	Fractional team
Typical cost	$4,000 to $15,000 a month	$180,000 to $250,000+ a year	$15,000 to $40,000 a month for a full DevRel, docs, and growth team	$20,000 to $50,000 a month
Who does the work	The senior person directly	One employee	A delivery team; seniority and specialist mix vary	Named senior specialists, 15 to 25 hours a week each
Time to start	Days	3 to 6 months to find and onboard	Weeks	Weeks
Commitment	Month to month	Employment	Often quarterly or longer	Often 3 to 6 months
Best when	You need direction or a first program	Your channels are proven and you need daily capacity	You have a clear plan and need output	You need senior depth across more than one area

Sources: Yalla DevRel for the fractional and full-time rows, and MarketerHire for agency and team pricing.

Where Studio1 fits: Studio1 is an example of an agency partner that combines strategy with technical content and DevRel execution. Its process covers discovery, strategy, creation, distribution, measurement, and iteration. For a buyer, the useful question is whether the proposed scope provides the leadership, delivery capacity, or combination needed. The agency pricing above is a third-party benchmark, not a Studio1 quote.

Yalla DevRel also notes that a bad full-time hire can cost 6 to 12 months before you notice and fix it. That risk is a big part of why teams test the role part-time first.

Who is fractional DevRel for?

It fits you if one or more of these sound familiar:

You sell a product developers use, and nobody senior owns developer adoption.
Developers sign up and then go quiet, and nobody can tell you why.
You have one or two advocates or writers doing good work with no plan above them.
You need leadership now and cannot wait six months for a search to finish.
You want proof the role works before committing $200,000 or more a year.

Small teams are the norm in this field. The 2024 State of Developer Relations survey of 310 people found that the most common team size is 2 to 5 people (35.2%) and that 18.2% are solo practitioners, according to this summary of the data. The same summary says 33.5% of practitioners could not say what their program budget is. A part-time lead can help a team like that decide what to spend on.

On company size, MarketerHire suggests that most devtool companies under $5 million in yearly revenue do better with one senior DevRel hire plus a part-time content lead than with an agency retainer. SaaSHero recommends a fractional consultant at the seed stage and a bigger partner by Series B. Both are vendors, so use them as a starting point.

Studio1 example: A devtool startup preparing a launch could need technical tutorials, a demo video, and distribution across developer channels. Studio1’s technical content, video, and launch-support services are relevant to that execution need. If nobody internally owns the adoption strategy, make that responsibility explicit in the engagement or assign it to a fractional lead.

Who should skip fractional DevRel?

Be honest with yourself here. Fractional is the wrong call when:

You need daily output. A conference circuit, a full content calendar, or a busy community cannot be run by one part-time person.
Your plan already works. If you know exactly what to do and need more hands, an agency or a full-time hire fits better.
Nobody can act on the advice. A fractional leader multiplies a team. They cannot stand in for one.
You want results without changing the product. If developers are stuck because the product or the docs are broken, DevRel can point at it, but someone has to fix it.

Yalla DevRel makes the same three points on its own page, which is a good sign that the advice is not just a sales pitch.

If your bottleneck is producing and distributing technical content, a delivery partner such as Studio1 may be a better fit than an advice-only retainer. For example, an agreed tutorial series could be supported by demo videos and distribution on X, LinkedIn, and relevant developer communities. Confirm the publishing cadence and channel ownership in the scope.

Are you ready? A five question check

Answer yes or no.

Do developers use your product, or will they within six months?
Can you name one person inside the company who will act on the recommendations?
Do you know what a good outcome looks like in numbers, even roughly (for example, more new sign-ups making a first call)?
Can you give the person access to your product, docs, analytics, and a few engineers?
Are you willing to change docs or onboarding based on what they find?

Four or five yeses means you are ready. Two or fewer means fix those gaps first, or start with a one-time audit instead of a monthly plan.

How to hire a fractional DevRel lead

Pick the goal first. Adoption, community, better docs, or product feedback. DeveloperRelations.com points out that what you measure should follow why you invest.
Agree on two or three numbers. Good picks include how many people finish the getting-started guide, what share of new sign-ups make a first API call, and how much traffic and sign-up referrals your content brings. Our guide on measuring developer content beyond pageviews covers this in more detail.
Ask for a monthly scorecard. One page, same numbers every month.
Look for shipped work. Ask to see tutorials, talks, or programs they built, and who they were for.
Keep ownership. Docs, code, accounts, and community channels should live in your repos and your accounts, so nothing is stuck with the contractor if you part ways.
Stay month to month. A short commitment keeps both sides honest. A 90-day review is a good checkpoint.

Warning signs: a promise of results on a fixed date, no named person doing the work, vague reports full of reach and impressions, and long contracts before any proof.

Evaluating Studio1? Start with the Studio1 case studies, then ask for examples relevant to your product and goal. Review the technical depth, the intended developer audience, the distribution approach, and the evidence of outcomes. Ask who would lead your engagement and who would write, build, review, and publish the work.

What does the first 90 days look like?

This is a plan that tends to work well for a first engagement. It is a template, not a quote from any source.

Days	Focus	What you should have at the end
1 to 30	Audit	A friction log of the sign-up and setup path, a docs review, and conversations with 5 to 10 real users
31 to 60	Fix and publish	The top onboarding blockers fixed, the first tutorials live, and one community channel chosen
61 to 90	Measure and decide	A scorecard with the first trend lines and a clear call: keep going, scale up, or hire full-time

By day 90, you should know whether DevRel moves your numbers and what the next step costs. That is the main thing you are buying.

Illustrative Studio1 scope for this plan: The first month could focus on a developer experience audit and content priorities. The second could cover getting-started tutorials, an integration guide, a demo video, and distribution. The third could review content referrals and onboarding completion with your team, then decide what to improve or expand. Deliverables, analytics access, and engineering ownership would need to be agreed before work starts.

Frequently asked questions

How much does fractional DevRel cost per month?

Most engagements cost $4,000 to $15,000 a month. Advice-only plans sit near $4,000. Part-time leaders doing hands-on work at 10 to 20 hours a week usually cost $8,000 to $15,000. A live benchmark from Go Fractional shows $10,400 to $18,200 a month at about 13 hours a week, though its sample is small.

How many hours a week does a fractional DevRel person work?

Often 10 to 20 hours a week. Go Fractional's benchmark uses about 13 hours, roughly a third of a full-time week. Some providers price by scope of ownership instead of hours, so ask what you are really getting.

Is fractional DevRel cheaper than hiring full-time?

Yes, in total cost, no per hour. A full-time senior hire runs $180,000 to $250,000 or more a year fully loaded, while a fractional lead at $8,000 to $15,000 a month costs $96,000 to $180,000 a year, and you can stop at any time. You pay more for each hour and buy far fewer of them.

What is the difference between fractional DevRel and a DevRel agency?

A fractional lead usually provides senior leadership personally on a part-time basis. An agency provides a team and may cover both strategy and execution. Studio1, for example, combines technical content, developer advocacy, videos, audits, and distribution. Choose based on whether you need one accountable leader, broader delivery capacity, or both, and confirm those responsibilities in the proposal.

Can a fractional DevRel replace a full-time team?

Not for daily work. One part-time person cannot match a team that is on the job five days a week. They can set the plan, start the first programs, and help you hire the people who will run them.

How long before I see results?

No source gives a fixed answer, and anyone who promises a date is guessing. A sensible expectation is that onboarding and docs fixes show up within the first 30 to 60 days, while steady growth in adoption takes a few quarters.

Do I need a fractional DevRel if I already have a content writer?

It depends on whether anyone decides what the writer should write and why. A writer without a plan produces posts. A DevRel lead ties the posts to a goal, such as getting more people to finish setup, and checks whether it worked.

For example, a Studio1 technical content engagement could focus on tutorials and integration guides that address specific onboarding questions. If your existing team already owns the strategy, that delivery support may be enough. If priorities and success measures are still unclear, assign that leadership responsibility first.

Need help turning your DevRel plan into shipped work?

Studio1 helps developer-first companies with technical content, developer advocacy, product videos, documentation and developer experience audits, and distribution. If you need support beyond planning, share your product, your biggest adoption challenge, and the work your team can already own.

Explore Studio1’s case studies to see examples of its work.

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.