Goals and scheduled tasks

Goals

A goal keeps the team working in a series of ordinary runs until real checks say it is true, or a limit says stop. Type /goal followed by what should be true, for example /goal make the tests pass, or pick it from the / menu.

The start screen

Nothing runs until you press Start working. The screen lists how “done” will be decided, built from what you wrote:

• A sentence a check can answer: “the tests pass”, “README.md mentions install”, “the page has a button”, “there are no console errors”.
• A command in backticks, or run <command>, that must exit successfully.
• [ ] item or checklist: item for things the team must prove.
• Anything else is shown as No check can confirm: …. It is passed to the team as a requirement but never counts as met.

You can list several criteria after all of:, one per line or separated by ;. The limits are shown and editable: number of runs (default 8), time (30 minutes), money (a default of $2 when the model has a price) and tokens (optional). A goal always has a run limit and a time limit. At 80% of a limit a warning appears; at 100% it stops. It also stops when the same things are still failing three runs in a row.

While it works

• A goal bar above the message box shows the state, how many criteria are met, the run number, and Pause, Resume and Stop.
• A goal card in the conversation lists every criterion as met, not met or “claimed, not checked”, with the evidence behind it.
• Closing the app pauses the goal. It comes back as “paused (the app was closed)” and waits for Resume. A provider outage pauses it and it resumes by itself when the provider says when.

Honesty

A criterion is met only from a check that really ran after the run. When the team says a checklist item is done, it shows as “claimed, not checked” and does not count. A goal ends “Done: checked” only when every criterion is met. At the end a Goal result document lists each criterion with its evidence and what was used.

Scheduled tasks

The clock icon on the left rail opens Scheduled tasks. A task runs on a schedule and reports to an inbox.

• When: hourly, daily, weekly (choose the days), monthly or a custom cron expression, in a time zone you choose. The editor describes the schedule in words and shows the next few times.
• What: a name, the task text, the project, the team and the model.
• Where it works: Only look at the project, or Work in an isolated copy. The second is the only way to let a task change files, and it appears when a copy can be made. See Isolated copies.
• Allowing it: you allow each task explicitly. If the task changes afterwards, the allowance goes stale and the card shows Needs your OK.
• Quick chats cannot be scheduled. Save the chat as a project first.

The inbox

Runs are listed newest first with a status (Done, Failed, Stopped, Stopped at its limit, Did not start), when, how long, the cost and the run’s own summary. Open goes to the conversation and its walkthrough. A run that worked in an isolated copy also shows Apply and Discard. A run never applies by itself. A number on the rail icon and in the title bar counts results nobody has read.

Run even when Maxtkn is closed

The editor has a collapsed section that shows the task as a command for your computer’s own scheduler: Windows schtasks, a macOS launchd snippet or a Linux crontab line, with a Copy button. It runs the maxtkn command line with the task’s project, request, team, model and time limit. It never contains a key, only the name of the environment variable that holds it. A run started that way does not appear in the app’s inbox; its log is written to .maxtkn/runs in the project.

The generated commands are produced and tested as text. They have not been run in the macOS or Windows task schedulers, so try one with a harmless task first.