Agentic Document Extraction Pricing Core Concepts

What drives the cost of a document processing job?

The same one-page invoice costs 1.9 credits or 0.4 credits, depending on two choices you make when you call the API. Nothing about the document changed - only the service tier and the model.

Agentic Document Extraction (ADE) bills in credits, and three things determine how many a job consumes: the service tier, the model, and the characters returned. Each one is a choice you control, not infrastructure you have to build. Measured per thousand pages, ADE Gen2 pricing sits at or below common industry benchmarks, and teams migrating from ADE Gen1 should see 25% to 80% lower per-page costs on typical mixed workloads.

This guide covers how credits work, how to buy them, and how each of the three factors moves the number. By the end you should understand the core principles behind ADE pricing, know which levers you control on each job, and be able to read a real API response to see exactly what that job cost and why.

Everything runs on credits

ADE bills in a single unit: credits. One credit equals one US cent, so one dollar buys 100 credits. That value is universal: a credit is worth the same amount on every plan and in every region.

Credits are also fungible across the product. Every ADE service draws from one shared balance, so you track a single number for the whole product.

How to buy credits

There are two ways to purchase credits, depending on how you buy software.

• Self-service. Buy credits by credit card at ade.landing.ai and start immediately. This is the fastest path for individual developers and teams that want to test a workload or run in production without a contract.
• Enterprise. Larger commitments run through annual agreements and standard procurement. This path suits organizations that need volume terms, invoicing, and a signed contract.

Both paths spend the same credits at the same rate. What differs is how you buy and commit; a credit is worth the same once you have it.

The same usage everywhere: Playground, API, and SDKs

Each ADE service consumes credits from your balance, and for the same service tier the amount consumed is identical no matter how you call it. Running a job in the visual Playground, through the REST API, or with the Python or TypeScript SDKs draws from the same balance on the same rate card and the same billing logic.

One point of nuance: the Playground always runs at the Priority tier, so the credit figures you see there reflect Priority pricing. The API lets you choose the tier. Standard is the default option and is about half of Priority, so the same job run through the API on Standard costs less than the Playground shows. You can prototype a document in the Playground, then move the same job to the API at Priority, and the cost will not change; move it to Standard and it drops to roughly half.

The exact per-service credit formulas, for Parse, Extract, and the rest of the ADE services, are published on the Credit Consumption page within docs.landing.ai. Treat the documentation as the authoritative reference for current ADE pricing on any service.

The three factors that drive credit usage

Once credits are in your balance, three factors determine how many a given job consumes: the service tier you choose, the model you run, and the number of characters processed.

1. Service tier: how quickly you need the response

The service tier is the lever you control most directly. It sets how fast the result comes back. The same work, run at a different speed, costs a different amount.

Service tier selection applies to both Parse and Extract. There are two tiers.

• Priority (1x). Available in both sync and async mode. Latency of seconds to minutes. Use it for live, user-facing applications and agent tool calls where someone is waiting on the result.
• Standard (0.5x, the default). Available in async mode only. Latency of minutes to hours, by webhook or polling. Use it for background pipelines and scheduled ingestion. The same job costs roughly half what it does at Priority.

Sync and async are two processing modes that differ only in how you collect the API result. A sync call always bills at the priority rate. Submit your documents as an async job to be billed at the 0.5x standard rate.

For more on selecting the optimal service tier, see the article Understanding ADE Service Tiers or read the Service Tier documentation.

For more on processing modes, see the article Understanding Sync and Async Modes or read the Sync vs Async Processing documentation.

2. Model: the Parse model you run

The Parse model you select has a direct impact on price. The DPT-3 model family offers two models. The optimal choice depends on the job to be done. This article focuses solely on the price difference between the two models.

• DPT-3 Pro is the default, highest-quality model. It is the one to reach for on harder pages, the kind with handwriting, figures, charts, or diagrams, or pages that were scanned poorly.
• DPT-3 Verity is the lower-latency model built for digitally created text. It is the cheaper path for pages that hold clean, machine-readable content: digital text and tables.

Both models are billed the same way. Each page costs the per-page rate plus the output-character rate, and a document's total is the sum across its pages. Only the rates differ.

DPT-3 Pro

