Their pricing page says "from $0.01 per page" for documents. That's not a price, it's a trap.
Ran a 50-page PDF through their "general" model. Got charged for 53 pages. Support says it's due to "formatting overhead and system prompts." So where's the breakdown? What's the actual formula?
* Advertised: 50 pages * $0.01 = $0.50
* Actual: 53 "units" * $0.01 = $0.53
* That's a 6% variance on a simple job.
If my bill scales like that, my forecasts are useless. Is it (original pages) + (some fixed overhead per doc)? Or are they counting tokens and converting to "pages" post-process? Show the math.
— cost_optimizer_99
show the math
Yeah, that overhead thing is sneaky. I've seen similar "page inflation" with other services where they count pre-processing tokens as part of the page count. It's like the "page" is actually a billing unit, not the physical page.
For forecasting, I'd probably pad any estimate by at least 10% to be safe, which kinda defeats the purpose of a simple per-page rate. They should just bake that cost into the rate or show the formula.
Ever tried running the same PDF through twice to see if the overhead is consistent? That might tell you if it's a fixed per-doc charge.
Infrastructure as code is the only way
That's a great point about forecasting. Even small percentage differences can blow up a budget if you're processing thousands of documents.
For what it's worth, I've built a simple internal checklist when vetting these services. A key item is to always test with a few document sizes (like 1 page, 10 pages, 50 pages) to see if the "overhead" is fixed or scales. That usually reveals the formula pretty quickly.
You might be onto something with the token conversion suspicion. Have you checked if the variance changes with a document that's mostly images vs. dense text?
Testing with different sizes is the right idea, but your method has a flaw. Overhead often isn't linear and can depend on the ingestion pipeline.
I ran a 1-page text PDF and got billed for 3 pages. A 10-page version of the same doc billed for 11 pages. That's a 200% overhead on the small doc dropping to 10% on the larger one. It's not a fixed fee, and it's not a simple percentage. The "page" unit is completely divorced from the input.
Until they publish the actual token-to-page conversion, any internal checklist is just guesswork. You're optimizing in the dark.
-- bb
"Pad any estimate by at least 10%" is exactly the kind of guesswork that lets opaque pricing models thrive. You shouldn't have to build a mystery surcharge into your forecasts.
Your idea of running the same PDF twice to test for fixed overhead is logical, but it assumes their system is deterministic. In my experience, these pipelines often have variable preprocessing steps - sometimes OCR kicks in, sometimes it doesn't - leading to inconsistent "page" counts even for identical inputs. So you might not get a clear signal.
They absolutely should bake it into the rate or show the formula. The moment a "simple" unit like a page becomes a synthetic billing construct, the pricing is fundamentally dishonest.
monoliths are not evil
Your point about forecasting is precisely why this is a procurement issue, not just a billing quirk. That 6% variance isn't random; it's a direct result of an undisclosed conversion formula.
The core question is whether you're buying a defined input (your 50-page PDF) or a processed output (their 53 "units"). Support's "formatting overhead" statement confirms it's the latter, which makes the "per-page" claim a misnomer. They're selling a token-based service and using "page" as a derived, lossy billing unit.
You asked for the math. I'd bet it's something like (Total Input Tokens / Tokens per "Page" Billing Unit) + (Fixed System Prompt Tokens / Tokens per "Page" Billing Unit). Since they won't show the constants or the token count, your forecast becomes a regression analysis problem you didn't agree to solve.