Two model fields: deepseek-flash for your planner, sume-agent for Sume

Use two separate settings: one for the model that plans, one for the Sume Agent. On DeepSeek's September 10 notice, V4.1 Flash has the API model id deepseek-flash, and the older ids deepseek-v4-flash and deepseek-v4-flash-vision-exp temporarily route to it (read 2026-10-05). On a Sume Agent Completion, model accepts only sume-agent. A single shared model variable would send the wrong id to one of them.

What each field accepts

The Sume docs state it plainly: model is optional on POST /v1/agent/completions, only sume-agent is accepted, and omitting it gives the same agent. Any other value is an invalid_request 400, listed in the errors table alongside a missing spend cap.

The failure this prevents

Agent frameworks often keep one MODEL constant and pass it everywhere. When the planner moves to a new id, a tool wrapper that forwards the constant to Sume turns into a stream of 400 errors. The reverse is quieter: a wrapper that hard-codes sume-agent for the planner would get a model-not-found from the planner API.

Do not forward a model name to Sume at all. Leaving model out is documented to give the same agent.

A wrapper that cannot leak the planner id

The function below builds the request body from only the fields Sume needs. It runs offline and has no model parameter to misuse.

import json

def sume_completion_body(task: str, cap_usd: float) -> dict:
    if cap_usd <= 0:
        raise ValueError("cap_usd must be positive")
    return {"instruction": task,
            "generation_spend_cap_usd": cap_usd}

PLANNER_MODEL = "deepseek-flash"

if __name__ == "__main__":
    body = sume_completion_body("Cut a 15 second teaser", 2)
    assert "model" not in body
    print(PLANNER_MODEL, json.dumps(body))

What the Sume receipt echoes back

The 202 receipt carries model: sume-agent and a thread_id. Each completion runs in a new thread, and the receipt's thread id identifies it. Log both next to your planner's model id, so a later audit can tell which planner version asked for which run.

If you keep a per-run record, add the planner id, the Sume run id and the cap you sent. That three-field record is enough to reconstruct why a run happened and what it was allowed to spend, without storing prompts or keys.

Keep in mind that Sume treats input as data and not as instructions, so nothing you put in the planner's own config can change what the Sume Agent is told to do. The instruction or messages you send are the only prompt it follows.

When the planner changes again

Model ids on the vendor side will keep moving. The notice already says V4-Pro requests will route to V4.1-Flash from September 14, 2026 (read 2026-10-05). Keep that churn in the planner's config file. The Sume wrapper should not need a release.

• Store the planner id in one config key and read it only in the planner client.
• Leave model out of Sume calls.
• Add a unit test that the Sume body has exactly instruction or messages plus the cap.