Docs / Getting started

Pipelines, jobs and the command chat

Everything FrameBuff does runs as a job. A job is one run of a pipeline, and a pipeline is a list of tool calls.

Pipelines

A pipeline is a straight list of steps with no branching. Each step calls one tool with its arguments. A step can use what an earlier step returned: write $1.out to pass step 1's output into a later step, or $1.out.name to take one field of it.

You build pipelines on the Pipelines page. Before a job starts, FrameBuff checks the steps: every tool must exist, every required argument must be there, and a step can only use the output of a step that comes before it.

A saved pipeline never stores a password or a key. Arguments marked as secret are left out when the pipeline is saved.

Jobs

Each run is a job on the Jobs page, with its steps, its log lines and its outcome. Installs, model servers, scheduled backups and renders are all jobs, so you watch and stop them all in the same place.

When the machine is busy, a job waits and says why on its page, for example waiting: CPU busy (82%). It starts by itself, oldest first, when the reason is gone. Jobs that touch different things can run side by side while there is CPU and memory to spare. A job that installs software runs alone.

Jobs that were queued or running when a core stopped are marked failed with "core restarted mid-run", so you can see what to run again.

Spreading work over several machines

One step can split its input into parts, run the same steps on every part, spread the parts over several machines and gather the results in order. If a part is lost on one machine, another machine takes it. The step fails only when no machine that could take the part managed to finish it.

Schedules and triggers

FrameBuff has one engine for everything that runs by itself. A trigger is either a clock (once, daily, weekly or every few hours) or an event, such as a file landing, a job finishing or one of your machines coming online. The action is a pipeline or a tool. Every firing is a job on the Jobs page.

• A clock entry can have a window. A run that comes due outside its window waits for it to open and never starts late.
• A run that came due while the core was off starts once at start-up if its window is still open. Otherwise it is skipped, and you get one notice.
• An action that posts or sends something online, spends money, deletes or uses an online service always asks you first. An unattended run cannot ask, so the schedule refuses to run it and warns you.
• Modules bring their own timed work, such as a backup every few hours. You can change the timing or turn any entry off on the Schedule page.

The command chat

The command chat is the box in the right bar. You type a command and the core does it. It follows fixed rules and uses no AI model, so the same line always does the same thing. Type help for the list.

status
pipelines
run Nightly backup
jobs
cancel <job id>
tools files
modules
logs 50

A line that names something FrameBuff can make runs the tool that makes it. generate image of a cat asks the default image tool. Add with and a name at the end to pick another one. The work runs as a job.

The command line sends the same commands to a running core, so framebuff status in a terminal answers the same as status in the chat.

The command chat is separate from the Companion, which is the conversation with an AI model. See Agents and approvals.