A Firecrawl alternative that is an index, not a crawler.
Firecrawl is a capable tool for what it is: you submit a URL or a crawl job, it fetches and converts on demand. Lyrenth starts from the opposite end: a standing index of 1.1B+ pages already cleaned into AIDocuments, kept fresh, and served in one call. If your agents read the web continuously, the difference compounds on every request.
The structural difference, stated plainly. Both approaches are legitimate; they optimize for different jobs.
| Fetch-on-demand tools | Lyrenth | |
|---|---|---|
| Model | Crawl or scrape when asked; every caller triggers work | Standing index; reads are lookups, crawled only on a miss |
| Repeat reads | Re-fetch or per-customer cache | One canonical AIDocument served to every caller |
| Output | Markdown / extraction output | Full AIDocument: markdown, structure, signals, cache truth, token economics |
| Origin impact | Scales with your usage | Amortized across all users of the index |
| Crawler identity | Varies | Verified bot: signed requests, published IPs, rDNS, robots.txt honored |
Honest scoping: if you need arbitrary site-wide crawl jobs on domains nobody has indexed, a job-based crawler is the right tool. If your agents read public pages continuously, an index is.
Real pages, read through the production index, with the economics the API itself reports:
| Stripe API reference | 307,902 raw | 2,000 indexed | 99.4% saved |
| GitHub REST API quickstart | 88,614 raw | 4,876 indexed | 94.5% saved |
| React useState reference | 111,042 raw | 8,156 indexed | 92.7% saved |
Switching is one endpoint: POST /v1/aidocument with a URL, or npx -y lyrenth-mcp for any MCP client. Free tier is 2,000 reads a month with no card, enough to run it against your real workload before you decide anything.