Multi-tab workflow

Open Interpreter is built for developers who keep several terminal tabs open against the same project. One tab drives the feature. The others run tests, scan for bugs, draft docs, or explore a refactor — in parallel.

The pattern

Open your project in your terminal. Open three or four tabs. Run interpreter in each. Each tab is an independent agent with its own model, approval policy, and conversation history. They all see the same filesystem.

# tab 1
$ cd my-project && interpreter
> work on the auth refactor in src/auth

# tab 2
$ cd my-project && interpreter
> run pnpm test --watch and tell me when something breaks

# tab 3
$ cd my-project && interpreter
> scan the repo for TODOs related to auth and summarize them

Why it works

Tabs share the project's filesystem. When tab 1 edits a file, tab 2 and tab 3 see the new version on their next read. That makes parallel work on a single repo realistic: the feature tab does the edits, the test tab notices the failures, the scan tab pulls the next chunk of context.

Tabs do not share session state. Each tab has its own model, its own approval state, and its own transcript. You can run a cheap fast model in your scan tab and a stronger model in your feature tab without either bleeding into the other.

A worked example

You're refactoring auth.

• Tab 1 — feature-auth. Strong model, workspace-write sandbox, on-request approvals. You drive the change here.
• Tab 2 — tests. A lighter model running pnpm test --watch with an agent watching the output. When something breaks, it summarizes the failure for you.
• Tab 3 — scan. Cheap model, read-only sandbox. You ask it things like "find every place that calls verifyToken and tell me which ones still use the old shape."

Each tab stays focused on its job. When you commit, you read /diff in tab 1 and ship.

Slash commands that help

• /model — switch the model or profile in this tab. Use a stronger model for the active feature tab, a cheaper one for scan tabs.
• /resume — pick up a prior session in this tab. Useful when you come back to a tab after lunch.
• /diff — see what's changed in the working tree before you commit from the feature tab.
• /permissions — change the approval policy for this tab without touching the others.

Anti-patterns

• Don't run two agents editing the same file simultaneously. They will race. Keep edits to one tab per area of the code.
• Don't expect tab 2 to know what tab 1 said. They're independent conversations. If tab 2 needs context from tab 1, paste it in.
• Don't share one approval policy across tabs you don't trust equally. Run scan tabs in read-only. Save workspace-write and never for tabs you're watching.

Tips for keeping tabs sane

• Name your terminal tabs by intent. feature-auth, tests, scan. Most terminals let you rename tabs with a keystroke (Cmd-Shift-I in iTerm2, Cmd-I in macOS Terminal).
• Use /resume --last when you come back to a tab after a break. The conversation, files, and context come right back.
• Pick the right model per tab. Cheap for scans, fast for tests, strong for the feature. Switch any time with /model.

Next