Agentic Document Extraction Pricing Core Concepts

Pricing Overview

Agentic Document Extraction (ADE) pricing is designed for cost optimization from the start, so you don't have to build those optimizations yourself. Measured per thousand pages, ADE Gen2 pricing sits at or below common industry benchmarks, and teams migrating from ADE Gen1 on typical mixed workflows should see 25% to 40% lower per-page costs, with more savings coming across Summer 2026.

This guide covers how credits work, how to buy them, and the three factors — service tier, model, and characters — that determine how many credits a job consumes. By the end you should understand the core principles behind ADE pricing, understand the extensive optimizations that LandingAI has designed-in, and know what actions you can take to influence pricing.

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, live at 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 sets how fast the result comes back, and it is the factor with the largest and most direct effect on price. The same work, run at a different speed, costs a different amount. There are three tiers.

• Priority (1x, fully available). Latency of seconds to minutes, run synchronously or on a priority queue. Use it for live, user-facing applications and agent tool calls where someone is waiting on the result.
• Standard (0.5x, fully available, the default). Latency of minutes to hours, run asynchronously by webhook or polling. Use it for background pipelines and scheduled ingestion. The same job costs roughly half what it does at Priority.
• Batch (0.375x, coming soon). Latency of hours to days, submitted as an async job. It is designed for large-scale initial ingestion where throughput matters more than turnaround. Coming Summer 2026.

One mechanic follows from this: synchronous calls run at the Priority rate, because there is no Standard tier for a synchronous API. Sync is convenient for quick tests and real-time use, and the Standard async tier is the economical default for production volume.

2. Model: the Parse model you run

The second factor is the Parse model variant. (DPT-3 is the Parse model inside ADE Gen2.)

• DPT-3 Pro is the model available today. It uses complexity-based pricing, charging a base page rate plus a content charge for the characters it returns.
• DPT-3 Fast is a lower-cost model built for simpler pages. It is not available today, but is coming in the first half of July 2026.

Which model fits a page depends on how hard its content is to read. When DPT-3 Fast arrives, it will be the cheaper path for pages that hold clean, machine-readable content: digital text and tables. DPT-3 Pro, the model available today, is the one to reach for on harder pages, the kind with handwriting, figures, charts, or diagrams, or pages that were scanned poorly. Those pages need the Pro model to read them accurately.

The short version: simpler pages will run on Fast at lower cost, and difficult pages run on Pro.

The intelligent router (coming soon)

This is the cost optimization we designed in. The intelligent router is a fast-follower, coming in Summer 2026, and it is the piece that makes the model choice automatic. Instead of selecting a model for every page, you let the router send each piece of work - at the block level - down the least expensive capable path.

It works in layers. You select the processing mode (sync or async) for the job. Then, each page is sent to the DPT-3 model for layout detection. The output from layout detection is a list of blocks on the page with each block's location. The intelligent router then selects between DPT-3 Pro and DPT-3 Fast at the block-level. Blocks that contain digital text and tables are routed to Fast. More complex blocks are routed to Pro.

The result for customers is that every piece of block-level content is handled at the lowest sufficient cost without customers doing any sorting of pages or creation of cost-optimization infrastructure. All of this detection, separation and routing is handled automatically. As the user, you get back one consolidated response per document.

Under the hood your document has been on quite an elaborate journey!

When Fast arrives alongside intelligent routing, customers may see cost reductions as great as 80% (compared to ADE Gen1), especially on simple, non-urgent documents.

3. Characters: the content processed

The third factor is the number of characters a job reads in and returns. Characters mean the visible content: the Markdown text, tables, and fields that ADE actually produces. Bounding-box coordinates and other structural metadata are not counted, so you pay only for the content on the page.

This is what makes the pricing fair for a mixed workload. A sparse page returns few characters and costs little; a dense page returns many characters and costs more.

Credit usage is transparent and easy to access

You never have to guess what a job cost. Every API response includes a credit_usage field reporting exactly what that call consumed, and the Playground mirrors the same figures in its Usage table. This reconcilable, line-by-line reporting is central to how ADE's credit-based pricing stays transparent and easy to forecast.

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-api-e8071bbc9cd1",
  "filename": "invoice_1.pdf",
  "version": "dpt-3-pro-20260515",
  "page_count": 1,
  "failed_pages": [],
  "duration_ms": 16764,
  "markdown_chars": 1754,
  "credit_usage": 1.9,
  "credit_breakdown": {
    "total_credits": 1.9,
    "billable_pages": 1,
    "line_items": [
      {
        "type": "parse",
        "model": "dpt-3-pro",
        "processing_mode": "sync",
        "credits": 1.9
      }
    ]
  }
}

Read from the top, credit_usage (1.9) is the headline charge for the job, and credit_breakdown shows how that number was reached. Inside it, line_items gives the per-operation detail: a single parse line, run on model dpt-3-pro in sync processing_mode, costing 1.9 credits. The billable_pages (1) and total_credits (1.9) fields summarize the job. The failed_pages array is empty, which is what you want to see. The markdown_chars field (1754) reports the volume of visible content returned, and that character count is what drives the content portion of the charge. The version field records the exact model build (dpt-3-pro-20260515), and duration_ms the processing time.

You can check the 1.9 yourself. Because this was a synchronous call, it ran at the Priority (1x) rate for DPT-3 Pro: 1 credit for the page, plus 0.5 credits per 1,000 output characters. With 1,754 output characters, the content charge is about 0.9 credits, so the 1-credit page charge plus the roughly 0.9-credit content charge comes to about 1.9 credits, matching credit_usage.

Same document, lower credit usage on Standard

Run the same one-page invoice on the Standard tier and the cost drops. Standard is the asynchronous default and runs at the 0.5x rate for DPT-3 Pro: 0.5 credits per page plus 0.25 credits per 1,000 output characters. The same 1,754 output characters now produce a content charge of about 0.44 credits, so 0.5 for the page plus roughly 0.44 for the content comes to about 0.9 credits. In the response, the same job on Standard would report a credit_usage of about 0.9, and the line_items entry would show processing_mode as async while the model stays dpt-3-pro. It is the same work at a different speed, and Standard costs roughly half the 1.9-credit Priority figure, which is why Standard is the economical default for production and why the service tier is the main lever on what you pay.

One practical note follows from the Playground being fixed to Priority: to estimate credit usage for a lower tier like Standard or Batch, you need a side calculation or a direct API run. Either compute it from the per-service formula or run the document through the API on that tier and read the exact credit_usage 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.

The single most useful thing to remember is that the service tier is the lever you control most directly. Reach for Priority when a person or an agent is waiting. Run on Standard (the default) for background and production pipelines, and pay roughly half. Plan for Batch (coming soon) when you are ingesting at scale and can trade turnaround for the lowest rate. The price tracks the content on the page and the speed you ask for, and both are reported in every response, so the whole document mix becomes economical to automate and straightforward to forecast.