We ran the same research prompts in Codex, Cursor, Antigravity, and Claude Code with native web search and with Bonsai. Bonsai often costs more per session — but leaves official pages on disk, scores higher on accuracy, and reuses cleanly. Popular library docs worked either way; client-rendered enterprise portals usually did not.
Three prompts, four agents: native web search vs the Bonsai workflow. Scores weight official-source grounding, technical accuracy, and inline delivery — not who spent fewer tokens. On the SFCC prompt, Codex burned ~80k native tokens for no answer; Bonsai captured the official guide. Session benchmarks →·SFCC scenario →
Mainstream docs (TanStack, RSC)
Native often matches inline depth
Comparable answers — Bonsai adds pages on disk
Enterprise docs (client-rendered)
Native often wrong or empty
Codex ~80k tokens, no answer; schema bugs in others
Grounding per session
12/12 Bonsai runs cached official pages
0/12 native — snippets, mirrors, or nothing to inspect
Cursorgrounded
76%research grounding
SFCC native (16k) was deployable via mirror; Bonsai (30k) cached the official Salesforce guide. TanStack and RSC native runs were often cheaper with comparable inline depth.
Claude Codemixed
68%research grounding
Deepest TanStack answer — after an 83.5k-token recovery from a failed workflow. SFCC native was cheapest among the original three (32.5k) but still wrong on steptypes.json.
Codexmisses hard docs
52%research grounding
Solid TanStack and RSC overviews, but SFCC burned ~80k tokens with no usable answer. Bonsai runs cost more when they capture more official pages (+24% on TanStack).
Antigravitydeferred
45%research grounding
Lowest context on SFCC (3.4%) — and still mock data plus invalid status returns. Depth often lives in brain artifacts while the chat stays short.
When native web search is enough — and when it is not
We ran three research prompts twice in Codex, Cursor, Antigravity, and Claude Code: native web search, then the Bonsai workflow.
On TanStack Query and React Server Components, native search plus training data often produced inline answers close to Bonsai. In Cursor's TanStack run, native WebFetch matched Bonsai's depth at 31k vs 47k tokens. Nothing from that native run landed on disk for the next session.
Enterprise and vendor documentation was different. Our benchmark used a Salesforce B2C Commerce job-step prompt as the hard case; the same failure modes appear on other client-rendered portals. Codex spent ~80k tokens and produced no usable answer. Claude and Antigravity wrote confident guides with subtle schema mistakes. These hosts render in the browser, gate content behind cookie consent, and rewrite URLs when products rebrand. A generic fetch often gets an empty shell or a search snippet, not the article you meant to cite.
That is what site modules are for: host-specific fetch and extraction when the generic pipeline fails. Salesforce Help and Developer ship as a reference implementation; the same pattern covers any SPA-heavy docs site.
The hero animation uses Codex's enterprise SFCC prompt from the research benchmark: ~80k native tokens, no usable answer, versus ~74k with Bonsai and official pages on disk. Grounding climbs from no capture to 100% as the tree compresses — same order of spend, very different outcome.
bash
# Fetch, extract, convert to Markdown, and cache — one commandnpx @taurgis/bonsai https://nodejs.org/api/url.html# Run it again — served straight from the local cache while freshnpx @taurgis/bonsai https://nodejs.org/api/url.html
Bonsai requires Node.js 22 or newer and is published as @taurgis/bonsai. Head to Getting Started to fetch your first page, or read Why Bonsai? for the reasoning behind the cache.