Scheduler configuration¶

This page describes global scheduler settings and routine configuration.

Configuration¶

Axe is configured in sase.yml under the axe: section. Keys, types, and defaults are on the generated scheduler configuration page; behavior notes are on AXE configuration behavior.

Moved to Scheduler description grammar. Moved to Scheduler jobs. Moved to Scheduler jobs. Moved to Scheduler jobs. Moved to Scheduler jobs. Moved to Scheduler jobs.

Global Settings¶

The query setting uses the same Patch query language as sase's TUI. CLI flags on sase scheduler run and sase axe routine run override the configured query, runner limits, and zombie timeout for that process.

Routine Configuration¶

axe:
  routines:
    my_routine:
      description: |-
        Run project-scoped custom checks once a minute

        Use this lane for inexpensive checks that should react within a minute. Individual jobs may use run_every to
        reduce their own cadence; long-running maintenance and high-frequency lifecycle checks belong in separate
        routines.
      interval: 60 # Seconds between cycles
      job_timeout: "60s" # Default timeout for all jobs in this routine
      wait_runners: 1 # Emitted as %queue(capacity=1): lane agents run alone
      env: # Inherited by every job; individual job env wins
        API_TOKEN: { env: MY_API_TOKEN }
      jobs:
        my_job:
          script: my_job_executable # Optional; defaults to name
          description: |-
            Run a custom validation after meaningful repository changes

            Creates one instance per enabled Git or GitHub project and runs at most once every 1h30m after ten new
            commits. A successful action advances the trigger checkpoint; an active toobig agent clan inhibits the
            check, and the per-job timeout limits each run to 30 seconds.
          run_every: "1h30m" # Run at most once per compound duration
          timeout: "30s" # Per-job timeout (overrides job_timeout)
          env:
            MY_VAR: "value" # Custom environment variables
          inhibit_if:
            agent_clan: { name_prefix: toobig- }
          trigger:
            git.commits_since:
              project: "{target.name}"
              threshold: 10
              checkpoint: on_action_success
          once_per: "{target.name}:{proposal.id}"
          for_each:
            source: projects # One stable my_job[project] instance per enabled project
            vcs: [git, gh]

Every routine requires a description explaining the lane's cadence and the class of work it owns, and every job requires one explaining what that job does. Both follow the summary/body grammar in Description Grammar.

Routine Fields¶

Routine field names, types, and defaults are on the generated scheduler configuration page.

wait_runners applies only to agents emitted through a script job's proposed_launches; it does not gate mentor, hook, or CRS workflow launchers. The runner prepends it to each proposed prompt as %queue(capacity=N) unless the prompt already authors its own %queue capacity, so it follows the per-launch capacity budget rules: the agent starts when the occupied weighted load plus its own weight fits within N, and 1 makes a default-weight lane agent run alone. N must be at least 1; wait_runners: 0 produces a %queue(capacity=0) that is rejected at launch. When a job proposes a clan, every member carries the budget and waits independently, so a low budget can serialize the clan.

Job Fields¶

Job field names, types, and defaults are on the generated scheduler configuration page. inhibit_if.changespec remains accepted as an alias of inhibit_if.patch.

Map-form jobs compose by identity across config layers. A higher-priority layer can patch a single field or set enabled: false while retaining the rest of a packaged entry. Object-list form remains accepted, but bare-string list entries are invalid because they cannot provide the required description. Target instances use names such as my_job[sase-core], with independent cadence, run history, checkpoints, and dedupe state. Literal targets may include an overrides: object for per-target fields such as run_every; the projects source accepts name/names and vcs filters.

Configuration is validated fail-closed. Unknown fields, duplicate job identities, and invalid or non-positive durations produce actionable errors with their config paths. Secret references resolve at dispatch and fail closed with provider-specific diagnostics. Scheduled agent work must originate from a script's structured launch proposals; agent: and macro: job fields are rejected. See Automation migration notes.

_[project]: A sase project is a named unit of work registered with SASE. _[workspace]: A sase workspace is a numbered clone of a project's primary repo, managed by the workspace store and tracked in that project's registry.json. _[agent]: A sase agent is an agent session or a single agent that does not belong to a session. _[prompt]: A prompt is the text SASE hands to a provider to start an agent turn. _[macro]: A macro is a reusable prompt triggered with #name in agent prompts. _[Patch]: A Patch is SASE's local unit of change. _[bead]: A bead is one tracked work item in SASE's git-native issue tracker. _[plan]: A plan is a persisted, approved artifact recording the intent behind agent work. _[TUI]: The TUI is SASE's terminal interface for running agents and reviewing results. _[epic]: An epic is an executable multi-phase plan run with sase bead work. _[gate]: A sase gate is a durable, command-backed request for one user decision, created when work must pause for the user. _[monitor]: A sase monitor is a monitor turn that runs one long command under a detached supervisor, so the command outlives the agent that started it. *[stitch]: A stitch is the lightweight ordered change record inside a Patch's STITCHES: section.