Treating Claude Code Like a Teammate: Developing with Multica
Table of Contents
Running Claude Code in a terminal works great for one task at a time. You open a session, describe what you want, watch it work, review the diff. But once you start juggling several tasks — a bug fix here, a refactor there, a small feature waiting in the backlog — the terminal stops being the right place to manage that work. You end up with a pile of tabs, half-finished sessions, and no clear picture of what each agent is doing.
That is the problem Multica solves. It is a source-available, self-hostable workspace where coding agents work like teammates: you assign them an issue, they pick it up, report progress, raise blockers, and hand the work back for review. It does not ship its own model — it drives the agent CLIs you already have installed, and Claude Code is one of them.
Here is how to set it up and use it day to day with Claude Code.
How Multica Fits Together
Before installing anything, it helps to know the pieces:
- Workspaces — separate agents, issues and settings per team or project.
- Issues — units of work. You assign an issue to an agent the same way you would assign it to a person.
- Agents — named teammates, each backed by a provider (like Claude Code) and a runtime.
- Runtimes — the machines where agents actually run. Each one runs a small daemon, so your code stays on your machine.
- Skills — reusable playbooks that agents share, so a good way of doing something only has to be written once.
- Squads — agents and people on one team, with a leader routing work.
- Autopilots — scheduled jobs for things like standups, audits and reports.
The key idea: the Multica server is the board, and the daemon on your laptop is the worker that runs claude when an issue lands on it.
Step 1: Install the CLI
On macOS or Linux, Homebrew is the easiest route:
brew install multica-ai/tap/multica
Make sure Claude Code itself is installed and signed in — Multica uses your existing claude binary, it does not bring its own:
claude --version
Step 2: Connect and Start the Daemon
If you are using Multica Cloud, a single command configures the CLI, authenticates you in the browser and starts the daemon:
multica setup
Prefer to keep everything on your own infrastructure? Multica can be self-hosted with Docker. The install script can bring the server along, and setup self-host points the CLI at it:
curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash -s -- --with-server
multica setup self-host
Then confirm the daemon is running and that it found Claude Code:
multica daemon status
The daemon auto-detects agent CLIs on your PATH, so claude should show up in the list of detected agents. If it lives somewhere unusual, point the daemon at it:
export MULTICA_CLAUDE_PATH="$HOME/.local/bin/claude"
Step 3: Create a Claude Agent
In the web app, open Agents → New agent, pick your machine as the runtime and Claude Code as the provider, and give it a name. That name is how you will assign work to it. You can check it from the terminal:
multica agent list
The Daily Loop: Issues In, Reviews Out
This is where Multica changes the workflow. Instead of opening a terminal session, you write an issue:
multica issue create --title "Add pagination to the /posts endpoint" --assignee "claude"
Or assign an existing one:
multica issue assign <issue-id> --to "claude"
From there, the daemon picks up the task and runs Claude Code against your repository. Two details here matter a lot:
- Every task runs in isolation. Multica keeps a cached clone of the repository and gives each task its own
git worktreeunder~/multica_workspaces. Two agents working on two issues never step on each other’s files. - Work goes to review, not to
main. When Claude finishes, the issue moves to review. You read the diff like you would read a colleague’s pull request.
While it works, you can follow along without attaching to any terminal:
multica issue runs <issue-id> --active # what is running right now
multica issue run-messages <task-id> # the full message log for a run
multica issue usage <issue-id> # how many tokens it took
The execution log records every tool call and command the agent ran, which makes reviewing how it got to a result just as easy as reviewing the result itself. If the agent gets stuck, it raises a blocker on the issue, and you answer it with a comment — in the web app or with multica issue comment add.
Tips for Getting Good Results with Claude
Keep a CLAUDE.md in your repository. Claude Code reads it on every run, so it is the best place to describe your conventions: how to run the tests, how commits should look, what not to touch. Since every Multica task starts from a fresh worktree, this file is what gives each run the same context.
Write issues like you would for a person. A clear title, the expected behavior and how to verify it. An agent that knows how to check its own work hands back much better reviews.
Tune the daemon with environment variables. A few I find useful:
export MULTICA_CLAUDE_MODEL="opus" # model used by Claude Code tasks
export MULTICA_DAEMON_MAX_CONCURRENT_TASKS=3 # default is 20 — keep your laptop breathing
export MULTICA_AGENT_IDLE_WATCHDOG=30m # stop runs that go quiet (default 2h)
Let the daemon start on its own. So you never forget to bring your agents online:
multica daemon autostart enable
Turn repeated instructions into Skills. If you keep writing the same guidance in issues (“always add a test”, “update the changelog”), that belongs in a skill that every agent can reuse.
The Verdict
Claude Code is already a capable developer. What Multica adds is the team around it: a board where work is visible, isolated worktrees so tasks run in parallel safely, a review step before anything reaches main, and a log of everything the agent did.
The shift in mindset is the real win. I stopped thinking “let me open Claude and do this” and started thinking “let me write a good issue and assign it.” If you already use Claude Code daily and feel the pain of managing several sessions at once, give Multica a try.