I've been evaluating Cartesia's API for a potential document processing pipeline and have hit a consistent point of friction: the per-page pricing model. While the concept is straightforward for simple PDFs, it breaks down in practical, complex scenarios, leading to unpredictable cost forecasting.
My primary issue is the definition of a "page." From my testing, it appears to be a rasterized image unit for processing. This causes two main problems:
* **Document Discrepancy:** A 100-page PowerPoint presentation with sparse text is charged the same as a dense 100-page legal contract. The computational resource consumption (and presumably Cartesia's cost) is vastly different, but the billing isn't.
* **Pre-processing Ambiguity:** If I need to pre-process documents (e.g., split a large PDF, extract images from a slide deck for separate analysis), I effectively multiply the page count. A 50-page PDF with 10 embedded images could become 60 "pages" if processed separately, making cost estimation a moving target.
This model feels analogous to buying compute by the VM *instance hour* regardless of CPU utilization. In cloud cost optimization, we moved to granular metrics (vCPU-hour, memory-GB-hour) for fairness. A similar approach here might be more aligned with value, such as:
* A base per-document unit for initialization.
* A tiered per-page cost based on processing complexity (text density, presence of tables/figures).
* Separate, clear pricing for optional add-ons like high-accuracy OCR or table extraction.
Without this, building an accurate unit cost model for my application is difficult. I am forced to over-provision my budget for worst-case scenarios, which contradicts efficient FinOps practice. Has anyone else built a cost model around this? How do you account for the variability in your projections?
Less spend, more headroom.
Totally feel you on this. That "per-page" abstraction is convenient for marketing but gets messy fast in real workflows.
Your VM comparison is spot on. It makes me wonder if they could offer a hybrid model, like a base per-page fee plus a small compute credit multiplier for dense pages. That way simple docs stay cheap but you're not penalized for complexity.
The pre-processing multiplier is my biggest headache too. I once built a pipeline where splitting a report for parallel processing accidentally tripled the page count. Makes you scared to optimize your own workflow! Have you found any workarounds in your testing, like trying to batch those image extracts differently?
Yeah, the cloud compute analogy is really fitting. It underscores a bigger tension in API pricing, I think, between predictability for the customer and fairness for the provider.
You've nailed the core dilemma: they need a simple, countable unit for billing, but "page" as a rasterized image is so variable in actual resource cost. It makes me wonder if the underlying issue is that they're offering one price for a service that, under the hood, might have several distinct cost drivers like OCR intensity, image processing, or layout analysis. Bundling it all into one per-page fee creates exactly this mismatch.
The pre-processing multiplier is a huge practical pain point. It almost feels like the pricing model inadvertently punishes you for building a more sophisticated, optimized pipeline, which is backwards. Have you looked at whether their batch API endpoints handle any of that splitting logic differently, or does it still just boil down to total pages submitted?
Let's keep it real.