Reducto

Editor’s note: My Reducto review is based on independent analysis of documented workflows, specifications, and pricing, rather than firsthand product testing.

Quick verdict: I recommend Reducto for engineering teams that need document content with source coordinates or schema-defined fields. Its appeal is the combination of Parse, Extract, and visual configuration in Studio, but model defaults and privacy terms need deliberate attention before production.

Reducto sits in the document parsing layer of the AI data stack. It can prepare document content for retrieval or return named fields for business workflows. Those are different jobs, and I like that the product separates them rather than treating every document as a text dump.

My main reservation is that the simplest advertised rate does not describe every configuration. The r-1 model is an opt-in preview on the API, while stronger privacy commitments require Growth or Enterprise. In this review, I’ll look at pricing, Studio’s workflow, and the output and deployment controls that matter when choosing a document parsing API.

Key Takeaways

• Parse returns document content; Extract returns schema-defined fields and includes internal parsing.
• Studio supports visual schema creation and source-highlight inspection before API deployment.
• Eligible asynchronous Parse and Extract jobs receive a 20% batch discount.
• r-1 is a preview, and API requests remain on legacy Parse unless explicitly configured.
• Growth and Enterprise privacy commitments do not automatically apply to Standard accounts.

Pros and Cons

I like Reducto’s output controls more than its default configuration story. The capabilities suit developers, but using them responsibly still requires engineering ownership.

How Much Does Reducto Cost?

Reducto’s Standard rates start at $10 per 1,000 pages for r-1 Parse. Standard Extract costs $20 per 1,000 pages, including parsing, so I would not budget an additional Parse charge for its internal processing.

The account plans determine purchasing terms and controls:

• Standard: Pay-as-you-go. My starting point for a small, non-sensitive pilot, with $150 in free usage and up to five Studio seats.
• Growth: Custom pricing. My shortlist for volume discounts or contractual privacy requirements, including a ZDR agreement and BAA.
• Enterprise: Custom pricing. The option for customer-infrastructure deployment and enterprise access controls.

Plan	Price structure	Studio seats	Notable provisions
Standard	Pay-as-you-go	Up to 5	$150 introductory usage; no page-volume limit
Growth	Custom quote	Unlimited	Volume discounts, ZDR agreement, BAA, priority support, EU/AU endpoints
Enterprise	Custom quote	Unlimited	VPC/on-premises, custom SLA and throughput, RBAC, SSO/SAML

Standard’s lack of a page-volume limit is not a throughput guarantee. I would separate total processing budget from the concurrency and response-time requirements of an application.

The public offer is $150 in free usage. The pricing FAQ also describes 15,000 free credits, but that is not a universal allowance of 15,000 pages across every endpoint. I would treat it as introductory credit, not a recurring monthly free plan.

Operation	Standard list rate per 1,000 document pages	Billing distinction
r-1 Parse	$10	Preview model requiring explicit API selection
Legacy Parse, standard pages	$15	Legacy standard-page rate
Legacy Parse, complex pages	$30	Legacy complex-page rate
Extract	$20	Internal parsing included
Deep Extract	$40	Internal parsing included; batch discount unavailable

Legacy agentic modes carry a 2x multiplier. These rates describe current pay-as-you-go pricing, not every existing contract. Contracted accounts retain their negotiated structure until renewal, so I would compare an account’s rate card rather than assume a universal migration.

What Changes the Bill?

r-1’s optional OCR data and/or Parse citations add $2 per 1,000 pages, charged once per page even when both are requested. Prompted blocks or custom regions add $5 per 1,000 pages. The advanced chart agent costs $0.06 per detected and processed chart, making chart density a separate budgeting variable.

Dense Extract and Deep Extract jobs with over 100 fields per page may incur a per-field surcharge whose amount is not given in the public table. Spreadsheet billing is cell-based rather than ordinary page-based. For either workload, I would request an account-specific estimate before extrapolating a PDF pilot.

For an illustrative 100,000-page document workload, choosing one endpoint per page gives these base costs:

Workload	Regular usage	Eligible batch usage
r-1 Parse	$1,000	$800
Extract	$2,000	$1,600
Deep Extract	$4,000	Not eligible

That arithmetic excludes introductory credit, tax, add-ons, dense-field surcharges, and negotiated discounts. Separate independent endpoint calls can still create additional charges. A workflow that deliberately calls Parse and then Extract is different from Extract’s included internal parsing.

