Live-commerce Format: instruction past 4,000 characters is cut

On a live-commerce Format run, the API cuts instruction at about 4,000 characters and keeps only the start, with no error, while input above 2 MiB gets a loud 400. So put the broadcast script in input.script, keep instruction short, and send input as a JSON object, not a stringified blob.

Two limits that fail in opposite ways

The live-commerce docs describe two size limits. The first is loud. The API rejects input above 2 MiB (2,097,152 UTF-8 bytes), or above 64 top-level properties, measured on the compact JSON. You see a 400, and you fix it.

The second is quiet. When Sume carries instruction into the run, it cuts at roughly 4,000 characters and keeps the start. Nothing tells you. The tail of your text is simply missing, and a script that you pasted there will end mid-sentence.

Where each piece belongs

Use instruction for decisions in prose: use the script as written, the framing, no BGM, no captions. Use input for data: product_url, host_image_url, vo_language, price and script.segments. input must be a JSON object. A stringified blob gets a 400.

The recipe reads the keys it knows. Other keys go to the run as context, but they are not echoed back in output, so keep your own row ids in your database.

A script shaped for the Format

The script is a list of segments, each with a tag. The docs use Intro, Mid and Fin. Tell the agent to use the text as written, because the default behavior of an agent is to tidy a script.

{
  "instruction": "Use the Intro/Mid/Fin script as written; do not shorten. Vertical 9:16, no BGM, no captions.",
  "input": {
    "product_url": "https://shop.example.com/p/4438469916",
    "vo_language": "ko",
    "script": {
      "segments": [
        { "tag": "Intro", "text": "..." },
        { "tag": "Mid", "text": "..." },
        { "tag": "Fin", "text": "..." }
      ]
    }
  },
  "generation_spend_cap_usd": 120
}

Cap the spend and catch the end

Send generation_spend_cap_usd on every run. The cookbook uses about $120 as the ceiling for a production live-commerce run, and a much smaller cap for a single-scene retry. A webhook URL in communication gets one signed POST when the turn ends, so you do not need to poll.

Post the run to /v1/formats/{owner}/{slug}/runs with an Idempotency-Key. Store data.id and data.thread_id with your row. The first reads the receipt, and the second groups retries.