Skip to main content

Baby steps: discover lmctl one step at a time

You don't have to adopt lmctl all at once. Each step below adds value on its own, with almost no commitment — you can stop at any rung and still come out ahead. This is the gentle path for developers who already live in a native AI CLI.

Step 1 — Just look at your sessions (≈1% of lmctl)

You already use a native AI CLI — Claude Code, Codex, Gemini, and so on. Without writing a teamfile or changing anything, lmctl can give you one read-only window over all of those sessions. You don't even have to install it — try it with npx (needs Node 24.15+):

npx @lmctl-ai/lmctl ls # no install — list your sessions across providers

Or, once installed (npm install -g @lmctl-ai/lmctl):

lmctl ls # list native provider sessions, across providers
lmctl health <sessionid> --provider codex # one session's state + token usage
lmctl tail --session <id> --provider codex # read its messages

lmctl ls prints one line per session, across Claude, Codex, Gemini, and the rest — in one place. That's it: you've used lmctl. No setup, no lock-in, just a better lens on the sessions you already have. (lmctl ls --runs shows lmctl's own runs instead, once you have any.)

Planned screencast“that’s MY data”Show lmctl ls lighting up real sessions across Claude, Codex, and other providers.
Future asset path: /assets/screencasts/my-data.mp4

Step 2 — Give sessions human-friendly names

Raw sessionids are cryptic. Here's the nice part: lmctl ls already prints _MEMBER_ lines in teamfile format, so you don't write a teamfile from scratch — you paste its output into a .lmctl file and just fill in alias=:

_MEMBER_ alias=Coder provider=codex
_MEMBER_ alias=Reviewer provider=claude

Then seed it so lmctl captures (or confirms) each underlying session:

lmctl seed ./team.lmctl # starts each provider once, captures the session id
lmctl tail ./team.lmctl Coder # now address by alias, not a cryptic id
lmctl health ./team.lmctl Reviewer

Now you work with names — Coder, Reviewer — instead of copying sessionids around. See Concepts & glossary for the teamfile format.

If your _MEMBER_ lines include model=, verify the routed model immediately after seed:

lmctl health ./team.lmctl

The MODEL column should match the teamfile. Use @lmctl-ai/lmctl 0.1.151 or newer for model-routed teams; this tutorial was checked against 0.1.218.

Step 3 — Stop copy-pasting between sessions

The usual chore: a Coder makes a change, and you hand-copy it into a Reviewer's chat. Let the Lead do that routing for you — message a member and the Lead relays the relevant context:

lmctl chat ./team.lmctl Reviewer "Review Coder's latest change and flag anything risky."

The first member in the teamfile is the Lead; it talks to its members, and can even reach members of other teams — automatically, at runtime, with built-in cycle protection. You've gone from "two chat windows I shuttle text between" to "a team that hands work off for me." And because the Reviewer is a different provider and model than the Coder, that review is genuinely independent — see Adversarial review.

Step 4 — Capture the pattern, and keep its memory

Once a back-and-forth stabilizes, write it down as Lead instructions and add durable-memory so the team's knowledge survives fresh sessions, provider swaps, and moving the repo to a new folder. The current public model is teamfile + members + lmctl chat; repeatability comes from the prompt you give the Lead and the project facts committed under durable-memory/.

Read why this scales to long work in Context & durable memory.


Each rung is independently useful. Look → name → route → capture: adopt exactly as much lmctl as pays for itself, and no more.