LlamaExtract Max Effort: Pay for Fewer Critical Omissions, Not a Bigger Score

LlamaIndex introduced Max effort for Extract's Agentic Plus tier on October 29. It offers more computation for demanding documents, with variable billing. The announcement reports Value F1 rising from 77.7 to 94.3 on its own ExtractBench Pro benchmark. That is a reason to investigate a new option, not evidence that your invoice, onboarding, or document-review app has become safe to automate.

For a small product team, the useful question is narrower: which missing or incorrect fields are expensive enough to justify a different processing path? A missing internal label and a missing delivery exception can look equally small in a JSON response while causing very different customer problems.

This guide is for founders and AI app builders choosing how a document feature should behave. It provides a critical-field worksheet, a paired trial, and a routing decision that includes human review and customer waiting time. The launch and its figures come from LlamaIndex's announcement; the adoption method below is our recommendation. We have reviewed documentation and the published benchmark materials, not run a paid extraction trial or measured customer outcomes.

1. The new option changes a product promise, not just a setting

Document extraction turns source material into named fields: a supplier name, a delivery date, a list of items, or a condition attached to an order. A schema is the definition of those fields and their intended meanings. Parsing is the earlier step that interprets a document's text and layout. Neither a readable parse nor schema-shaped output establishes that the information is complete.

Max effort creates a practical opportunity to spend more processing on difficult inputs. The temptation is to add a premium toggle to every upload. That is premature because the product promise often remains undefined. Is the app preparing a draft for someone to inspect, identifying exceptions, or creating a record that another system immediately acts on? Those are different jobs even when they share the same extraction provider.

Start with a sentence describing the decision downstream: “The purchasing coordinator can compare a supplier's confirmed delivery conditions against the requested order.” This is more useful than “Extract everything from PDFs.” It identifies whose work improves and which mistakes matter. A perfectly extracted company address does little for that promise if a late-delivery condition disappears.

Also decide what the app can honestly say when work finishes. “Processing completed” can mean the service returned a result. “Ready to approve” implies a stronger assessment about completeness and exceptions. Your interface should not silently convert the former into the latter. The founder owns this distinction even if a builder generates the integration.

Our recommendation is to treat Max effort as a candidate for a defined document workflow. The proposed purchase is a better chance of recovering important evidence, with costs and delays attached. It is not a purchase of permission to remove review. If the team cannot name a consequential omission, first improve the workflow definition rather than expanding compute.

2. Read the benchmark as a map of hard cases

ExtractBench Pro is useful because the published dataset card makes its scope inspectable: 100 synthetic documents across six challenge groups, with schemas and expected outputs. The cases include document-specific conventions, diagrams, charts, and counting rules. Fictional values fixed before rendering support exact answers; they do not make the workload representative of every customer's documents.

Value F1 combines finding expected values with avoiding incorrect extra values. It is distinct from the share of whole documents that are perfect. A high aggregate result cannot tell you how often every action-critical field in one upload is simultaneously correct. Nor does it establish whether an absent field means “not present in the source” or “missed by the extractor.”

Use the benchmark to ask better questions about your inputs. Do users submit clear digital order forms, sideways scans, unfamiliar abbreviations, or information distributed between a table and a footnote? Is a quantity visible as text, implied by a drawing, or dependent on a rule elsewhere? These distinctions help define trial groups without pretending that a benchmark average predicts production accuracy.

A particularly important comparison is between the errors the benchmark counts and the errors your customers notice. If a tool captures dozens of descriptive fields but omits one condition that reverses the user's decision, a field average can improve while the product still fails its central task. Record that condition separately rather than inventing a universal score that hides its importance.

The benchmark belongs to the vendor publishing the feature. Public materials make scrutiny easier, but this article does not claim independent replication, a provider ranking, or expected accuracy for Chinese documents. A bilingual product should include its actual languages and mixed-language layouts in its own trial. Translation of a schema is not proof that document conventions transfer.

3. Build a critical-field worksheet before buying more compute

Use a compact worksheet to connect each extracted field to a consequence. A critical field is one whose omission or wrong interpretation could materially change the next action. Criticality comes from the workflow, not from the field being a number, a required property, or visually prominent.

The following is a reusable planning artifact. The example entries describe a fictional supplier-confirmation assistant, not a customer deployment or measured experiment. Replace them with your own document types, owners, and acceptance rules before testing.

Write a separate entry when two fields have different consequences. A delivery date and an internal reference code may use identical data types, but they should not automatically share an acceptance rule. Conversely, a field that looks optional in a form may be essential to the customer's decision when it appears.

Keep the artifact short enough to use during a real review. A document category with no defined owner or absence rule is not ready for automatic acceptance. More processing might help recover a value, but it cannot decide what your business should do when the source never supplied it. That missing policy is a product requirement to resolve first.

4. Compare the same documents without changing the question