Is Reducto Good Value for Money?

I see the value in buying a defined document-processing component, not in assuming the lowest page rate covers a finished application.

• For field extraction: Included parsing makes the base Extract budget easier to understand.
• For backfills: Batch pricing is attractive when a 12-hour completion window is acceptable.
• For dense forms: Unspecified surcharge amounts weaken self-service cost predictability.

I recommend Standard for a non-sensitive engineering pilot. I would move the purchasing conversation to Growth immediately if retention or BAA requirements determine whether documents can be uploaded at all.

Getting Started With Reducto

Studio supports a visual path from an uploaded document to a configured extraction schema. I would start there to define the output contract, then move to direct API endpoints for application integration.

The documented workflow is:

1. Create or join an organization in Studio, then choose Create pipeline and Extract.
2. Upload a sample document representative of the intended workload.
3. Define the schema through natural-language Generate instructions, using Fast or Enhanced mode, or through the manual builder.
4. Enable citations and run the configuration, then inspect Results against source highlights.
5. Create an API key and use Deploy code snippets as the bridge into application code.

For a hypothetical invoice workflow, I would request an invoice number, currency, total, and an array of line items. The line-item objects would contain descriptions and numeric amounts rather than one unstructured string. Each field needs a description precise enough to distinguish it from similar values on the page.

The useful work happens in the field descriptions. “Total” is ambiguous if a document contains a subtotal, tax amount, and balance due. I would describe which figure the application expects and establish how missing information should be handled before expanding the schema.

Studio’s source highlights matter because valid JSON alone says little about whether a value came from the right location. I would compare the invoice-level total with the relevant source text and inspect line items separately. A document can have a correct headline amount while individual rows remain unsuitable for downstream accounting.

Keep Studio and API Settings Aligned

New Studio pipelines default to r-1, but the API defaults to legacy Parse. r-1 requires V3 and an explicit settings.model value of r-1; V2 requests remain legacy. I would record that setting alongside the schema so a Studio configuration and a production request do not silently target different processing paths.

The /pipeline endpoint is deprecated. Studio itself is not: its configuration and deployment workflow remains documented. For new integration code, I would use the current direct endpoint appropriate to the job, such as /parse or /extract, rather than build around old pipeline_id calls.

API adoption also needs result handling, not just document submission. Python, Node, Go, and REST are documented options; the application must still collect asynchronous results and preserve anything it needs beyond Reducto’s retrieval window.

Reviewer’s Notes: I would treat the model selector, schema, citation settings, and application validator as one versioned configuration. A visual prototype is useful only if production preserves the same output expectations.

Parsing Documents for RAG

Parse returns whole-document content organized into chunks and typed blocks, rather than named business fields. I consider that the more appropriate starting point for RAG document parsing when the application needs broad access to a document’s contents.

r-1 processes text and layout together and returns block-level bounding boxes. Its documented input support includes handwriting and scanned text, but that capability list is not an accuracy guarantee for a particular corpus. I would judge suitability by whether the resulting structure preserves the relationships retrieval needs.

Tables make the distinction concrete. Flattening a merged header can detach a number from the category that explains it. Reducto offers several table representations, and I would choose based on the downstream consumer rather than defaulting to the most readable text format.

Setting	Documented behavior	My practical recommendation
HTML tables	Preserves merged cells	Prefer when header relationships matter
Markdown or JSON tables	Flattens merged cells	Check whether flattening loses meaning
Variable chunking	Size measured in characters	Do not treat the setting as a token budget
Section chunking	No size ceiling	Apply downstream size checks
Disabled chunking	Returns one chunk	Use when the application owns segmentation

The other chunking modes are page, page_sections, and block. Variable size 1,000 targets roughly 750 to 1,250 characters, not tokens. That difference matters when planning embedding inputs; a character setting is not a promise that every chunk fits a model’s token limit.

I like the separation between searchable text and retained structure. Header, footer, and page-number filtering can remove those blocks from content and embed while preserving them in chunks[].blocks. That gives the application cleaner search material without necessarily discarding the metadata needed for document display.

With embedding_optimized, Reducto creates table summaries in embed while retaining original formats in content. I would use that separation intentionally: search-oriented summaries and answer-supporting source content serve different purposes. Reducto does not provide the complete retrieval stack; embeddings and the vector database remain application responsibilities. I would also consider Unstructured if the larger job is scheduled ingestion from repositories: its connector, scheduling, and embedding features cover more of that workflow.

