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
- AI Act Article 50(1) chatbot notice for an agent built on Sume
Article 50(1) asks providers to make sure people know they are talking to AI. If you front Sume Agent Completions with a chat box, the notice is yours to add.
- Flow Agent batch edits and asset tidying: keep a Sume manifest
Flow Agent can batch edit and organize assets inside Flow. Sume has no asset organizer; a manifest of job ids and media URLs does the job. Code included.
- GitHub Actions schedule delayed at the top of the hour: what to do
GitHub says scheduled workflows can be delayed, notably at the start of every hour. Offset the cron minute and call a Sume Scheduled run with a dated key.
- GitHub Actions schedule disabled after 60 days: a Sume Scheduled fix
A public repo's scheduled workflows are disabled after 60 days without activity. How Sume Scheduled's active and inactive status differs.
Written by Sume