Run a paired trial: each selected document goes through the baseline and the candidate path, using the same schema, relevant options, and supported version. The configuration guide identifies Max effort as an Agentic Plus option and supports holding the version constant. Capture the resolved configuration instead of relying on a screenshot of a playground toggle.

Have a knowledgeable person establish expected critical values from the source before examining model outputs. Where the source is ambiguous, mark the ambiguity rather than forcing an answer. Include ordinary uploads, known hard cases, genuine missing values, revised documents, and cases with multiple plausible dates or totals. Label deliberately constructed examples so they are not confused with the distribution of real work.

Separate development examples from a reserved check set. Use the development group to clarify descriptions and rules. Once those are settled, freeze them before evaluating the reserved group. If you change the schema after seeing a failure, rerun both paths under the new schema and report the change. Otherwise a schema improvement can be mistaken for an effort improvement.

For every document, compare critical omissions, incorrect critical values, unsupported additions, reviewer corrections, elapsed time, and billed usage. Preserve failures and unfinished jobs in the denominator. A path that returns excellent answers on a selective subset may still leave customers waiting on the hardest uploads.

Do not choose the candidate merely because it repairs the most memorable failure. Look for regressions on routine work and cases where it supplies a convincing but unsupported answer. Record reviewer disagreement and adjudicate it against the source. If the expected answer changes, retain that history so a revised label does not quietly inflate the result.

A small trial is an adoption aid, not a statistical guarantee. State the document families, languages, sample-selection method, and exclusions alongside the outcome. If the cases are too few or too curated to justify automatic routing, the valid result is a limited assisted workflow or a larger trial, not a fabricated production-success claim.

5. A supplier-confirmation scenario exposes the real tradeoff

Imagine a three-person team building an assistant for purchasing coordinators. A user uploads a supplier confirmation. The first page repeats the requested arrival date. A later amendment says one item will arrive later unless the buyer accepts a substitute. The intended output is a comparison draft with exceptions highlighted; it does not authorize purchases or contact suppliers.

A baseline extraction could return the earlier date and a complete-looking item list while missing the amendment. A candidate run could find the amendment but attach its condition to the wrong item. These are hypothetical failure modes to test, not observed LlamaExtract behavior. They show why “more fields returned” is an insufficient acceptance criterion.

The reviewer needs to answer three connected questions: which item does the condition affect, which date is current, and what choice remains for the buyer? A single source snippet may not resolve all three. The product should let the reviewer inspect the amendment in context and preserve an unresolved state when the relationship remains unclear.

Now consider a clean confirmation with one unambiguous date. If the current process already produces a correct draft quickly, the additional path might add delay without changing the decision. That upload is a useful control, not an uninteresting case to remove. A product that optimizes only for dramatic exceptions can make ordinary users pay for complexity they do not have.

Finally, include a confirmation that never states a delivery date. The correct behavior is to ask for clarification or leave the value unresolved. If the app substitutes a requested date from another record without disclosure, it has crossed from extraction into inference. That may be a separate useful feature, but it needs a different label and approval rule.

This scenario leads to an actionable scope: investigate whether Max effort improves amendment-sensitive comparison drafts enough to justify its cost. It does not support the broader promise that the app can autonomously accept every supplier confirmation. The distinction should appear in the builder brief, result screen, and rollout decision.

6. Measure cost per usable decision, including the expensive tail

The relevant cost is larger than the extraction line item. It includes parsing where applicable, retries, review time, and the work created by an error. The pricing documentation describes Max effort as usage-based with an Agentic Plus page-charge minimum; parsing charges are separate. A minimum is a floor, not a maximum or a fixed quote.

For a trial, use a simple ledger: total processing charges plus reviewer time valued at an explicitly chosen internal rate, divided by the number of decision-ready drafts. A decision-ready draft meets your critical-field rules, including an honest unresolved state when it supports an agreed next step, such as requesting clarification. A draft merely parked in an unresolved queue does not count. Keep time cost and cash charges visible separately so an assumed labor rate does not masquerade as money actually saved.

Also report the slowest and most expensive cases you observed, their document types, and whether they produced usable results. An average alone cannot tell a founder whether one unusual upload consumes the allowance intended for several ordinary customers. Set trial spending limits before submission and agree on what happens when the observed workload exceeds them.

Read actual usage records rather than treating a result payload as a receipt. The response-format documentation distinguishes extracted data from expanded configuration, metadata, and usage. Billing values can arrive after completion; pending usage should remain unknown rather than being entered as zero. Shared parsing must not be counted twice when totaling a comparison.

Avoid estimating the financial value of avoided errors unless you have defensible inputs. A possible missed delivery is a reason to investigate, not a license to multiply invented failure rates by invented damages. You can still make a decision with observed review effort, real charges, documented critical errors, and a clearly stated uncertainty about downstream losses.

Choose a broader rollout only when the workload-specific benefit survives this accounting. If the benefit appears only in a narrow group, keep the adoption narrow. If a schema clarification fixes the issue cheaply, preserve that improvement without crediting it to additional computation.

