Use case
The best API for structured data extraction
Extraction is the one workload where the cheapest model on paper is often the most expensive in production, because every response that fails schema validation costs a full re-send of the source document; GLM-5.2 is the pick here for its schema-constrained output and function-calling reliability, which is what keeps the retry rate — and therefore the real bill — down.
The unit of work is a document in and a record out. Input dominates, but not as brutally as summarisation, because a populated schema with a dozen fields is a real number of output tokens rather than a sentence.
What makes this workload different is that failure is billable. A malformed or hallucinated field means running the document again, so the effective cost per successful record is the model's nominal cost divided by its first-pass success rate. Divide two models' per-run costs and you get the retry rate at which the cheaper one stops being cheaper — that ratio, not the price list, is the comparison worth making.
What actually matters here
- Schema adherence
- A response that does not validate costs the whole request again. This is the only workload here where reliability converts directly into a line on the invoice rather than into user experience.
- Function-calling and JSON mode
- Constrained decoding removes an entire class of failure — malformed syntax — leaving only the harder problem of wrong values. A model without it is being asked to be correct by luck.
- Input rate
- The source document is re-sent on every attempt, so the input rate is both the base cost and the penalty multiplier when a retry happens.
- Determinism across runs
- Extraction pipelines get re-run over the same corpus after a schema change. A model that answers differently each time makes diffs meaningless and makes back-filling untrustworthy.
What it costs, at 400,000 documents/month, ~3K tokens each
Worked from this catalogue’s published rates at 1,200M input and 140M output tokens a month. Your figure will differ; the arithmetic will not.
| Model | Input | Output | Per month | At official rates |
|---|---|---|---|---|
| GLM-5.242% | $0.82/M | $2.55/M | $1,341.00 | $2,296.00 |
| DeepSeek V4 Flash36% | $0.090/M | $0.18/M | $133.20 | $207.20 |
| DeepSeek V4 Pro37% | $0.28/M | $0.55/M | $413.00 | $643.80 |
Excludes cached-input savings, which on a repeated-prefix workload typically reduce the input column substantially. Cached rates are published per model on the pricing page.
Questions
- How do I know whether a cheaper model is actually cheaper?
- Run both over a few hundred labelled documents and record the first-pass validation rate, not just the price. Divide the expensive model's cost per run by the cheap model's, and if the cheap model's failure rate is worse than that ratio implies, it is losing money on retries. This is a half-day experiment that decides a recurring bill.
- Should I validate before or after storing?
- Before, always, and with the same schema the model was constrained to. Validating downstream means a bad record is discovered by whatever consumes it, which is far more expensive to unpick than a retry at extraction time.
- Does a two-stage pipeline help?
- Often. A cheap model does the first pass and a validator routes only the failures to a stronger one, so you pay the higher rate on the minority of documents that need it. It is worth building once your volume makes the difference between the two models material.
- Do cached-input rates apply to extraction?
- To the schema and instruction prefix, yes — that block is identical on every call and is exactly what the cache is for. The document itself is unique per request and is billed at the standard input rate.