Splitting a big task for a cheap model: the 24,000-byte lesson

📦 Volume work and cheap models

Many tasks are a large amount of the same small work: check every page, extract fields from every file, review every country. A low-cost model is a good fit for each small unit. The failure comes from handing it the whole pile in one request. It loses track, truncates, or is refused by the provider after you have paid for the input.

🚫 The limit and the incident

Our terminal agent accepts a task of 1 to 24,000 bytes and refuses anything else before a model is called. On 21 October 2026 a packet of about 125 KB was submitted to five lines in parallel for a review. All five came back with exit code 1 and the message that the task must be between 1 and 24,000 bytes. No model was called, so no money was spent, and the review did not happen. The cost was the time of an unattended run.

The limit is a guard, and it did its job. The mistake was upstream: nobody checked the size when the packet was built.

✂️ How to split

Split along units that do not depend on each other: one file, one country, one customer, one page. Each task then holds its own input, its own instruction and its own acceptance check. The checker can run on each result alone.

A few rules help.

• Size check at build time. The packet builder refuses to write a packet over the limit. Do not leave it to the worker.
• One unit, one result file. Name results after the unit so that a failed task can be rerun on its own.
• Shared context goes in a short header. A common instruction of a few hundred bytes is fine. Copying a whole policy into each task is not.
• A merge step by script. Combine the results with a deterministic script and check completeness: every unit has a result, none twice.

📏 A small, real example

For the topic selection on this wiki we sent three models one packet that held a list of reference sections, our own article titles and the output format. It was 17,880 bytes, under the limit. Two paid runs cost $0.0020 and $0.0028. The same job as one large document would have been refused or truncated.

🛠️ Practice: build a splitter

1. Define the unit: the smallest piece of input that produces a result on its own.
2. Write the instruction once, with the output format and the acceptance check.
3. Write a builder that creates one packet per unit and refuses any packet above your limit, with a message that names the unit.
4. Run the builder on the full input. Count packets, the largest size and the total size.
5. Run five packets first. Check them with the script, not by eye.
6. Run the rest, then merge with a script that reports missing and duplicate units.

✅ Check yourself

• Feed the builder a unit that is too large. It stops and names the unit.
• The merge report shows zero missing and zero duplicate units.
• A single failed unit can be rerun without touching the others.
• You can state the cost per unit from your ledger.

🚧 When this does NOT work

• Units that depend on each other. A document that refers to a page in another packet cannot be judged alone. Add a short summary of the neighbour, within the limit.
• A unit that is itself too big. A single file above the limit needs a second split, by section, with care at the borders.
• Cross-unit questions. "Which of the 40 countries is best?" is not a unit task. Do it afterwards in a second pass over the short results.
• Overhead. For a dozen items, splitting costs more than it saves. Do the job in one request.
• Quality across units. Different tasks may give different styles. Fix the format and examples in the header.

📊 Evidence

➡️ Next

Learn how to hand work over with acceptance criteria in Spec-driven development with existing task packets, and how to count what it costs in Cost per accepted result.

Sources

• Spec-driven development with existing task packets: task packets.
• Cost per accepted result: counting cost.
• Splitting work across agents, and when not to: swarm work.
• Context windows and tokens: what fits in a request.