Why a PDF summary is often not the end of the conversation
A structured summary is the fastest way to get the gist of a long PDF, but the moment you have specific follow-up questions — "what's the exact deadline in section 4," "does this contract mention a non-compete clause," "what was the sample size in the study" — a bullet-point summary is the wrong shape for the answer. You either re-read the whole document yourself, or you paste the relevant paragraph back into the bot as a new message and hope it has enough context to answer well. Chat-with-PDF closes that gap directly: once @vustSummaryBot has already summarized a PDF-document upload, a single button tap arms a short follow-up Q&A mode on the exact text it already extracted, so a specific question gets a specific, grounded answer instead of a second full summary.
This is deliberately scoped as a lightweight follow-up, not a full document-chat product. It rides on the same extracted text the summary was built from, it's capped at 3 questions per document, and it closes after 30 minutes — bounded enough to keep the cost of a 1✦ question honest, generous enough to actually answer the two or three things a bullet-point summary always leaves out.
How @vustSummaryBot's PDF pipeline actually wires this up
To be precise about the mechanics rather than hand-wavy about them: @vustSummaryBot's PDF-document upload path (packages/summary-telegram/src/pdf-extractor.ts) extracts the text layer from an uploaded PDF file and runs it through the normal summarization pipeline. When that specific path succeeds — the extraction status the handler checks internally is pdf_document, meaning a real PDF file was uploaded and read directly, not a link to a PDF fetched some other way — the delivered summary message gets one extra row appended to its keyboard: "💬 Ask about this PDF." No other source type (plain text, a URL, a YouTube link, a forwarded message) shows this button; it only appears on a PDF-document summary's own result screen, appended after the normal feedback/share, format-switcher, and retry/delete rows, so every other summary type's layout is completely unchanged.
Tapping the button "arms" a per-user flag stored in the same result_context mechanism the bot already uses for other short-lived state (the same table backing the "long YouTube video, pick a format" quote flow). The row is keyed to your Telegram user ID, holds the extracted document text (truncated to a hard cap if the original was very long), and tracks two things: whether you're currently armed for a question, and how many of your 3 allotted questions you've already used. Once armed, the very next plain-text message you send to the bot is treated as a question about that document — not as a new summarization request — right up until you hit the 3-question cap or the 30-minute window from the original summary's delivery closes.
The 30-minute window, explained honestly
The 30-minute clock starts at the moment the PDF summary was delivered, not at the moment you tap the button. If you summarize a PDF, get distracted, and come back 40 minutes later to tap "Ask about this PDF," you'll get an honest "Session expired — please resend the PDF" message rather than a stale or confusing partial state. This is a deliberate design choice: extending the window every time you tap the button would let a single document's extracted text sit around indefinitely, which isn't necessary for what is meant to be a quick, in-the-moment follow-up rather than a persistent document-chat session. If you need to ask questions about the same PDF again later, resending it and getting a fresh summary re-arms the whole flow with a new 30-minute window.
The 3-question cap, and why it's not just an arbitrary number
Each question costs 1✦ and calls the same underlying AI model @vustSummaryBot already uses for summarization, given the extracted document text plus your specific question. Three questions per document is a deliberate ceiling on the total AI cost a single PDF upload can generate through this feature — a summary is one paid or free action with a known, bounded cost; an open-ended chat session on the same document would have unbounded cost if left uncapped. After your 3rd answer, the next message you send gets a clear "you've used all 3 questions for this document — start a new summary to continue asking questions" reply, and critically, that 4th attempt is never charged: you only pay for a question that's actually answered, never for one that's rejected by the cap.
What the answers are actually grounded in
Every answer comes only from the text @vustSummaryBot already extracted from your PDF when it built the original summary — not from general world knowledge, not from search, and not from the summary text itself (which would compound any information loss from the summarization step). If your question asks about something the document doesn't cover — a page that was truncated out of a very long PDF, or simply a fact the document never states — the bot is instructed to say so honestly ("not found in this document") rather than guess or extrapolate. This grounded-only behavior matters most on documents where getting a wrong answer would actually cost you something: a contract's exact notice period, a study's precise sample size, a policy's specific coverage limit. A confident-sounding wrong answer on any of those is worse than a bot that says it doesn't know.
A worked example: from summary to three follow-up questions
Below is a realistic, condensed version of what the flow looks like end to end, using a hypothetical 22-page SaaS vendor contract PDF as the source document.
Summary excerpt (what @vustSummaryBot delivered first):
• This is a 12-month SaaS subscription agreement between the customer and the vendor, auto-renewing unless cancelled. • Payment terms: net-30 invoicing, quarterly billing cycle, 1.5% late fee per month on overdue balances. • Data handling: vendor stores customer data in EU-region servers, retains it for 90 days post-termination, then deletes it. • Liability is capped at 12 months of fees paid; the agreement excludes consequential damages. • Either party may terminate for cause with 30 days' written notice and a cure period.
Question 1: "What's the exact notice period if I want to cancel without cause?" Answer: "Not found in this document. The excerpt only specifies a 30-day notice period with a cure period for termination for cause — it does not separately address a without-cause cancellation right or notice period."
Question 2: "Where is customer data stored, and how long is it kept after the contract ends?" Answer: "Customer data is stored on vendor servers in the EU region. After termination, the vendor retains the data for 90 days before deleting it."
Question 3: "Is there a cap on how much the vendor can be sued for?" Answer: "Yes — liability is capped at the equivalent of 12 months of fees paid under the agreement, and the agreement excludes consequential damages."
Notice the shape of these answers: specific, sourced directly from the extracted text, and — in the first case — explicitly honest about what the document doesn't say rather than inferring a plausible-sounding number. That's the entire point of grounding the answer in the document text instead of letting the model reach for a generic, plausible-sounding "usually 30 or 60 days" guess.
What this is not
This is not a persistent, multi-document chat assistant, and it's not a substitute for reading a document you need to act on legally or financially — treat answers the way you'd treat a fast, literal-minded research assistant: good for pulling a specific fact out of a document you've already reviewed at a summary level, not a replacement for your own judgment on anything consequential. It's also not available on every summary source type in the current version: it only appears after a PDF file is uploaded directly to @vustSummaryBot and summarized through that document-upload path. A PDF reached via a URL link goes through a different extraction path in the current build and does not currently show this button — if that's your use case, summarizing the same document as a direct file upload is the way to unlock chat-with-PDF on it today.
What happens if a question fails partway through
Every question is charged only after it's genuinely answered, never before, and never for a rejected attempt. If the underlying AI call fails for any reason — a transient provider error, a timeout — the 1✦ charge is automatically refunded and you get a plain "could not answer that question, try again" message instead of silently losing a spark. The same applies if the answer is generated successfully but delivering the message back to you somehow fails: the refund happens either way, so a technical hiccup never quietly costs you a spark you didn't get value from. This mirrors the same deduct-before-call, refund-on-error pattern @vustSummaryBot already uses for its paid summaries — chat-with-PDF doesn't introduce a new, less careful money-handling path just because the individual charge is smaller.
How this fits with the rest of @vustSummaryBot
Chat-with-PDF deliberately reuses everything the bot already has rather than introducing a parallel system: the same result-context storage mechanism used elsewhere in the bot, the same underlying Claude model used for the original summary, and the same spark wallet used for every other paid action in the bot. The only things genuinely new are the button, the 30-minute armed state, and the 3-question, 1✦-each pricing around it. If you're already summarizing PDFs in @vustSummaryBot regularly — contracts, research papers, reports, meeting notes exported as PDF — this is a small, bounded extension of a workflow you're already using, not a separate tool to learn.