Which model runs a Sume scheduled agent, and how to choose it
A Sume schedule stores its own model beside its instructions and cap. Where to pick it, what Agent Completions accepts, and what the changelog says on defaults.
A Sume schedule stores its own model alongside its instructions, cron expression and spend cap, and you choose it when you write the instructions in the dashboard. A caller of the Developer API does not pick the model per run.
This is from Create a schedule, step 2, and the model field in the schedule shape on the Scheduled overview.
Where do I set the model for a schedule?
Open https://www.sume.com/agents/scheduled, create or edit the schedule, write the instructions and pick a model there. The public GET /v1/actions/{action_id} response returns a model field, but the Developer API has no create or update endpoint, so the dashboard is the only place to change it. Instructions themselves are deliberately omitted from the public shape.
When you change the model on an existing schedule, remember it is saved state. The next cron fire and every API call after the edit use the new model, with no change in your caller. That is convenient for a fix and risky for a regression, so edit the schedule during a quiet window and watch the first run's receipt. Because output_schema is also saved on the schedule, a model swap that changes how a field is filled can surface as output_error on the receipt rather than as an HTTP error.
What about Agent Completions?
POST /v1/agent/completions has a model field that accepts only sume-agent. Omit it and you get the same agent. Any other value returns 400 invalid_request. So there the field names the agent, not a language model choice.
| Surface | Model control |
|---|---|
| Scheduled run | Saved on the schedule in the dashboard |
| Agent Completion | model accepts only sume-agent |
| Per-run override of the schedule's model | Not in the documented request body |
What is the default?
Sume's changelog says Grok 4.5 became the default agent model in v0.2.55 (July 31, 2026). Treat that as history, not a promise about today: the docs do not pin a current default for schedules, and defaults move.
If an output depends on one specific model, do not rely on the default. Pick the model explicitly on the schedule and re-check it when the catalog changes.
If you need a different model for one run, the documented options are to create a second schedule with that model, or to use Agent Completions, where the model field is only the agent name. The docs do not describe a per-request model override on Scheduled runs, so do not assume one exists.
Who pays for the model?
The agent's own LLM turn bills a separate Agent wallet, apart from generation spend. The per-run generation_spend_cap_usd bounds generation only, so it is not a cap on the model's own tokens. Read Runs and results for the exact split, and GET /v1/usage for the authoritative bill.
For a production schedule, the receipt's usage shows generation spend, and GET /v1/usage shows the rest.
Sources
Related posts
More in Agents
- hypit Understand order: one probe, then parallel batches
Sume's hypit Understand order: probe alone, then transcribe, boundaries and tiles in one batch, then notes. Which verbs wait on the transcript.
- How an agent picks a video model over hosted MCP
An agent reads video-router_models, picks an id, then calls generate_video with an idempotency_key and waits with jobs_wait. Omit the model for sume/auto.
- Get a typed podcast clip plan from an Agent Completion
Send a transcript and an output_schema to POST /v1/agent/completions, and get back start and end times for each clip, ready for video-trim.
- Poll a Sume Action run in Python: branch on next_action, not status
A small Python loop for a Sume Scheduled run that sleeps on poll_status, retries on retry_later and stops on none, then fetches the result.
Written by Sume