DPT-3 Verity

A few key things to draw attention to:

• Standard is half of Priority on every line, as discussed above.
• Verity's page rate is under a third of Pro's, and its character rate is under half.
• The two factors (tier + model) compound, so the same page parsed with Verity on Standard costs a fraction of what it costs with Pro on Priority.

A typical business document parsed with DPT-3 Pro uses a median of 1.5 credits on the Standard tier. For the full rate reference, see the Credit Consumption documentation.

3. Characters: the content processed

The third factor is the number of characters a job reads in and returns. Characters mean the visible content only. Bounding-box coordinates, confidence scores, other structural elements, and metadata are not counted. You pay only for the content on the page. A sparse page returns few characters and costs little; a dense page returns many characters and costs more.

You have control over the content returned by the Parse models via the parameters pages and options.

The pages parameter allows you to skip pages that you do not want included in the response.

The options parameter allows you to configure which block types are included in the response. Use boolean values to toggle each block type on and off.

If you know in advance that certain output is not required for your downstream tasks, omit it from the parse response to reduce the number of characters returned and thereby reduce your price.

Learn more in the article How to Configure Parse Output or by consulting the Parse Input Parameters documentation.

Credit usage is transparent and easy to access

You never have to guess what a job cost. Every API response includes a billing object reporting exactly what that call consumed in credits and which service tier it was charged at. The Playground mirrors the same figures in its downloadable Usage table. Line-by-line reporting that is easy to inspect and reconcile is central to how we designed Agentic Document Extraction. Pricing transparency makes credit forecasting easy.

Here is the metadata block from a real Parse v2 API response, for a one-page invoice run synchronously on DPT-3 Pro:

"metadata": {
  "job_id": "parse-01m1aj48q4av5tkpkaxbkvynx6",
  "model_version": "dpt-3-pro-20260710",
  "page_count": 1,
  "output_markdown_chars": 1779,
  "range_units": "unicode_codepoints",
  "failed_pages": [],
  "duration_ms": 7236,
  "billing": {
    "service_tier": "priority",
    "total_credits": 1.9
  }
}

The billing object is the headline: total_credits (1.9) is what the job cost, and service_tier records the rate it was charged at. This was a synchronous call, so it billed at priority.

The two fields above it are what produced that number. page_count (1) drives the per-page charge and output_markdown_chars (1779) drives the content charge.

Same document, 79% lower credit usage on Standard with Verity

Now run the same one-page invoice again, changing both factors at once: DPT-3 Verity instead of Pro, and the Standard tier instead of Priority. Because Standard is async-only, this goes through Parse Jobs rather than a synchronous call. Here is the metadata block that came back:

"metadata": {
  "job_id": "parse-01m1agnyc3mb989w4p11p9a2q3",
  "model_version": "dpt-3-verity-20260804-preview",
  "page_count": 1,
  "output_markdown_chars": 1717,
  "range_units": "unicode_codepoints",
  "failed_pages": [],
  "duration_ms": 8136,
  "billing": {
    "service_tier": "standard",
    "total_credits": 0.4
  }
}

In an apples-to-apples comparison of the same document, using Verity at Standard required 0.4 credits versus 1.9 credits for the same work on Pro at Priority.

This is an example of the service tier and model choice levers compounding. The tier alone would have roughly halved the bill; the model alone would have cut it to roughly a third. Together they take the same page from 1.9 credits to 0.4 - a 79% reduction.

Playground runs on Priority

It is important to note that the Playground always runs on the Priority service tier. If your use case does not require Priority Tier, you should use Standard to save credits.

To estimate credit usage for the lower Standard tier, you will need a side calculation or a direct API call. You can compute it from the per-service formula or run the document through the API on Standard tier to read the exact total_credits from the response.

Questions about ADE pricing

If you have questions about pricing, a specific formula, or how to understand your bill, email support@landing.ai.

Pricing resources mentioned in this post

• Purchase Credits
• Article: Understanding ADE Service Tiers
• Article: Understanding sync and async API for Parse and Extract
• Article: How to Configure Parse Output
• Documentation: Credit Consumption
• Documentation: Sync vs Async Processing
• Documentation: Parse Input Parameters
• Documentation: Parsing Models