Develop

Mobius CLI

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: create an agent, read a conversation, pause a routine, see what it did.

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 agents list
mobius sessions get ses_8q5m2x9v7p3n4r6t
mobius routines pause rtn_9q2m7x5v3p8n4r6t

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 routines --help
mobius routines list-occurrences --help

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

Options every command takes

OptionWhat it does
--profile <name>Which saved login, if you have several.
--api-key <key>Sign in with an API key instead of your login. In scripts, set MOBIUS_API_KEY and leave this off.
--api-url <url>Point at a different Mobius. You'll rarely need this.
--output <format>, -oauto, pretty, json, yaml, or text.
--fields <list>, -FShow only the fields you name.
--quiet, -qSay nothing when it works. Errors still print.
--log-level <level>debug, info, warn, or error.

Every one of these also reads from an environment variable, so you can set it once instead of typing it on every command:

export MOBIUS_PROFILE=ridgeline
export MOBIUS_OUTPUT=json

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 routines list --output json

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

A worked example

Say a morning routine hasn't posted its summary and you want to know why.

Find it first. --fields trims the answer down to the parts you asked for:

mobius routines list \
  --fields id,name,status,next_fire_at \
  --output json
{
  "items": [
    {
      "id": "rtn_9q2m7x5v3p8n4r6t",
      "name": "Morning brief",
      "status": "paused",
      "next_fire_at": null
    }
  ],
  "has_more": false
}

paused explains the silence. Before resuming it, read what the last few occurrences did:

mobius routines list-occurrences rtn_9q2m7x5v3p8n4r6t \
  --fields scheduled_for,status \
  --output json
{
  "items": [
    { "scheduled_for": "2026-08-30T08:00:00Z", "status": "failed" },
    { "scheduled_for": "2026-08-29T08:00:00Z", "status": "completed" }
  ],
  "has_more": false
}

Then read the failed turn itself in the routine's conversation, which is where the error text is:

mobius sessions get <session-id>

Fix the cause, then put it back on its schedule:

mobius routines resume rtn_9q2m7x5v3p8n4r6t

For watching an agent work as it happens, the app is better. Use the CLI when something else needs to read the answer.

Next