Running four Claude Code agents in KalCode: installation, plans, and updates

Four agents: identify where limits originate instead of judging by plan alone

This article is based on official KalCode pages and does not report an installation or hands-on test. When checked on October 5, the pricing page explicitly stated that no plan imposes a KalCode-level count limit on local coding agents and terminals; the homepage likewise listed unlimited local-agent concurrency for every plan. This statement covers the application's own local count limits only. It does not guarantee that any computer or model account can complete four tasks simultaneously. Check workspace, provider-account, and other plan capacities separately on the pricing page.

The Plans overview in the release notes still lists parallel agents among limits counted across the whole application, without giving a current concurrency number. This article bases its plan assessment on the specific pricing-page and homepage statements. If the client still reports a limit, record the application build, signed-in account, operating system, and full error text, then check current account status and official guidance. Do not infer that every account received identical client behavior at the same time, or buy another plan immediately for an undiagnosed error.

If an agent opens and then reports exhausted model usage, check the selected Claude account's allowance prompt. The website also explicitly says hardware, operating-system, provider, account, API, and related-service restrictions may still apply. Ordinary shells and development servers also occupy panels, so four terminal windows do not prove that four agents are working.

First verify one agent's sign-in and task flow, then gradually add more. Before starting, decide whether the four tasks can progress independently. If the other three must wait for the first task's output, starting them together only adds waiting and repeated explanations. Compare the relevant plan benefits when you actually need more workspaces or account capacity.

Install for your platform and verify the download first

When checked on October 5, the download page listed 0.1.9 build1658 for 64-bit Windows 10 1809 or later, and Apple silicon Macs running macOS 14 or later. No Linux build was available. Intel Mac users should not interpret the Apple silicon download as a universal Mac version. This build number is not a separate semantic version and does not establish that the plan descriptions changed in this build.

Choose the appropriate platform on the official download page listed below and compare its SHA-256. On Windows, run Get-FileHash .\KalCode_0.1.9_build1658_x64-setup.exe -Algorithm SHA256 in the download directory. On macOS, run shasum -a 256 ./KalCode_0.1.9_build1658_arm64.dmg. If the filename or build later changes, use the value listed for that download rather than checking a new version against an old hash.

For a standard macOS user, follow official guidance to copy the app to ~/Applications so subsequent in-app updates can work. After installation, open a disposable practice project first and check that the app starts normally and recognizes its path before connecting an everyday repository. Initial verification needs neither customer data nor access to a complete project.

Before updating an older version, check the version and operating system

Versions 0.1.7 and 0.1.8 can update through Restart to update or Settings → Updates. Windows 0.1.6 cannot update itself and requires running a newly downloaded official installer once; macOS 0.1.6 can update within the app. Official guidance says installing over the existing Windows version preserves data.

From 0.1.9 onward, official guidance says subsequent updates install when KalCode closes, including upgrades to new versions. Save your work and end current tasks before closing and reopening the app, then check the installed version and build. Seeing only version 0.1.9 does not distinguish build1340, build1530, and build1658.

Before updating, finish the current test, save files, and record tasks in progress. Reopen the app afterwards and confirm the displayed version, project path, and account name. Repeat the same small task that worked before the update. If there is a problem, this helps separate application startup failure, a signed-out account, and a task-specific error instead of blaming the new version immediately.

Record the operating system, builds before and after the update, and error text. KalCode now saves reasoning effort for each thread; Restore previous version only permits builds that can read that data. Official guidance does not name the earliest compatible build here, so use the restore options the app offers rather than clearing the data directory to force a downgrade. If the expected older version is unavailable, preserve the current data and error and consult the official update instructions.

Connect your own Claude account within KalCode

Install a supported Claude Code CLI first. KalCode documentation specifies stable 2.1-series releases from 2.1.282 onward and excludes prerelease builds. Open Providers → Accounts, add a Claude Code account, select Sign in, and complete the provider's browser sign-in flow.

Each account uses a separate managed configuration. Signing into the CLI in another system terminal does not sign into the configuration KalCode uses; detecting an installed CLI does not mean the account is authenticated. Check the account entry's status in the app before starting a task.

Give personal and work accounts recognizable names. Test with one clearly identified account instead of mixing several login identities from the start. If authentication fails, record the error shown in the app and the CLI version, and verify the selected account. Do not paste access tokens, login callbacks, or full account credentials into public support posts.

Verify one agent, then expand to four independent tasks

In Code, click New agent or use the panel's plus entry point. Choose the provider, account, model, effort, and count, then click Launch. Each agent opens its own terminal panel. Launch only one initially and confirm that the identity in the panel matches the account selected.

Use a practice request such as: “Only read this example project and list its entry files and test commands. Do not modify files or run installation.” Check that the agent reads the right directory and that its answer corresponds to actual files. If approval is requested, inspect the specific action first. This is a suggested test example, not a reported run from this article.

After it passes, gradually expand to four agents responsible for structure review, option comparison, test design, and review of existing changes. Specify each task's input, prohibited scope, completion criteria, and delivery location, and verify the assignment individually. For the first exercise, ask for suggestions only. Once tasks are not getting mixed up, authorize one small change for a designated agent.

If an agent produces no output for some time, first check whether it is waiting for sign-in, approval, or prerequisite material. Preserve the panel containing the error instead of immediately launching the same task again and creating competing modifications.

Check branches and changes before deciding how to merge

Official guidance says newly created agents in a Git workspace each use their own worktree and branch. Verify the branch, then review the actual diff. Directory isolation does not determine whether changes are correct.

If also using Codex, a known issue in 0.1.9 prevents it from committing within its own worktree; use Commit changes on the agent card. Do not apply that exception to every Claude Code task or commit unreviewed files merely to remove a status prompt.

Designate a final integrator who reviews each branch's diff and merges in dependency order. For example, if one agent changes an interface and another writes caller tests, first compare parameters and return values. Separate tasks finishing does not mean the combination will run. After merging, run the project's existing relevant tests and check for duplicate implementations or outdated instructions.

Keep approval enabled initially and recognize features that are not available yet

The permissions documentation lists Approve as the default mode: workspace reads may proceed, while writes and commands require a question when no applicable rule exists. Keep this mode during your first parallel exercise. Inspect each file modification, command, and target directory before deciding whether to approve.

Gemini CLI is unavailable in KalCode 0.1.9. This is a limitation of the current integration, not a conclusion that other Gemini products are unusable. If the goal is four Claude Code agents, keep this check focused on the connected Claude accounts.

The website lists Squads, Agent Handoff Chains, and file-ownership conflict warnings as Coming soon. Demonstration layouts and plan roadmaps are not evidence that these capabilities already exist. For now, explicitly define handoff conditions yourself: who checks the result, what the next task depends on, and who decides which version to keep if changes overlap.

At the end of verification, inspect every agent's actual output, repository diffs, and tasks still running. Successfully running four agents means four tasks with clear responsibility and verifiable results, rather than simply four busy windows on the screen.