Last week, Reducto announced r-1, a new document parsing model that replaces its previous multi-stage system with a single full page pass. The company states this approach is faster, cheaper, and more accurate than its legacy agentic models.
The model is available in preview via Reducto’s hosted Parse API on V3. Users enable it with a configuration flag. There are no open weights and no local checkpoints for self-hosting. Reducto supports multi-tenant cloud, customer VPC, on-premises, and air-gapped installs. Higher tiers include SOC 2 Type II attestation and HIPAA processing, according to its security policies.
One pass instead of a pipeline
The old system ran OCR, layout detection, and post-processing as separate stages. Optional agentic vision language passes were layered on top. Each extra model call added latency. r-1 folds text, tables, figures, layout, reading order, formatting, and grounding into one full page pass. Every block returns with page relative bounding boxes that tie content back to its position on the page.
The consolidation is the main product claim. Teams working on financial statements, insurance claims, or contracts often route files across several providers and bolt on post-processing to reach usable accuracy. r-1 targets that orchestration cost, not only raw character accuracy.
The numbers
Reducto reports a 20% reduction in error rate for the early r-1 preview against its own legacy agentic pipelines. It also states that r-1 outperformed commonly used hyperscaler products and large LLMs on complex documents in internal evaluations. Amazon Textract and Azure Document Intelligence are named in the release as the incumbent baseline category.
On price, legacy agentic models ran between 3 and 6 cents per page depending on workload. r-1 is 1 cent per page, all in, with no feature multipliers or credit costs layered on to reach high accuracy. Reducto frames this as part of a wider move to flat product rate cards.
Please note that the 20% error reduction is measured relative to Reducto’s own prior pipeline, not to a third party baseline. And the head-to-head against hyperscalers and LLMs is vendor run, with no public eval harness or dataset released alongside the announcement.
What r-1 resolves on the page
Per the documentation, r-1 handles the following natively in the full page pass: digital text, scans, and handwriting; table structure read with surrounding page context, including merged cells and nested headers; columns, headers, footers, sidebars, and reading order resolved together; figure detection with a short generated description; formatting that carries meaning, including headings, lists, bold, underlines, and strikethroughs; and grounding through page relative bounding boxes.
The long tail cases Reducto calls out are dense tables, unusual layouts, low quality scans, watermarked content, and documents that follow no predictable template. A dropped strikethrough can invert a contract clause, and a misread table can hand an agent the wrong figure, which is why these edge cases carry weight in regulated pipelines.
Migration path and what stays on the old stack
r-1 requires the V3 API. A Parse request that omits settings.model still runs on legacy Parse, so nothing breaks silently. New pipelines created in Studio default to r-1.
Agentic processing is not gone. Workflows needing custom prompts or advanced chart extraction still route those pages through the agentic pipeline, which Reducto augments onto the r-1 result, and which adds latency. Teams migrating an existing configuration should check the r-1 configuration compatibility page first, since some legacy settings are ignored or unsupported.
Reducto has also signalled the next two pieces: r-1 mini for speed and cost sensitive workloads, and automatic per page routing that picks the right model for each page. Organisations moving off another parser can request up to $5,000 in credits for a side by side comparison.
What it means
For people building applications that read documents, the shift means fewer API calls and lower costs per page. The model handles complex layouts in one go, which reduces the need to stitch together multiple tools. Teams using legacy systems can switch gradually without breaking existing code.
