[Regression] LlamaParse API fails to extract clearly visible text from PDF

[dani1996dani]

Describe the bug
LlamaParse failed to extract a clearly visible monetary value from a PDF that it had previously parsed successfully.
The value TOTAL FOR BUILDING: $1,729,000.00 is clearly displayed in the document but is missing from the parsed output. This appears to be PDF-specific - other proposals are parsing correctly (thus far).
Started experiencing this bug from May 21st, 2026. It worked well for this PDF in the past.

Files

Eagle.pdf

Job ID
Could not find the Job ID specifically, couldnt find a time field in the llamaparse UI - we have a lot of jobs that ran on May 21st.

Client:
Please remove untested options:

• API

Additional context
Add any additional context about the problem here.
What options did you use?
We are using the Agentic tier, using the API.
This was working correctly until today and broke without any changes on our end.
The issue is isolated to this specific PDF - other proposals continue to parse as expected.
Please advise whether this is a known regression or a model/pipeline change on LlamaParse's end, as this field is business-critical for our use case.

The output it gave me for that PDF file:

eagle_llamaparse_output.md

Langfuse screenshot:

Same section - in the PDF:

[logan-markewich]

What options are you parsing with?

[dani1996dani]

We're using the @llamaindex/llama-cloud Node.js SDK with the following options passed to client.parsing.parse():

   "tier": "agentic",                                                                                                                                                                                                             
   "version": "latest",                                                                                                                                                                                                         
   "input_options": {},
   "output_options": {
     "markdown": {
       "tables": {                                                                                                                                                                                                                
         "output_tables_as_markdown": true
       }                                                                                                                                                                                                                          
     }                                                                                                                                                                                                                          
   },
   "processing_options": {
     "ocr_parameters": {
       "languages": ["en"]
     }
   },                                                                                                                                                                                                                             
   "expand": ["markdown_full"]
 }        

We retrieve the result via result.markdown_full. No other options are set - input_options is an empty object. The file is uploaded with purpose: 'parse' before the parse job is triggered.

Let me know if you need more info, happy to provide it.

[dani1996dani]

We ran the same file multiple times today - it failed to extract the same row multiple times today.

[Free-tek]

This is the silent-failure pattern that bit us too. The frustrating part isn't the miss, it's that the parser returns confidently with the row gone, so anything downstream that depends on the total breaks without warning.

Two things that helped us avoid it in production:

1. Route image-heavy or table-dense pages through GPT-5 with vision in parallel and compare. LlamaParse misses on tables that GPT picks up, and vice versa, so a disagreement is a strong signal you need a human.
2. For high-stakes documents (financial totals, contracts, specs), insert a human verification step on the cases the model flags as low confidence, or on document types you know will fail. We built AwaitVerify for that part (https://awaithumans.dev/awaitverify). You bring whichever parser, we handle the human verification and the typed callback into your pipeline.

Happy to share a sample of how the dual-extractor + human-verify flow looks if useful.