Crons
A cron sends a saved prompt to one or more of the workspace's projects on a schedule. Each time it fires, Kosuke hands the prompt, word for word, to the Cron Agent in the main sandbox of each project. Every project gets its own run, and they all start at once. Open Crons in the sidebar to create a cron and to read what every run did. Every run spends the workspace's Credentials and credits, never a member's Subscription.
Create a cron
- Open Crons in the sidebar and press New cron.
- Enter a Name, such as "Triage new issues".
- Under When it runs, pick a Frequency. Each preset fills in the Crontab, and you can edit it.
- Check Next three runs to confirm the schedule. The times are in the Workspace Timezone, which the line under them names.
- Under What it does when it fires, pick the Projects and the Model.
- Write the Prompt. Type
/to pick a skill. With an OpenAI model, skills start with$. - Press Save and enable.
The cron is on from the moment you save it. Leave Model on Default to run on the workspace's default model. The picker lists only models the workspace's Credentials can run.
The Projects picker lists every project in the workspace. Search it, tick the projects you want, or press Select all. Pick at least one. The cron keeps the projects you picked when you saved it. A project created later joins only when you edit the cron and add it.
With several projects picked, / offers only the skills every picked project has.
| Frequency | Crontab | Fires |
|---|---|---|
| Hourly | 0 * * * * | At the start of every hour |
| Daily | 0 9 * * * | Every day at 09:00 |
| Weekly | 0 9 * * 1 | Every Monday at 09:00 |
| Monthly | 0 9 1 * * | On the 1st of every month at 09:00 |
| Custom | Your own | Five fields, in this order: minute, hour, day of month, month, day of week |
A crontab is read in the Workspace Timezone. It may not fire more often than every 15 minutes.
If the dialog says "No workspace provider is configured.", the workspace has no Credentials a cron can run on. Ask an admin to connect a provider in Settings > Workspace > AI Providers. Until then, Save and enable stays off.
The Workspace Timezone
Every cron in a workspace runs in one timezone, the workspace's. A cron has no timezone of its own, so 0 9 * * * fires at 09:00 in the Workspace Timezone. Every cron time Kosuke shows is in that zone too, whatever your own clock says: the next three runs, the next run, the times of past runs and the dates a project was paused. A workspace starts on UTC.
Owners and admins set it in Settings > Workspace > General, under Timezone. Picking a zone saves it. Every enabled cron's next run moves to the new zone, except a cron that is already due, which fires on its slot first. Members see the zone but cannot change it. With the CLI, run kosuke workspaces timezone-set.
Kosuke refuses a new zone when it would make a cron fire more often than every 15 minutes, or never, and names those crons. Nothing changes then. Edit those crons first, then set the zone again.
What a run does
Each fire starts one run in every project of the cron that is not paused, all at once. A cron with three projects makes three runs per fire. Each run starts the Cron Agent in its project's main sandbox and gives it the prompt word for word. The Cron Agent reads the project. It never changes the checkout, never creates a branch, and never asks a Clarification. When something is unclear, it decides and says what it assumed in its Reply. It may write Artifacts, such as an investigation or a comparison, and it hands every piece of work that needs a code change or a pull request to a chat session. It can also send a proposal to a member's Lead. See Send a proposal to a member's Lead.
A run opens no chat session of its own and does not appear on the board. You follow it on the cron's page. The sessions the Cron Agent files do appear on the board. It files them in the Backlog only, and a member starts the work. When an earlier run in the same project filed a session that is still in the Backlog, it edits that ticket instead of filing the same work twice.
Kosuke creates the sessions the Cron Agent files and is their Assignee. The member who starts one acts on GitHub in its first Turn: the commits and the pull request come from their connected GitHub account, or from Kosuke App if they have not connected one. Each session runs on the model the prompt names, or else on the cron's model. A session booked to Kosuke stays Kosuke's whoever starts it, and runs on the workspace's Credentials. It shows as unread and "waiting on you" for every member. To take it over, reassign it: from the next turn it runs on the new Assignee's credentials, with their Personal Skills and Plugins.
The Cron Agent reaches only the Project Skills in the checkout. A prompt that calls any other skill is passed, word for word, to the session it files.
Each run spends credits while the Cron Agent works, so a fire over three projects spends for three. A run acts as the cron's creator, whoever pressed Run now, but spends the workspace's Credentials. It reaches what the creator's API key reaches, except deletes, run diagnostics and their personal credentials. A run has 60 minutes and then fails.
When a cron fires while its previous run in a project is still working, the new run in that project is skipped. Its other projects run as usual.
Send a proposal to a member's Lead
A run can send a proposal to the Lead of one member. A proposal is a card in that member's Needs you, with Skip, one action and the run's one line of why. Use it for something a person must accept or reject. Every cron can do this. Your prompt only has to ask for it.
| A run can propose to | What accepting does |
|---|---|
| Delete a Backlog ticket | Deletes it. The card names the pull request or session that already did the work |
| Merge Backlog tickets | Folds them into one ticket and deletes the others |
| Create a cron | Creates it |
| Start a Backlog ticket | Starts it with /kosuke:ship |
Nothing happens until the member accepts. The action then runs as that member, with their permissions. A run never deletes a ticket, merges tickets or creates a cron itself.
Each member has their own Lead, so the run chooses one member for each proposal:
- The member your prompt names, or the one your prompt's rule picks, as in "Send every proposal to Marta."
- Otherwise the ticket's Assignee.
- Otherwise the member who filed the ticket.
- Otherwise the member who created the cron.
The card says which cron proposes it. The run's Reply lists every proposal it sent, to whom, and any that Kosuke refused. Kosuke refuses a proposal when:
- the member named is not a member of the workspace;
- that member already has an open proposal for the same ticket, or for a cron of the same name;
- the workspace already has a cron of the name proposed;
- a ticket to merge was edited after the run read it;
- the member is not idle, for a proposal to start a ticket;
- the ticket is assigned to another member, for a proposal to start it;
- the workspace has no Lead. The Lead is in Beta, and Kosuke turns it on for a workspace.
A run does not retry a refused proposal. The next run can send it again.
Triage the Backlog with a cron
Backlog triage is a cron you create. Copy this prompt into a new cron, pick the projects to groom, and pick the Hourly frequency:
Triage the Backlog of this project.
1. Groom the Backlog sessions. Set a priority that is missing or wrong, and
add or remove Session Labels. Do this directly, and only when you can give
a reason. Name each change and its reason in your report.
2. Read the code each ticket is about, so you judge it from the repository
and not from its title.
3. Compare the Backlog with what merged. When a pull request or a session
already did what a ticket asks, send a delete_ticket proposal with that
pull request or session as the evidence.
4. When several tickets ask for the same thing, send one merge_tickets
proposal that keeps the clearest ticket and holds what all of them say.
5. When the same chore keeps coming back as a ticket, send a create_cron
proposal for it.
Change nothing else. When there is nothing to do, say so in one line.
The prompt names only the task. The Cron Agent already knows the commands and how to choose the member for each proposal. Add a line such as "Send every proposal to Marta." to choose yourself.
What to know before you rely on it:
- The run sets priority and labels itself, as the cron's creator. Both are cheap to undo. Each change is in the run's Reply, not in anyone's Lead chat.
- A run works in one project. Save the cron with every project it should groom.
- It fires on its crontab whether or not anything changed, and every run spends the workspace's credits. Pick a slower schedule for a quiet Backlog. The fastest is every 15 minutes.
- Deletes, merges and new crons wait for a member to accept them.
Follow a cron and its runs
The Crons page lists every cron in the workspace, with its projects, schedule, model, next run and status. The Projects column shows the first project and +2 for two more. Hover it to see them all. You can search by name or prompt and filter by project, which keeps every cron that includes it.
| Status | What it means |
|---|---|
| Enabled | The cron fires on schedule |
| Last run failed | The cron is on, and the latest run in at least one of its projects failed |
| Paused | A member paused it |
| Disabled | The cron turned itself off. Its page says why |
A cron with paused projects also shows a badge such as "2 projects paused". Its other projects keep firing. See When a project is paused.
Select a cron to open its page. It shows the next run, the projects, the model, who created it, the schedule with the Workspace Timezone, and the prompt. On the Runs tab, each run has a summary, its project, a status, a duration and the time it ran.
Two filters on the Runs tab narrow the list. All projects keeps the runs of the projects you tick, and All statuses keeps the runs with the statuses you tick. Press Clear to show every run again.
| Run status | What it means |
|---|---|
| Running | The Cron Agent is working |
| Succeeded | The Cron Agent finished. The summary is the first line of its Reply |
| Failed | The run could not start, the Cron Agent failed or ran out of time, or a deploy replaced the main sandbox under it. The summary gives the reason |
| Cancelled | The cron's creator or a workspace admin stopped the run |
| Skipped | The previous run in that project was still in progress, or another fire of the cron was already starting, so nothing started |
Select a run to open its page. It shows the Cron Agent's transcript, its Reply, the Artifacts it wrote and, under Sessions it filed, each session with its status and whether it waits for an answer. It also shows the project, the model and how long the run took. A run that failed shows the reason under Run failed. In the Runs tab, a skipped run has no link to open and no transcript, because nothing started.
To stop a run that is still going, press Stop on its page. The run ends as Cancelled. Its Artifacts and the sessions it already filed stay.
Cron runs that succeed or fail also appear in Activity. See Home, Needs you and Activity.
Why a run fails to start
| Reason on the run | What to do |
|---|---|
| No workspace AI provider is configured. | Ask an admin to connect workspace Credentials |
| The project has not completed its first deploy. | Deploy the project |
| A deploy was in progress. | Wait for the deploy. The next fire tries again |
| Credit limit reached | See Plans and billing |
| The main sandbox could not be reached. | Check the project's preview, then wait for the next fire. See Preview and sandboxes |
| No AI model is available for this cron. | Edit the cron and pick a model the workspace can run |
When a project is paused
A project is paused inside the cron after 5 failed runs in a row there. Every failed run counts, except one that failed because a deploy replaced the main sandbox under it. Only a run that succeeds sets the count back to zero. A cancelled or skipped run leaves the count alone. Each project keeps its own count.
A paused project gets no scheduled runs. The cron's other projects keep firing. On the cron's page, the paused project's chip is marked Paused.
To resume a paused project:
- On the cron's page, select the paused project's chip. It says since when the project is paused and the error that paused it.
- Press View failed runs to see that project's failed runs on the Runs tab.
- Fix the cause, then press Resume, which names the project.
The project takes part in the next fire, and its count starts again from zero.
When every project is paused, the cron disables itself. Its page reads "Every project is paused after 5 failed runs in a row." Resuming one project turns the cron back on. Resume on the cron itself resumes every project. Saving an edit also clears every pause, but a cron that turned itself off stays off until you press Resume.
When a project is deleted
Deleting a project removes it from every cron that includes it, along with the runs made in it. The cron's other projects keep firing. A cron whose last project is deleted stays, disabled, and its page reads "No projects left". Edit it, pick at least one project and press Save. Then press Resume.
Pause, resume, run now, edit or delete
On the cron's page, use the buttons in the header. In the list, open the menu at the end of the row.
- Pause stops the schedule. Resume schedules the next run and resumes every paused project.
- Run now fires the cron once, paused or not, exactly as a scheduled fire would. It runs in every project that is not paused.
- To run in only some projects, open the arrow beside Run now, or Run on some projects… in the list's menu. Tick the projects, then press the button, such as Run on 2 projects. You can tick a paused project to run it once. It stays paused.
- Edit opens the same dialog, where you can also change the projects. Press Save to keep your changes. Saving clears every paused project.
- Share copies the link to the cron's page. On the cron's page it is the icon button before Pause. The link opens for signed-in members of the cron's workspace.
- Delete asks you to confirm. The schedule stops, and its runs, their transcripts and their Artifacts are removed with it. The sessions its runs filed stay.
Any member can read every cron and its runs, and share its link. Only the cron's creator or a workspace admin can edit, pause, resume, run, resume a project of, stop a run of, or delete it. For everyone else, Edit, Pause, Resume, Run now and Delete are greyed out, and Stop and a paused project's Resume are not shown.
Whose credentials a run spends
Every run spends the workspace's Credentials, never a member's Subscription. So does every session the Cron Agent files, whoever starts it, until a member reassigns it to someone. A cron keeps firing after its creator leaves the workspace. If the workspace loses its Credentials, each run fails with "No workspace AI provider is configured." See AI providers for whose credentials run what.
Limits
- A crontab may not fire more often than every 15 minutes.
- A cron needs at least one project.
- A session the Cron Agent files runs on the workspace's Credentials until a member reassigns it to someone.
- The agent inside a chat session acts as the session's Assignee, when the Assignee sent the turn. It can create, change, run and stop crons as they could, but never delete one.
- A run proposes a delete, a merge or a new cron. It never does one itself.
To create and manage crons from a script, see Schedule recurring work.