One Document, Two Ways to Send It: PDF Attachment or Rendered Page Images on the Same Key

Two input paths for the same document

When your application needs a model to read a PDF, you have two practical input paths:

• Send the PDF directly as a file part or URL, letting the model's document pipeline handle extraction and any internal rendering.
• Pre-render each page to an image and send those images as image parts.

With a single API key from an aggregator that exposes many models (Claude, GPT, DeepSeek, Qwen, GLM, Kimi), you can choose the path per request. That choice affects token cost, which models work, and how faithfully the document is represented.

Path 1: Sending the PDF directly

Here the model receives the document and its backend handles parsing, page rendering, and text/image extraction.

Backend support

• Only models whose API accepts PDF or file inputs can take this path. Capabilities differ across providers and model families.
• Models without native document input cannot process the same request; you must switch models or switch paths.

Token cost

• Billing usually includes extracted text plus any page images the backend generates internally.
• You do not control how the backend renders pages, so token usage can be less predictable than with pre-rendered images where you know the exact page count.

Fidelity

• Convenient for text-heavy documents, but layout details are interpreted by the backend and may vary by provider.
• Scanned or image-only pages, complex tables, and unusual fonts may be extracted unevenly.

Path 2: Pre-rendering pages to images

You render each page to an image (for example, PNG or JPEG) before sending, then pass the images as image parts.

Backend support

• Any vision-capable model can accept images. This widens the set of usable models, including those without native PDF input.
• The same pre-rendered images can be sent to different models with the same key, making A/B comparisons straightforward.

Token cost

• You control page count and image resolution. Token usage scales with the number of images and their dimensions.
• Avoid re-sending identical pages, and downscale when the model does not need full resolution.

Fidelity

• The model sees exactly what you rendered: visual layout, stamps, signatures, and table structure are preserved as pixels.
• You can tune resolution per workload, trading token cost against fine detail.
• Downside: you manage the rendering step and must ensure legibility.

Side-by-side comparison

| Aspect | PDF direct | Page images |
|--------|------------|-------------|
| Backend support | Only models with PDF/file input | Any vision-capable model |
| Token cost | Includes backend's internal rendering; harder to predict | Proportional to pages and resolution you choose |
| Fidelity | Text extraction plus backend's layout interpretation | Exact visual representation of rendered pages |
| Operational effort | Simpler request; no rendering step | Requires a rendering pipeline |

Choosing per request

• Use PDF direct when the document is mostly text, the chosen model supports file input, and you want minimal preprocessing.
• Use page images when you need a model without PDF support, want visual fidelity for layout-heavy pages, or need predictable token usage based on page count.
• Mix paths across models: send the PDF to a document-capable model and rendered pages to a vision model, then compare outputs.

Cost and key mechanics

On this platform, usage is billed at the official model price × 1.3. If you contribute keys, you are credited at official price × 1.1 (or × 1.2 for premium models) in USDC. Top-ups use USDC on Base without KYC, and one key works across all supported models.

Compare paths against your actual document mix: page count, image resolution, and whether the selected model accepts PDFs. Because the multiplier is uniform, choosing between PDF and images mainly changes the underlying token count, not the billing rule.