DEV Community: Nancy Garg

10 Projects You Should Build with Jev

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

JEV is getting a lot of attention right now.

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

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

1. Build a smart support ticket router

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

2. Build an inbound lead scorer

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

3. Build a comment moderation system

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

4. Build an AI citation checker

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

5. Build a smarter RAG context picker

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

6. Build a semantic code review bot

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

7. Build an AI model router

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

8. Build an AI agent safety firewall

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

9. Build a browser agent reflex layer

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

10. Build a real-time game AI

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

The bigger idea behind JEV

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

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

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

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

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

TL;DR

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

What is Gemini 4 Argon?

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

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

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

How it differs from the other models

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

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

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

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

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

The test scores

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

Three caveats on reading it.

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

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

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

What it will really cost you

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

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

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

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

What to check before you switch

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

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

What Google has built with it

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

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

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

Where it still loses

This is the part the launch post skips.

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

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

Wrapping up

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

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

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

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

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

TL;DR

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

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

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

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

What is answer engine optimization (AEO)?

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

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

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

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

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

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

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

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

Two patterns show up across the studies.

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

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

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

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

1. Let the right crawlers in

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

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

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Googlebot
Allow: /

Four details trip up a lot of teams:

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

2. Put the answer in the first few lines

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

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

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

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

3. Publish the comparison pages people ask for

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

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

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

4. Make your docs the best answer on the web

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

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

5. Get talked about where AI tools already look

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

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

What to do about it:

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

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

6. Say the same thing everywhere

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

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

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

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

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

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

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

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

Can programmatic pages help your product get recommended by AI?

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

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

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

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

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

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

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

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

Then add the numbers your tools already give you:

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

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

What mistakes keep developer products out of AI answers?

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

Frequently asked questions

How do I get my product recommended by ChatGPT?

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

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

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

Do backlinks still matter for AI visibility?

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

Do I need an llms.txt file?

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

Do I need schema markup?

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

Should I block GPTBot?

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

Is AEO different from SEO?

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

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

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

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

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

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

TL;DR

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

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

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

What is Opus 5.5?

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

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

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

How it differs from the other models

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

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

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

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

What breaks when you switch

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

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

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

What it will really cost you

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

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

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

A few other prices, if you're budgeting:

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

The Test Scores

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

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

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

What people have built with it

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

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

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

Where it still loses

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

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

Wrapping up

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

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

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

What is Jev? In 5 minutes

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

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

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

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

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

TL;DR

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

What exactly is Jev?

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

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

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

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

How Jev Is different

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

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

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

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

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

The pattern: Claude thinks, Jev decides

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

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

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

Usecase

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

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

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

How to start?

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

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

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

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

When not to use Jev?

A few situations where you still have to use LLM:

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

Conclusion

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

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

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