Develop

mobius is a program you install on a computer and run by typing commands. Anything you can do in the app, you can do by typing it instead: list the runs, start one, read what happened, create an agent.

It's one file. No runtime to install, nothing to configure beyond signing in once.

You may not need this

The app does everything. If you're building your first agent, or your third, stay in the app. Come back here when one of these is true.

You need a worker. This is the big one for MSPs. A worker is a copy of mobius you leave running on a machine, and it's how Mobius reaches things that can't be reached from the internet: a server inside a client's network, a tool with no public API, a script only your box can run. There's no way to do this from the app, because the whole point is that it runs on your hardware.

You're doing the same thing forty times. Adding one client is a nice afternoon in the app. Adding forty is a loop in a shell script.

You want it in a scheduled task or a pipeline. Anything that has to run without a person present.

What a command looks like

Every command names a thing, then what to do with it:

mobius <thing> <do-what> [options]

Which reads about how you'd say it out loud:

mobius loops list
mobius runs get run_8q5m2x9v7p3n4r6t
mobius agents list

Add --help anywhere and it tells you what's available at that point. This is the fastest way to find anything, and it always matches the version you have installed:

mobius --help
mobius runs --help
mobius runs start --help

The command reference lists every group and what it's for.

Options every command takes

Every one of these also reads from an environment variable, so you can set your project once instead of typing it forty times:

export MOBIUS_PROJECT=ridgeline

How output is formatted

By default, mobius prints a readable table when you're watching, and JSON when the output is going into another program. It works out which is which.

That's convenient and it's a trap in scripts. If something is going to read the output, say so:

mobius runs list --output json

Now a future change to the readable format can't quietly break your script.

A worked example

Say you have the ticket triage loop from the guide and you want to start it by hand.

Find it first. Runs are started by loop ID, not by name. --fields trims the answer down to the parts you asked for:

mobius loops list \
  --project ridgeline \
  --fields id,name,status \
  --output json

{
  "items": [
    {
      "id": "loop_9q2m7x5v3p8n4r6t",
      "name": "Triage tickets",
      "status": "active"
    }
  ],
  "has_more": false
}

Start it:

mobius runs start loop_9q2m7x5v3p8n4r6t \
  --project ridgeline \
  --fields id,loop_name,status \
  --output json

{
  "id": "run_8q5m2x9v7p3n4r6t",
  "loop_name": "Triage tickets",
  "status": "queued"
}

queued means Mobius has it and hasn't started yet. That's normal and usually brief.

See what it did:

mobius runs list-events run_8q5m2x9v7p3n4r6t \
  --project ridgeline \
  --fields sequence,event_type \
  --output json

{
  "items": [
    { "sequence": 1, "event_type": "run.started" },
    { "sequence": 2, "event_type": "step.started" }
  ],
  "has_more": false
}

Every event has a sequence number that only goes up. To poll for new ones without re-reading everything, pass the last number you saw as --after-sequence.

For watching a run as it happens, the run page in the app is better. Use the CLI when something else needs to read the answer.

Next

• Install it and sign in, on your machine or in a pipeline.
• Find the command you want in the command reference.
• Set up a worker, the main reason to be here.
• Have your own software call Mobius instead: the API introduction.