CLI and dashboard¶
Autolab gives you two surfaces over the same account:
- the CLI, where you write code, start climbs, submit experiments, attach compute, and change settings;
- the dashboard at app.autolab.ai, where you watch it happen: live run logs, metric curves, the agent's analysis, and a chat with the agent.
Neither replaces the other. A normal session is to work in the terminal and keep the climb's dashboard page open in a browser tab.
The terminal is not a progress feed
autolab commands return as soon as the control node has accepted the
request. They do not stream the experiment, and nothing more will print. If
your terminal has gone quiet after start or serve, that is success, not a
hang. Run output, metrics, and the agent's reasoning are on the dashboard.
The sidebar: the hub¶
The dashboard's left nav is the hub, and most of it has no CLI equivalent because browsing and curation are the browser's job:
| Sidebar | What it is | Nearest CLI |
|---|---|---|
| Explore | the Hills and Lists tabs, search, tags, stars | autolab hills (list only) |
| Climbs | your climbs and their state | autolab projects |
| Compute | your nodes, live usage, and the rental catalog | autolab nodes, autolab compute |
| Profile | your public page: hills, lists, climbs, activity | browser only |
| Credits | balance and spend on your Autolab key | browser only |
Search (Ctrl/Cmd+K) |
jump to any hill, list, person, or climb | browser only |
Organize your climbs¶
Each climb shows its hill's full name. Click the hill name to open its overview, or the climb title to open the climb. Older climbs without a hill show No hill attached.
Choose Cards for a grid or List for rows. Group by hill keeps attempts on the same hill together; choose No grouping to see one collection. Search by climb name or hill name. Use All, Running, Needs input or Stopped to narrow the results. Running includes climbs that are stopping after their current runs. Your view and filters stay in the URL and are remembered between visits. Counts reflect the current search.
When grouped by hill:
- Recent puts the hill with the most recently active climb first, then orders that hill's climbs by activity. A climb without runs uses its creation time.
- Created orders groups by their newest climb and members by creation time.
- Most runs orders groups by their busiest individual climb, then members by run count.
- Name orders hill names and the climbs within each hill alphabetically.
The No hill attached group stays last. Search and status filters apply before these groups are ordered. Vs baseline shows the percentage change from the baseline; whether a positive or negative change is better depends on the hill.
Requests do not override your selected sort. Cards show current activity or the reason a climb needs input, instead of its original description. Goal reached is a successful result and does not appear under Needs input. The orange Climbs badge in the sidebar counts your own climbs needing input and also excludes goals reached.
If you manage a climb, click Respond to read and answer its request directly on the card. Reply & resume sends your guidance and resumes research; Resume climb continues without a reply. Keep stopped stops the climb and keeps its history. Running experiments finish, but their results wait for you and are analyzed when you resume. The question stays on the climb until you resume. Reply drafts survive filter and view changes while you stay on the Climbs page. If a request changes while you are replying, review the new request before submitting.
Admin credit controls¶
Platform admins can open Admin > Users, select a user, and toggle Unlimited credits. Turning it off restores the previous finite limit, or recorded spend if that is higher. Each climb's own spending cap still applies. If a save fails, the page keeps its controls available and shows an inline error. The unlimited toggle returns to its saved value so you can retry.
Open a climb¶
autolab open # this climb's dashboard page
autolab open <id> # one experiment: its live logs, metrics, diff, and analysis
init, start, submit, and status each print the climb's URL,
https://app.autolab.ai/projects/<owner>/<slug>, as does serve once it
backgrounds the node. That link is the dashboard.
Inside a climb¶
| Climb page | What it is for | Nearest CLI |
|---|---|---|
| Overview | climb and agent state, active runs and deep research, metric trend | autolab status |
| Chat | ask the agent about results, steer it, queue work in words | browser only |
| Jobs | every experiment and deep research job; open one for logs, metrics, diff, analysis, or a research report | autolab log (list only), autolab research list |
| Graph | the lineage tree: what branched from what | autolab graph |
| Code | browse any experiment's code, or compare two | autolab checkout, autolab diff |
| Nodes | attached machines, health, rentals, and each node's log | autolab nodes |
| Memory | what AutoLab knows, memories from people, research reports | autolab memory |
| Log | the climb's event stream: state changes, decisions, errors | browser only |
| Settings | name, description, credits, cost cap, compute, collaborators | autolab settings |
The rule of thumb: the CLI changes things, the dashboard shows things. Anything that produces output over time, a run, an analysis, an agent conversation, is read in the browser.
Which log is which¶
Several different things are called a "log", and this is the most common source of confusion:
| Where | What it is |
|---|---|
autolab log (CLI) |
History, not output. One line per experiment, like git log. |
| Job page → Logs → Run (browser) | Your experiment's stdout and stderr, streaming live. |
| Job page → Logs → Setup (browser) | Environment prep, such as uv sync, before the run. |
| Job page → Agent Activity (browser) | What the agent did on this experiment, step by step. |
autolab serve log (CLI) or node page → Node Log |
The machine's narration: registration, accepted jobs, failures. Not your run's output. |
| Climb → Log tab (browser) | Climb-level events across all experiments. |
No CLI command prints an experiment's run output. Use autolab open <id>.
A typical loop¶
autolab status # where things stand
autolab submit -m "…" # queue an experiment (prints the climb link)
autolab open <id> # watch it in the browser: logs, metric, verdict
Between those, the agent is working on the dashboard side: coding, running, analyzing, and merging what improves the hill's metric. Ask it what it is doing in Chat, or steer it from the CLI. See Drive the agent.
Next: Run experiments for the submit/diff/checkout loop, or Compute to attach what makes any of it run.