The first decision in a bulk text job is not which model to call. It is what shape the payload takes on the wire. Two pipelines with identical prompts can produce different bills, different failure modes and very different amounts of engineering work purely because one sent a bare string and the other sent a structured list of role-tagged messages.
Both forms are supported by most serious text endpoints, and both are defensible. What matters is knowing what you give up when you pick one, and how that choice interacts with the way bulk providers validate, meter and hold balance for your work.
Input Shapes and What They Actually Mean at the Wire
At the simplest level, plain text means the entire prompt is a single string. You upload one file or one row, and the model receives one undifferentiated block of characters. There is no notion of instruction versus data beyond whatever delimiters you invented. For a single-shot task such as classifying a support ticket, extracting named fields from an invoice line or translating a paragraph, this is often all you need, and it is the cheapest thing to build: no serialisation layer, no schema, no escaping beyond your own separators.
A messages array is JSON instead. Each entry carries a role — system, user or assistant — plus a text body. On the DeepSeek V4.1 Flash model page, for example, application/json inputs accept a messages array of at most 64 system, user and assistant texts. The structure makes implicit contracts explicit: the system message holds the standing instruction, the user message holds the row you are processing, and assistant messages carry either prior turns or few-shot exemplars. The docs describe the JSON as shaped like Replicate’s, which shortens migration for teams coming from that ecosystem.
The practical consequences diverge quickly. With plain text, your delimiters have to survive your data. If a field legitimately contains the same triple-hash fence you use to separate instructions from content, prompt confusion becomes an ordinary data quality problem. A messages array removes that specific ambiguity because role boundaries are structural rather than textual — though a model can still be talked out of its instructions, so structure is not a security control.
Validation behaviour differs too. A malformed JSON payload fails before the model is called, which is a good outcome in bulk: the item is rejected at submit rather than silently producing a garbage answer you pay for. A plain-text file almost never fails validation, so bad inputs surface as bad outputs three steps downstream. Since only successful items are charged, structured input pushes more failures into the cheap category. Change management is the last differentiator: rewriting a plain-text template usually means editing a string builder and every test that asserted on it, while a messages array can be versioned, diffed and reviewed like code.
How Input Shape Interacts With Token Accounting and Holds
Text generation on Y-PAD’s DeepSeek V4.1 Flash model is sold per 1,000 weighted tokens, where output tokens count at full weight and input tokens count at 0.25 — the published ratio on the model page — with a 100-token minimum per file. List price is $0.0015 and launch price $0.0009 per 1,000 weighted tokens as of 7 Nov 2026. Those are provisional beta fares, so confirm current numbers on the live pricing page before you commit a budget.
That weighting should change how you think about prompt shape. A 400-token system preamble repeated across 200,000 rows is not free, but it bills at a quarter of its raw length, landing near 100 weighted tokens per file. What you generate is the expensive side of the equation. The DeepSeek api on Y-PAD is therefore forgiving of verbose, careful instructions and unforgiving of rambling generations, which subtly favours the array format: it gives you a clean home for a long preamble without repeating it inside every row’s template.
Hold mechanics matter more than per-token arithmetic for anyone running bulk jobs. At submit, Y-PAD holds the sum of max_units multiplied by list price; settlement charges succeeded units at launch price if you hold a launch seat and at list price otherwise, returning the unused hold. Because max_tokens accepts 1 to 8,192 with a default of 2,048, a classification job that never emits more than ten tokens still ties up balance as though it might emit two thousand. Setting max_tokens to a realistic ceiling is the cheapest optimisation available and costs nothing to implement.
Two further constraints shape the array format specifically. The messages array is capped at 64 texts, so long documents need chunking before submission rather than truncation after a failure. And because this model runs on Google Cloud Vertex AI, the prompt file leaves Y-PAD storage and is sent to Google for each run — a detail worth reading twice if your text contains personal data or anything under an agreement that does not cover that transfer. Note also that Y-PAD applies batch pricing to every request, with no minimum charge beyond the per-file unit floors, so one file costs the same per unit as a thousand.
Operational Rules for Shaping Prompts in Production
Pick one shape per job and record the decision in your repo. Mixed pipelines, where some rows are plain strings and others are arrays, are hard to validate, hard to re-run and impossible to A/B test cleanly.
Keep the standing instruction in a system message instead of re-pasting it into every row. The token weighting makes the cost argument weaker than it first appears, but the maintenance argument holds: one place to change the tone, the schema or the refusal behaviour.
Ask for JSON output only when you intend to parse it. The model page exposes an output setting for text or json, and JSON pairs naturally with a messages array because the schema can live in the system message. If downstream systems expect exactly one label, a plain text answer is easier to validate than a lightly structured one that has to be coerced.
Chunk long inputs before submission. The 64-message cap and the max_tokens ceiling both bound what a single item can sensibly carry, and a truncated document produces a confidently wrong extraction far more often than a clean failure. Treat the array as a transcript, not a chat: leave assistant turns in only when they are deliberate exemplars, because stray history silently inflates input tokens and confuses small models.
Use the playground before writing code. Watching how a given array is tokenised and answered beats debugging a 2,000-item batch, and Y-PAD exposes its models for trial runs for exactly that reason. Then plan the plumbing around the shape: upload links last one hour, a call accepts up to 100 files, batches hold up to 2,000 items, and there are no webhooks, so you poll. Cold starts run 10 to 30 seconds and occasionally minutes, with later items in a batch riding the same start — which makes one large batch of small text items materially better than many tiny batches. Outputs stay available for seven days, so download and archive them rather than treating the API as storage.