Citations Introduce Configuration Trade-Offs

Block-level bounding boxes are distinct from optional word and cell citations. On r-1, return_citations supplies finer positions through the paid OCR add-on, but figure blocks do not have word/cell citations.

It is also incompatible with merge_tables: combining them returns HTTP 400. Table merging can join consecutive same-column-count tables using semantic checks, yet may incorrectly join unrelated tables. I would prioritize precise source localization or cross-page continuity explicitly rather than assume both settings can be enabled together.

Migration deserves similar care. r-1 does not support jsonbbox table output or track_offsets, and some legacy settings are ignored. I would review those dependencies before changing an existing parser configuration.

Extracting Structured Data

Extract is the better fit when the application knows which fields it needs. It parses internally and returns schema-defined data, avoiding the need to build a separate field-extraction layer on top of whole-document chunks.

I like that distinction for invoice intake or document-driven database updates. A retrieval system may need everything a contract says; a business workflow may need only a contract date and renewal term. Paying for structured data extraction makes more sense when that output contract is clear.

For the hypothetical invoice, my schema would distinguish these shapes:

• Scalar fields: Invoice number, currency, and total, each with a concrete description.
• Repeated records: A line-item array with consistently defined object properties.
• Missing information: Application rules for null values and empty arrays.

Reducto returns every declared field, even when it is not marked required. Missing scalar values may return null, arrays may be empty, and objects may contain null subfields. I would not equate a present key with a successfully extracted value.

Schema enforcement also has limits. Types, declared properties, enums, and patterns are enforced with documented null exceptions. Keywords such as format, uniqueItems, conditional rules, and allOf are best-effort, so client-side validation remains necessary when those constraints affect acceptance.

Even bounds need attention: removing empty items can leave an array below minItems, and exclusive noninteger numeric bounds may behave inclusively. My application validator would check business meaning as well as JSON shape, particularly before posting amounts to a financial system.

Source Evidence and Deep Extract

Extract citations wrap scalar values with their value and supporting citation data, so enabling them changes the response shape. The metadata can include source content, bounding boxes, and confidence signals; spreadsheet citations use sheet, row, and column coordinates.

Citation arrays can be empty for inferred values or localization failures, and Extract citations disable chunking. I would route important fields without usable support to review rather than treat confidence as a calibrated correctness probability.

Deep Extract iteratively checks output against the source using verification criteria in prompts. A financial workflow could ask it to reconcile transaction sums or row counts. However, it cannot recover data absent from Parse, which limits what a second extraction pass can solve.

At twice standard Extract’s base price, I would reserve Deep Extract for workflows with meaningful verification requirements. I would still retain arithmetic checks and human review for exceptions; the iterative mechanism is not a substitute for the application’s acceptance rules.

Deployment, Privacy, and Production Limits

Growth and Enterprise carry the documented ZDR and no-training commitments; I would not extend those terms to Standard. Under the ZDR policy, API-submitted data expires within 24 hours, with exceptions for Studio-run jobs and persist_results:true.

That is not instant deletion. The persist_results:true setting keeps results indefinitely and requires opting into Studio, so a visual development workflow and an ordinary API workflow should not be assumed to have identical retention behavior.

Result availability is a separate clock. Job results generally remain available for 12 hours, while result, image, and PDF URLs last one hour. I would download required artifacts into application-controlled storage promptly, rather than treat temporary URLs as permanent evidence references.

Reducto documents encryption in transit and at rest and states completion of SOC 2 Type I/II, with reports available on request. HIPAA processing and a BAA are offered for Growth and Enterprise. I would review the agreement for the intended workload rather than read those provisions as blanket coverage for every account.

Deployment Boundaries Matter

Hosted SaaS is not the only arrangement, but the private options differ:

• Hybrid VPC: Customer storage with Reducto-managed ephemeral compute.
• Full VPC or on-premises: Customer infrastructure using Kubernetes and PostgreSQL.
• Enterprise contracts: Custom SLA, throughput, and access-control provisions.

Hybrid does not mean all computation stays inside the customer’s VPC. Full deployment also transfers runtime security responsibility to the customer, so I would include infrastructure operations in the cost comparison. For a team prioritizing locally operated open-source conversion, I would put Docling alongside this option before committing to an Enterprise contract.

