Kilo scheduled sessions vs a Sume schedule for recurring renders

Kilo Code v7.8.3 now reports a session that is asleep on a pending wakeup or cron task as scheduled, with its wake time (release notes, read 2026-10-04). That is a status for a session that exists on your side. A Sume schedule is a saved object on Sume's servers, so recurring renders do not depend on a Kilo session still being alive. Use the Kilo session to drive a one-off job, and a Sume schedule for a cadence.

What the two things are

The Kilo change is about how a waiting session is reported. The release note is one line and does not say where the session's state is stored, so do not assume a scheduled session survives a closed editor or a stopped host. Check Kilo's own docs for that before you rely on it.

A Sume schedule stores instructions, a model, a 5-field cron expression with a timezone and a spend cap. Sume runs it as an Agent in a fresh thread on each tick and keeps a receipt per run (Scheduled).

What a Kilo-driven run needs for paid Sume calls

If a woken Kilo session calls the hosted MCP at https://mcp.sume.com/mcp, the paid-call gates apply on each call. idempotency_key is required on write and paid tools and stops a repeat from rendering twice. dry_run previews, and max_spend_usd enforces a ceiling when you send it (MCP tools and gates).

Derive the key from the intent, not the attempt. For a Monday render use something like weekly-banner-2026-10-05, so a session that wakes twice produces one render.

How to choose

Keep it in Kilo when a person is around to review the output and the work mixes code edits with a render. Move it to a Sume schedule when the job is just generation on a cron cadence and a missed tick should not depend on a dev machine.

• Run history you can read later: a Sume run row per tick.
• Overlap protection: a Sume schedule runs one at a time and skips a second by default.
• Work that edits your repository: Kilo.