Sume Format instruction limit: why long briefs belong in input

A Format instruction accepts 8000 characters but only about the first 4000 reach the prompt. Put long briefs in the input field, which is stored whole as data.

4 min readSume
All posts

A Format run's instruction field accepts up to 8000 characters, but only about the first 4000 are carried as prompt text. If your brief is longer, put the bulk in the input object and keep the instruction short and decisive.

This is easy to miss because the API does not reject a long instruction. The tail simply does not reach the run, so a call can succeed and still ignore your last paragraph.

Because the API accepts the long text, nothing in the response warns you. Count characters in your own code before the call and log a warning above 3,500.

What each field does

The instruction is placed after the Format's own body, so on a conflict the instruction wins. That makes it the right place for the one thing that changes per call, such as the tone for today's batch or a number of scenes.

The input object holds up to 64 top-level keys and 2 MiB. It is written whole to /workspace/inputs/sume-action-input.json inside the run and is treated as data, not instructions. The Call a Format page has the field rules, and the request must name at least one of instruction, input, previous_run_id, or attachments or it returns 400.

A split that works

Keep rules in the Format package, where they are versioned. Keep per-call facts in input, such as the product name, price, claims you are allowed to make, and links to media. Keep the instruction to one or two sentences that tell the run what to do with that data.

For example, an instruction of Make a 20 second ad using the product record in the input file, lead with the main benefit leaves the product detail to a JSON file the run can read in full.

If the brief genuinely needs to be long, such as a script of 30 scene notes, the input file is the right container. The run can read the whole 2 MiB file, while the instruction stays a pointer to it.

Where text goes on a Format run, from the Sume docs (read 2026-10-10)
FieldLimitTreated asBest for
instruction8000 accepted, about 4000 carriedPrompt text, after the Format bodyThe one per-call directive
input64 keys, 2 MiBData in a JSON fileRecords, copy decks, product facts
attachments30 images, 30 MB each, 500 MB per runReference imagesProduct shots
previous_run_idOne earlier runContinuation of a threadRevisions

Two consequences to plan for

First, input is data. A line inside it that says ignore your rules is not an instruction to the run, which is the safer place to put customer-provided text. Second, input never reaches the structured output projection, so ids you put in do not round-trip into your output. Carry your own record id in your run index instead.

Media URLs inside input share a budget: 30 files in total, at most 30 images, 10 videos, and 10 audio files. Exceeding it returns 400 invalid_attachment.

A related habit is to name your input keys clearly. Keys like product, claims, and scenes are easier for the run to find than a single blob called data.

A quick audit

Measure your instruction strings. If any are near 4000 characters, move the middle into input. If your Format body repeats the same paragraph in every instruction, move it into the package once. Short instructions are easier to review in a pull request and cheaper to debug.

Sources

Related posts

More in Formats

All Formats posts

Written by Sume