The problem with asking one model to do everything at once
There's a particular kind of frustration that comes from pasting a large, multi-part task into a single AI prompt and watching it confidently do 70% of it before quietly forgetting the rest. You asked it to write the models, the routes, the middleware, and the tests. It nailed the models. The tests are half-baked. The middleware is missing entirely. You didn't notice until you ran the thing.
The root issue isn't the model — it's the context window getting stretched, attention diffusing, and a single thread of reasoning trying to hold too many concerns at once. One agent, one pass, one point of failure.
That's the problem /multi is built to fix.
What /multi actually does
/multi landed in lac-cli v0.3.6. When you run it inside lac agent, it takes your task description and splits the work across 2–4 specialized sub-agents that run in parallel. Each agent gets a focused slice of the problem — one might own data modeling, another the API layer, another validation logic. They work concurrently, not sequentially.
Once the agents finish their slices, a Project Manager agent reviews all the output together. It checks for consistency — are the model field names referenced correctly in the routes? Does the middleware actually wire up? — and synthesizes everything into a final summary. If something doesn't hold together, the PM can trigger retries, up to three rounds, before it hands you the result.
That review layer is what makes this different from just running four separate prompts yourself. You'd spend more time reconciling the outputs than you saved by splitting the work.
Running it
First, make sure you're on v0.3.6 or later:
pip install --upgrade lac-cliOr if you used the install script:
curl -fsSL https://lacai.io/install.sh | bashThen start the agent in your project directory:
lac agentOnce you're in the agent shell, type /multi followed by your task. Something like:
/multi Build a user authentication module: JWT-based login and register endpoints, bcrypt password hashing, auth middleware, and input validation. Express + Mongoose.The agent will confirm how it's splitting the work and how many sub-agents it's spinning up. You'll see them working in parallel — output streams in as each one finishes its slice. The PM review kicks in automatically afterward.
If the final result isn't what you wanted, or something went wrong mid-session, /undo reverts the entire /multi session. Not just the last file — the whole thing. That's important. Partial reverts on multi-file generations are a nightmare to do manually.
Choosing how many agents
You can specify the agent count directly — between 2 and 4. If you don't specify, /multi picks based on how it reads the complexity of your task description. I've found that leaving it to decide works well for most cases. Where I do manually set it is on smaller tasks where I know two focused agents is cleaner than four half-loaded ones.
The split isn't random. The system reads your task and tries to carve it along natural seams — concerns that are mostly independent of each other. A task like "build CRUD routes and write unit tests" splits cleanly. A task like "refactor this function" probably doesn't need /multi at all — just use lac agent directly.
Project memory still applies
One thing worth knowing: the agents in a /multi session still have access to your project's .lac-memory.json. That's the file lac agent builds up as you work — it tracks your stack, conventions, file structure, things you've told it about your project. The sub-agents read that context, so they're not starting cold.
If you're on a project where you've been using lac agent for a while, that memory file is doing real work. The sub-agents inherit the project's personality, so to speak. They know you're using ESM imports, or that you prefix all your environment variables a certain way, or that your error handler lives in a specific utility file.
If you're starting fresh and the memory file doesn't exist yet, spend a few minutes with lac agent before reaching for /multi. Give it some context first. It pays off.
When to use it (and when not to)
/multi shines on tasks that have clearly separable concerns and a meaningful amount of code to produce. Feature slices, new modules, generating a full API layer from a spec — these are good candidates. The overhead of spinning up multiple agents and running the PM review is worth it when the task is big enough that a single agent would struggle to hold all of it in focus.
It's overkill for small targeted edits. If you're fixing a bug or tweaking a function, just use lac agent normally. /multi isn't faster for small tasks — it's slower. Use it when scope is the problem.
It also pairs well with /watch (also in lac-cli). If you're debugging a flow in the browser and you capture a full session timeline with /watch, you can hit "Send to AI" to get the timeline into the agent, and then use /multi to split the fix across the affected layers — say, frontend input handling, backend validation, and database query — all at once.
Provider notes
Each sub-agent uses whatever provider you've configured in ~/.lac/config.json. If you're on Claude or OpenAI, you'll burn through tokens faster with parallel agents — that's just math. If you're running Ollama locally, /multi works offline just fine, though the speed depends heavily on your hardware. I run a lot of my local testing through Ollama specifically so I don't have to think about API costs while I'm iterating.
You can check or update your provider config any time:
cat ~/.lac/config.jsonA practical starting point
If you want to try /multi today without risking an active project, create a throwaway directory and let it generate something from scratch:
mkdir test-multi && cd test-multi
lac agentThen inside the agent shell:
/multi Build a basic REST API for a task management app. Endpoints for creating, listing, updating, and deleting tasks. Express, in-memory store, input validation with express-validator.Watch how it splits the work, watch the PM review step, and check the files it produces. That hands-on pass will tell you more about when and how to reach for it than any amount of documentation.
The full lac-cli docs and install instructions are at /lac-cli. It's MIT licensed and open source, so you can read exactly what the agents are doing if you're curious about the internals.