7. Design review around evidence, not confidence theater

A confidence score estimates certainty about a returned field. It cannot, by itself, prove that all relevant fields were discovered. A missing amendment may never create a low-scoring field for your routing rule to catch. This is why “send low confidence to Max effort” can be a useful candidate policy but is not an exhaustive omission detector.

The metadata guide distinguishes citations from confidence and warns that high confidence is not a guarantee. Test the accepted outputs as well as the review queue. A policy can appear efficient because it sends few documents to review while quietly allowing important mistakes through.

For the supplier example, show the extracted value, the relevant source location, and the unresolved condition together. Let reviewers correct a relationship, not only edit a date cell. Keep the original output and the correction so the team can later identify recurring failure families. Do not replace source context with a green badge whose meaning the customer has never agreed to.

Routing can combine known document families, explicit business rules, incomplete critical fields, and uncertainty signals. Evaluate the complete routing policy against manually checked examples. If the policy depends on detecting a hard case, measure how often it misses those cases. A fallback that is never triggered for an invisible omission provides no protection against that omission.

Review capacity is part of the product design. Decide who handles unresolved uploads, whether the customer can continue other work, and how long an unresolved draft may remain visible. An impressive extractor paired with an abandoned exception queue is still an unreliable service.

For consequential decisions, keep a human responsible for acceptance until the workflow has sufficient evidence for a narrower automation claim. More computation and richer metadata can improve that person's evidence. Neither changes who is accountable for the next action or turns an estimate into a verified fact.

8. Waiting, retries, and retention belong in the adoption decision

A longer processing path changes the experience of an upload. Give users a durable job state and a way to return to it. The production-extraction cookbook covers asynchronous processing, polling, timeouts, and batch patterns. It is implementation guidance, not an end-to-end latency promise for your workload.

Specify what the customer sees when processing is queued, running, failed, cancelled, or completed but awaiting review. A browser timeout should not automatically be described as a failed extraction, and pressing the upload button again should not silently create a second billable attempt. Ask your builder to distinguish reconnecting to an existing job from submitting a new one.

The rate-limit documentation also separates request caps from limits on simultaneous work and describes different reasons for refusal. The product implication is straightforward: a generic “try again” message is a weak operating plan. Require bounded retries, recorded job identifiers, and an explicit handoff when work remains blocked. Verify the behavior of your actual integration rather than assuming a provider example settles it.

Document access needs equal care. The retention documentation distinguishes Parse source/cache retention from Files API objects retained until deletion or expiry. Do not promise that every uploaded document disappears after one universal interval. Decide which source files, results, and reviewer copies your app keeps, for what purpose, and under whose control.

Begin with synthetic or appropriately authorized documents. Before a real customer pilot, check the account and workflow's applicable data-handling terms and permissions. Extraction quality does not answer whether a team is allowed to upload a particular file. Nor does deleting a provider object necessarily remove copies in your own storage or support workflow.

These concerns are adoption criteria because they affect whether the improved draft is usable. A more accurate answer that arrives after the customer's decision, cannot be reviewed, or violates the app's stated handling promise is not a successful product outcome.

9. Choose a narrow rollout, a revised workflow, or a deliberate wait

Use the worksheet and paired trial to make one of four decisions. Adopt for a named document family when critical-field results improve, review remains workable, and observed spending and waiting fit the budget. Keep a manual acceptance step unless you have separately justified removing it.

Revise the workflow when the largest problems come from unclear field meanings, ambiguous source precedence, or a result screen that hides unresolved conditions. Fix these before paying for more processing. Repeat both trial paths after a material change so the comparison remains interpretable.

Wait when the current evidence cannot establish whether the candidate helps your actual documents, when costs remain unrecorded, or when the upload and retention path has not been agreed. Waiting can mean retaining the existing manual process while collecting authorized examples, rather than presenting a speculative capability to paying users.

Stop the proposed adoption when the consequential mistakes persist, the extra review cancels the benefit, or the document family cannot be recognized reliably enough for the proposed routing. Preserve useful schema and interface improvements even if the feature decision is no. The trial should improve understanding of the product, not create an obligation to ship the new setting.

Give your builder a concrete handoff: the user decision; the included and excluded documents; frozen schema and configuration; expected critical values; unresolved-state behavior; charge and time records; reviewer ownership; and the exact claim allowed on the result screen. Request evidence from the reserved check set before enabling a customer cohort.

LlamaIndex's release makes a new cost-quality tradeoff available for investigation. The founder's job is to decide where that tradeoff changes a customer's work. Start with the omission that matters, preserve the source needed to judge it, and pay for additional computation only when the complete workflow earns it.

References

• LlamaIndex: Extract V2.6, Max Effort, October 29
• ExtractBench Pro: published dataset and evaluation scope
• Configuring Extract
• Extraction pricing
• Extract response format and usage
• Metadata extensions
• Production extraction patterns
• Rate limits
• Data retention