Hey everyone, I've been running into a bit of a snag with ChatPDF's API this week and I'm wondering if I'm alone in this.
I set up a workflow to process a batch of weekly campaign performance PDFs—think about 50-60 medium-length reports. Based on the pricing page, I estimated my usage would be well within my plan's quota. But my quota was depleted in just two days! 😳
I'm trying to troubleshoot my own process first. Here's my typical flow:
* I'm using the `POST /chats` endpoint to start a session for each PDF.
* Then I send a series of specific questions via `POST /chats/{chatId}/message` to extract structured data (e.g., "What was the spend for Campaign X?", "List the top 3 channels by CTR").
* I'm not uploading the same file repeatedly; each session is new per PDF.
Has anyone else experienced this? I'm starting to wonder:
* Does each question sent to an existing chat session count significantly toward the token/quota usage, even after the initial upload?
* Could there be a difference in how "pages" are counted versus how the API actually processes tokens/characters?
I love the tool for parsing data, but I need to forecast my costs accurately for my MarOps budget. Any insights from your own workflows would be super helpful!
Oh, that's interesting about sending multiple questions per chat. I hadn't considered that part.
I was wondering, are your PDFs very text-heavy? I ask because I saw a note somewhere about the quota possibly counting characters processed, not just the number of files. So maybe each question re-processes a big chunk of the text behind the scenes?
I'm also trying to budget for a similar project, so I'm a bit nervous now! Let me know if you find out more.
Yeah, that multi-question per chat approach is probably the culprit. Each message likely triggers the model to re-analyze the document context, using tokens each time.
You mentioned forecasting for your MarOps budget - you might need to architect around this. Could you extract *all* the data you need in one, super-detailed prompt per PDF instead of multiple back-and-forth questions? Something like "Extract the spend, CTR, and top channels for every campaign listed." It's less conversational but might keep your token burn way down.
Also, check if their quota counts "pages processed" or "tokens used". If it's pages, each question might be re-processing the entire doc. That'd kill your quota fast.
pipeline all the things
The note about counting characters is key, but it's probably even worse. Their pricing page is intentionally vague.
It's likely a composite of:
* Pages extracted
* Characters in those pages
* Tokens sent for every question
If each question in a chat re-sends the whole document context, your quota evaporates. You can't budget on vague "units." Demand a specific formula from their sales team before committing.
Caveat emptor.
Your multi-question workflow is exactly where the quota gets eaten up. Even though you're in the same chat, each `POST /chats/{chatId}/message` call is likely feeding the entire document context back into the model to answer. You're paying for the PDF processing multiple times per file.
I've seen this with other doc-analysis APIs. The initial `POST /chats` might cost one "unit," but every follow-up question costs another, sometimes nearly the same amount.
Have you checked the response headers? Some APIs include usage stats like `X-Tokens-Used`. That could confirm it. If not, try a quick test: run one PDF with your multi-question method, and another where you pack everything into a single, detailed prompt. Compare the quota impact.
Prompt engineering is the new debugging.
You're right about the re-processing, but the real kicker is that these vendors rarely expose token usage in a way that makes attribution possible. I've been burned by this exact pattern with a few "AI document analysis" tools. The `X-Tokens-Used` header is a unicorn. Most of them bury it in a webhook callback or a separate usage report that's always delayed by 24 hours. By then you've already blown through your quota and the budget's shot.
One thing to add: even if you consolidate into one prompt, some APIs charge a per-query "context window" fee that scales with file size, not just the number of tokens in your prompt. So that single super-detailed prompt might still burn the same effective quota as five smaller questions because the backend re-indexes the whole doc each time anyway. The only way to know is to test with a minimal file and watch the quota counter tick. Have you actually measured the delta between one question vs five on a single PDF yet, or are we still guessing?
Attribution is a lie, but we need the lie.
That point about delayed usage reports hits home. Even if they provide a 24-hour dashboard, it's useless for real-time budget control. You're flying blind.
Your mention of the "context window fee" is the real black box. We can speculate about tokens, but if the fee structure truly bills per full-document context per call, then consolidating prompts won't help at all. The cost model becomes purely "number of API calls times document size," which is a nightmare to forecast.
Have you ever successfully reverse-engineered one of these opaque pricing models by correlating call volume with the delayed reports? I've tried, but the lack of immediate feedback makes causal analysis nearly impossible.
Every dollar counts.
The delayed reports are worthless for this. You need real time metering. I had to wrap the entire client call in a logging proxy that checked my own usage estimate before proceeding. If I suspected a call would blow the budget, I'd fail fast.
Even then, you're right, it's guesswork without the actual pricing formula. I treat any API that bills per "unit" as a cost black box and run small scale load tests against a fresh paid account before committing. It's the only way.
Your question about reverse engineering: yes, but it required months of data. The correlation was there, but the variance made it useless for actual predictions.
That "units" line on pricing pages is the biggest red flag. Even if you get a formula from sales, it's often a non-binding estimate. The real cost gets calculated in their system, which can change without notice.
Has anyone actually gotten a formal, written cost-per-call formula from a vendor's sales team? I've only ever gotten vague slides.