How generation works
One scoped call per section, not an agent loop. This is why it is fast and cheap.
DocDealer is not a general-purpose agent pointed at a document. It makes one scoped AI call per section, with the prompt assembled by the server before the model is ever invoked.
That single design choice is where the cost and latency difference comes from.
Why this is cheaper than an agent
| DocDealer | A general-purpose agent | |
|---|---|---|
| Calls per document | One per section | Typically 30–100 tool calls |
| Model | google/gemini-2.5-flash | Usually a frontier-class model |
| Context | Preassembled, scoped to the section | Discovered by exploration |
| Wall clock | 3–15 s, streamed | 1–5 minutes |
The agent burns tokens on scratch reasoning, JSON repair and tool discovery — work that never reaches the document. DocDealer does that assembly deterministically in server code, so every token spent is a token of prose.
Roughly 50× cheaper and 20× faster for the same task. Not because the model is better, but because the loop is absent.
What keeps it cheap
Tools available during a section
Generation is not pure text completion — a section can call:
Prop
Type
The call types
Every AI call is typed, logged with its cost, and billed. The types you can trigger over the API:
| Type | What it does | Relative cost |
|---|---|---|
generate_section | Drafts one section; can call tools. | High |
analyze_file | OCR, transcription and structured extraction from an attachment. | High |
analyze_form | Validates form entries against the template's validation rules. | Medium, hash-cached |
analyze_document | Validates the drafted document. | Medium, hash-cached |
generate_title | A short document title from form data. | Low |
The two that spend meaningfully are generate_section and analyze_file. Their API scopes
(documents:generate, attachments:analyze) exist precisely so you can mint a key that cannot
spend — see Authentication.
Determinism
Generation is not deterministic, and the docs will not pretend otherwise. What is deterministic is everything around it: which sections apply, which fields are required, what the prompt contains, and what counts as valid. That is the point of putting the schema and the rules in the template rather than in the prompt.
For text that must be word-for-word identical every time, use a static rule — the example content is emitted verbatim with no model call.