Bulk text work rarely arrives as one tidy task. One queue needs support tickets sorted, another needs invoice fields pulled into a spreadsheet, a third needs product copy translated, and a fourth needs call transcripts compressed into briefs. At the API level these jobs look similar: send text, receive text. At the operational level they are different jobs with different failure modes, output budgets, and validation rules. The useful question is not which text model has the best demo. It is which job shape you are running, and what a successful item looks like in production.
Classify and Extract: Small Outputs, Strict Shapes
Classification is the simplest text job to describe and one of the easiest to get wrong at scale. You have rows of input — support tickets, product descriptions, chat transcripts, survey answers — and you want one label from a fixed set: billing, shipping, returns, abuse, spam, or whatever taxonomy your team uses. The model is doing a mapping, not creative writing. That changes the prompt design. Put the label list in the system message, state the tie-break rules, and ask for a single label or a compact JSON object. If you need a confidence field, define its scale and what to do with borderline cases. Do not let the model invent categories unless you are prepared to reconcile them later. For batch work, a schema validator is your friend: reject a response with two labels or a label outside the list before it reaches a dashboard.
Extraction looks similar at the API level and is materially different in practice. The input is usually longer and messier — invoices, contracts, emails, résumés, product specs — and the output is structured data: line items, dates, totals, addresses, identifiers. The prompt has to define the field names, the expected type, the null policy, and the source-of-truth rule when two numbers disagree. A text model can extract from text that is already readable; for PDFs and scanned images, start with an OCR-to-Markdown step. Y-PAD lists GLM-OCR as a separate PDF/image-to-Markdown model, which is a cleaner first stage than asking a text model to infer pixels. After extraction, validate types, ranges, required fields, and cross-field arithmetic. Keep the raw response for debugging and route validation failures to a review queue rather than silently patching them.
Both jobs benefit from short, explicit prompts and small output budgets. Y-PAD’s text endpoint accepts text/plain or an application/json messages array with at most 64 system, user, and assistant texts, and can return text or json. The endpoint exposes a max_tokens range of 1 to 8,192, with a default of 2,048. For classification, cap it tightly; for extraction, set it to the largest plausible record, not the default. Remember the per-file 100-token minimum; on tiny one-label files, that minimum can dominate the arithmetic.
Translate and Summarise: Output Length Drives the Bill
Translation and summarisation are where output length becomes the main cost driver. Translation is roughly length-preserving: a 2,000-word source becomes a 2,000-word target, plus the instruction and any glossary. Summarisation is compression by design, but the summary still has a target length, and long documents often require chunking. In both cases, the model’s output tokens are the part you can control. A prompt that says “translate this” and a prompt that says “translate this into French, preserve placeholders such as {customer_name}, keep product names in English, use the glossary below, and return only the translated text” will produce very different review loads. For bulk catalogues, extract placeholders and HTML tags before translation and validate that they survive afterwards. For legal or support content, keep a do-not-translate list and a glossary per locale, then test on a sample of 50 to 100 files before scaling.
Summarisation needs a compression rule. “Summarise in three bullets” is testable; “summarise” is not. Specify the audience, the maximum words, whether to include dates and amounts, and whether to preserve action items. For long reports or call transcripts, use a map-reduce pattern: summarise each chunk with the same schema, then combine the chunk summaries into a final summary. Keep the intermediate summaries so you can audit where a number came from. If the source is a transcript, upstream transcription quality matters; a garbled name in the transcript will become a garbled name in the summary. Also decide whether the summary is a standalone artefact or an index for retrieval, because that changes how much detail to retain.
Cost control is easier when you measure the job shape rather than the model name. Y-PAD lists its text-generation model as a DeepSeek v4 api, described for classify, extract, translate, and summarise. As of 7 Nov 2026, the provisional beta fares were $0.0015 per 1,000 weighted tokens at list and $0.0009 at launch, with output tokens plus input tokens at 0.25 and a 100-token minimum per file. Those are beta fares, so confirm the live pricing page before committing a large run. The model runs on Google Cloud Vertex AI, not Y-PAD’s GPUs; prompt files leave Y-PAD storage and are sent to Google for each run, which matters for data-handling reviews. For output, text or json is available, and max_tokens can be set per request.
Operational Fit: Batch Mechanics and Routing Rules
Operational fit is where many text pipelines fail quietly. At submit, Y-PAD holds the sum of max_units × list price; at settlement, succeeded units are charged at launch price if you hold a launch seat, otherwise list, and unused hold returns. Failed and cancelled items cost nothing, but only successful items are billed. That means a batch with many validation failures is not just a quality problem; it is a throughput and planning problem. Preflight a small sample with the exact prompt, schema, and max_tokens you intend to use. Then submit the batch and poll, because there are no webhooks. Expect a cold start of roughly 10 to 30 seconds, occasionally minutes, and remember that later items in a batch can ride on the same start. Upload links last one hour, outputs stay for seven days, and a batch can contain up to 2,000 items with up to 100 files per call.
A simple routing rule helps. Send short, fixed-label work to a classification configuration with a small max_tokens and a validator. Send document-field work to an extraction configuration with a JSON schema, null rules, and a review queue. Send locale-specific content to a translation configuration with a glossary and placeholder checks. Send long-form digests to a summarisation configuration with a compression target and a map-reduce plan. On Y-PAD these can share one text model and one API key, but they should not share one prompt. Keep the system message, examples, output schema, and max_tokens in versioned configuration so you can compare batches over time. If you have image or audio stages, separate those costs too: OCR pages and transcript minutes are billed on different units from text tokens.
