One Model Does Not Fit Every Task
Per-task AI engine and model selection is live: choose Claude, Cursor or Codex separately for detection, sections, recommendations, articles and videos.
The question kept arriving in different words, but it was always the same question. Why is the model that writes a polished, illustrated help article also the model that works out which CSS framework a repository uses? One of those is a writing job with taste in it. The other is closer to a lookup - open some files, match some patterns, write down the answer. Paying frontier prices for the second one to subsidise the first is a strange way to run a pipeline.
So we stopped doing it. Engine and model are now chosen per task, not per project.
Six tasks, not one job
The pipeline was never a single call. It has always been six distinct jobs, and until now they all inherited one project-wide setting:
| Task | What it actually does |
|---|---|
detect |
Branding, design tokens and structure detection |
sections |
Proposing the help centre's section structure |
recommendations |
Suggesting article topics from sections and code changes |
articles |
Writing illustrated articles, prose plus screenshot mockups |
walkthroughs |
Producing the mockups and click-path for walkthrough videos |
change_analysis |
Analysing merged pull requests and commits |
Look at that list and the mismatch is obvious. detect runs once per project and produces a JSON file. articles runs constantly and produces the thing your customers read. Those should not be the same spend.
In the AI Settings tab each row now carries its own engine and model picker, stored as an engine/tier key. Three engines are available: Claude, Cursor and Codex. A task you never touch falls back to the project-wide setting, so nothing changes until you decide it should.
The defaults already reflect this
We did not just expose the knob and wish you luck. The defaults encode what we learned running the pipeline ourselves.
On Cursor projects, detect, sections and recommendations default to Grok 4.5 High - fast, cheap, and entirely adequate for structured extraction where the output is a schema rather than a paragraph.
On Claude projects the split is the same idea drawn differently. Four tasks are pinned to Sonnet in the task definitions - detect, sections, recommendations and change_analysis, all of which produce structured output. The two that are not pinned are articles and walkthroughs, and because they have no pin they fall through to the project-wide default, which is Opus.
So the expensive model runs on the two tasks that produce prose a customer reads, and the cheaper one runs on the four that produce JSON. That is the whole idea, and the defaults now encode it rather than leaving it to you.
The fallback chain is worth understanding before you start changing things, because it is the part that will confuse you at 11pm. A task with an explicit engine/tier uses it. A task without one falls back to the project-wide engine setting, and then to that engine's default tier - except where the task definition pins a tier of its own, which is how the Sonnet defaults survive on Claude projects. In other words, an empty row is not "no model", it is "whatever you had before this feature existed". Nothing silently changed underneath anyone.
Three limits, all of which will annoy someone
The per-task settings cover the six core pipeline tasks only. The non-core changelog jobs - scanning features, generating feature posts, checking articles for updates - still read the legacy project-wide setting. They were lower value to split and the migration was already large enough. They will follow.
Cursor's headless output reports no token or cost data at all. Not partial data - none. So if you move a task to Cursor, that task's row in your usage and cost telemetry goes blank. It is still running, you simply cannot see what it cost from inside our dashboards. Codex is better here: it reports token usage but no cost, so tokens populate and the money column stays empty. Only Claude gives us both.
Third, there is no per-task quality benchmark in the product. Choosing a cheaper model for recommendations is currently a judgement call you make and then check by looking at the output, which is a fair thing to ask of an engineer and a slightly unfair thing to ask of everyone else. A comparison view is the obvious next thing to build.
Where to find it
Admin, then the AI Settings tab. The six rows are already there with the new defaults applied.
If you have been running everything on one model because that was the only option, change detect first and re-run onboarding on a spare project. That is the cheapest place to see whether the idea holds.
About the Author
Simon Moxon has been building SaaS companies since 2009. He's scaled teams to 20+ people, hit £2m ARR, and learned most of the lessons the hard way. Now he's building SupportPages.io - help docs that write themselves when you ship code. He writes about what's changed in SaaS and what hasn't.