Growth lists EU/AU endpoints. The EU residency terms keep document ingestion, temporary storage, computation, and deletion in the EU, while aggregate operational metrics may leave it. Regional selection therefore deserves a contract-level review, not just a changed endpoint.

Build Around Asynchronous Work

Direct uploads are limited to 100 MB; presigned uploads support up to 5 GB. Synchronous jobs face a 15-minute edge timeout, including queue waits, making asynchronous jobs and webhooks my preference for bursts or long documents.

The discounted batch queue offers a documented 12-hour completion guarantee for eligible asynchronous Parse and Extract jobs. That is distinct from an application’s interactive SLA. Deep Extract is ineligible, and combining it with batch priority returns HTTP 400.

Hosted model changes also need regression planning. Previous versions remain accessible for two weeks after replacement, but fully frozen hosted snapshots are not offered. I would maintain representative documents and output checks; a fixed request schema alone does not freeze model behavior.

How Does Reducto Compare to Alternatives?

I would compare Reducto alternatives by the responsibility being outsourced, not by assuming each vendor’s page rate buys equivalent output.

• Unstructured: My shortlist for ongoing ingestion across repositories. It documents scheduling, incremental processing, embedding generation, and 40+ source/destination connectors, giving it a broader ETL scope than a single extraction call.
• LlamaParse: Worth comparing when tiered parsing costs are the priority. Its lower-cost modes deserve attention, but Fast returns spatial text rather than Markdown, so I would match output requirements before comparing bills.
• Docling: My starting point for local or air-gapped conversion. Its code is MIT-licensed, with separate model licenses to review, and hosting and maintenance remain the operator’s responsibility.

Product	Published pricing basis	Documented scope	Main buying distinction
Reducto	r-1 Parse $10/1,000 pages	Parse, schema extraction, citations	Managed parsing and named-field output
Unstructured	$15/1,000 pages after introductory allowance	Managed ingestion and ETL	Broader connector-driven workflows
LlamaParse	$1.25 to $56.25/1,000 pages by tier	Tiered managed parsing	Mode-dependent cost and output
Docling	MIT code; infrastructure costs separate	Local conversion and self-hosted serving	Operating control rather than hosted billing

LlamaParse’s calculated base rates per 1,000 pages are $1.25 for Fast, $3.75 for Cost-effective, $12.50 for Agentic, and $56.25 for Agentic Plus. Layout extraction adds $3.75 per 1,000 pages. Those tiers are not benchmark-equivalent to r-1.

My preference would depend on what remains after parsing. Unstructured makes sense when ingestion orchestration is the larger problem; Docling makes sense when local control dominates. Reducto earns its place when schema fields and source metadata are central requirements.

How I Reviewed Reducto

My assessment is an independent analysis of Reducto’s documented workflow, output contracts, pricing, and deployment specifications. I evaluated how configuration choices affect integration and purchasing decisions, rather than assigning a measured accuracy or speed score. The cost examples are arithmetic from published rates, not observed invoices, and my recommendations reflect practical consequences of the documented settings.

Prices are current as of October 2026.

Should You Choose Reducto?

I would shortlist Reducto for an engineering team that needs source-aware document output and is prepared to own validation. Parse and Extract serve meaningfully different needs, while Studio provides a visual route to defining the extraction contract.

My recommendation is conditional on configuration discipline. Make the model explicit, budget the required add-ons, and choose the privacy tier before uploading sensitive material. Those decisions affect whether the service fits more than the headline page price does.

I would start a non-sensitive pilot on Standard and consider Growth or Enterprise when contractual controls dictate the purchase. I would skip Reducto for a simple one-off conversion or a firm preference for local open-source software. For those buyers, its managed API capabilities may be more than the job requires.

Frequently Asked Questions

Is Reducto free?

Standard includes $150 in introductory usage. I would not treat it as a perpetual monthly free plan or assume the FAQ’s 15,000 credits equal the same number of pages for every endpoint.

Does Reducto replace a RAG stack?

No. It supplies parsed content, chunks, and metadata. I would still plan for an embedding model, storage, retrieval logic, and the application that generates answers.

Is Reducto open source?

No. Enterprise VPC and on-premises deployment do not make Reducto open source. I would compare Docling if locally operated, openly licensed code is a primary requirement, while reviewing its model licenses separately.