PDF table extraction can fail without an error: a scan through the free parser returns zero rows, and long tables truncate at the token limit. Rejecting empty results and finish_reason length catches both.
Key takeaways · AI-distilled
In OpenRouter's tests on five generated PDFs, two of them scans, every model that read the PDF directly got all 644 cells right. Every failure came from the parser route the file took to reach the model, not from the model's reading.
OpenRouter handled a category cell merged down six to nine rows purely through the schema's field description, telling the model to repeat the value on every row it covers. All three PDF-reading models then filled the category on all 30 rows of a rough scan.
OpenRouter's 58-row shipment log used 2,500 to 7,700 output tokenThe chunk of text a model reads and writes in — roughly three-quarters of a word — and the unit AI usage is billed in.Full definition → depending on the model, 43 to 133 per row, so it suggests budgeting about 150 tokens per expected row. With Response Healing on, a cut-off output parsed cleanly but held only 5 of 58 rows, with no error.
On OpenRouter's test pages, GPT-6 Luna cost about $0.77 per 1,000 pages and Claude Haiku 5.5 about $1.00, both with every cell right. Gemini 3.8 Flash matched accuracy at 8 to 10 times the cost; the mistral-ocr route adds $2 per 1,000 pages and kept footnote markers.
In OpenRouter's tests, pdfplumber found every table in the digital PDFs but returned cells as strings like '(3,878)', split a two-level header into two rows with None, broke a two-page table in two, and found nothing in scans, so it suits only simple digital tables.
Terms in this piece · Glossary
token — The chunk of text a model reads and writes in — roughly three-quarters of a word — and the unit AI usage is billed in.
