Back to Research

Abralo Puts Claude Agents in One Window

Abralo is a free window for several Claude Code agents, useful when terminal splits hide what needs review.

Saint-Tropez - 2025 - lithographie musée de Montmartre, landscape painting by Maximilien Luce.
Rogier MullerJuly 11, 20269 min read

Abralo is an independent Show HN project that puts several Claude Code agents in one window. It deals with a small but real problem: once Claude Code, Anthropic's coding agent, is running in several terminal panes, you lose track of which agent needs attention. The useful takeaway is simple: Abralo is worth trying when your bottleneck is supervising parallel agents, not when you need deeper automation. Think of it as an attention layer around agentic coding, not a replacement for ai code review tools or human review.

See every Claude Code agent without terminal archaeology

The project exists because split terminals are a lousy control room. They work fine for one long-running task. They get weird when one agent is refactoring a service, another is writing tests, and a third is blocked on a yes/no question you missed fifteen minutes ago.

Abralo’s pitch is intentionally narrow: keep multiple Claude Code sessions visible in one place. That matters because the failure mode is not usually that the model stops. It is that the developer stops noticing the right thing.

A concrete example: you ask one agent to migrate billing/ from a hand-rolled retry helper to a shared RetryPolicy, and another to add regression tests around failed card renewals. In terminals, you may only notice the noisy one. In a single window, the blocked test-writing agent is easier to catch before it invents a fixture or waits forever.

The trap is treating the window as a productivity multiplier by default. Four agents can produce four times the diff, but also four times the review surface. Abralo helps you see the work; it does not make the work correct.

Treat parallel agents as competing drafts

The healthiest way to use Abralo is to give each Claude Code agent a separate, reviewable draft. One agent can explore the backend change. Another can write tests. A third can inspect docs or look for adjacent call sites. They should not all be editing the same files at the same time unless you enjoy merge-conflict archaeology.

This is where Abralo fits the current coding-agent moment. Developers are not just asking “can an agent code?” anymore. They are asking how to keep agent work legible while several sessions run at once.

The Hacker News reaction had the right skepticism. Some readers liked the look of the project and wanted to try it. Others asked about support for coding agents beyond Claude Code, mentioned model-neutral alternatives, or disliked a four-agent limit. Those are fair objections. If you want one launcher for every agent, Abralo may be too specific. If your real pain is following several Claude Code sessions, specificity is the point.

A useful operating rule: one agent, one branch, one claim. For example:

agent-a: branch billing-retry-policy — implement the retry change
agent-b: branch billing-renewal-tests — add failing tests first
agent-c: branch billing-callsite-audit — list affected call sites only

The trap is letting agents silently share context through your memory rather than through artifacts. If an agent discovers an important constraint, make it write the constraint down in the branch notes, PR body, or a small handoff receipt.

Keep permissions boring while the window gets busy

A multi-agent window should make attention easier, not permissions looser. When several Claude Code agents are running, keep the dangerous actions explicit: package installs, database writes, deploy commands, credential access, and anything that touches customer data.

A small Claude Code hook boundary is enough for many repos. Use hooks to stop or flag commands that should never run unattended, and keep your repository memory short so agents know the local rule before they act.

Hook boundary for a web app repo

Allow without asking:
- npm test -- --runInBand
- npm run lint
- npm run typecheck
- git diff --stat

Ask first:
- npm install or pnpm add
- database migrations
- scripts that write to S3, Stripe, or production APIs
- git push --force

Never allow from an agent session:
- reading .env.production
- sending real emails
- deploying from a feature branch

This matters more in Abralo because parallelism hides causality. If three sessions can all run commands, you need boring boundaries so you can reason about what happened later.

The trap is putting every rule into a giant always-on instruction file. A concise CLAUDE.md note such as “Do not run migrations without asking; use npm test and npm run typecheck before proposing a PR” is easier for an agent to follow than a policy novel. Save task-specific instructions for the prompt or a slash command.

Try Abralo when attention is the bottleneck

Abralo is a good fit when you already use Claude Code heavily and your current workspace is a pile of terminal splits. Try it on a repo where agent tasks can be separated cleanly: tests, refactors, docs updates, dependency cleanup, or call-site audits.

It is overkill when you only run one agent at a time, when your repo cannot tolerate parallel file edits, or when your main pain is final review quality. In that case, your time is better spent improving your review checklist, test suite, or code review tools.

This is also where ai code review tools belong in the story. Abralo helps you supervise active agent sessions; code review AI or llm code review tools help inspect the resulting diff. Those are different jobs. Confusing them is how teams end up with a beautiful control room and a shaky merge button.

If you are comparing this pattern to larger agent evaluations, keep scale in mind. Databricks’ public work on coding-agent benchmarks is about measuring agents across a large codebase; Abralo is about a developer managing a few live sessions in one window. Both are useful, but they answer different questions. We covered that broader angle in Databricks Benchmarked Coding Agents at Scale.

For Claude Code users who care about repeatable review guardrails across coding agents, the surrounding practice lives in the related training topic. Abralo is the small, tactile part: seeing what is happening before you decide what to trust.

Try-it-safely checklist for one repo

Use this as a one-hour experiment, not a grand process change. Pick one small repo and one real issue.

Check Do this Stop if
Choose the work Pick a task with separable parts, such as “add tests” and “refactor helper.” The work requires several agents editing the same files.
Split the agents Give each Claude Code session one branch and one outcome. You cannot describe the agent’s job in one sentence.
Set a permission note Block production secrets, deploys, force pushes, and external side effects. The agent needs live credentials to make progress.
Require a handoff Ask each agent for files changed, tests run, risks, and open questions. The agent only gives a cheerful summary.
Review the diff Use normal review plus code review AI if you already trust it. The tests are missing or the diff mixes unrelated work.
Merge slowly Merge one branch at a time after tests pass locally or in CI. Two branches make conflicting claims about the same behavior.

A good handoff receipt is tiny:

Agent handoff receipt

Branch:
Goal:
Files changed:
Commands run:
Behavior changed:
Tests added or updated:
Risky assumptions:
Needs human decision:

The important part is not the format. It is forcing each agent to leave you something reviewable before you switch attention to the next pane.

Common questions

  • Is Abralo an ai code review tools replacement?

    No. Abralo is a window for supervising multiple Claude Code sessions, not a system for approving diffs. Use it before review to keep agents visible, then use your normal code review process, tests, and any trusted ai code review tooling on the final changes.

  • Why would I run several Claude Code agents at once?

    Run several agents when the work splits cleanly into independent tracks. A common pattern is one agent writing tests, one making the implementation change, and one auditing related call sites. The caveat is file ownership: parallel agents should not casually edit the same hot files.

  • Does the four-agent limit matter?

    It matters if your workflow already depends on more than four simultaneous sessions. For many developers, four is enough because the real limit is review attention, not compute. If you need a larger pool or non-Claude agents, a model-neutral runner may fit better.

  • Should I use Abralo with Claude too?

    Use Abralo for Claude Code sessions and Claude, Anysphere's AI code editor, for the editor-native agent experience if that is your normal workspace. They solve adjacent problems. Claude’s Agent works inside the editor; Abralo is about watching several Claude Code agents in one place.

  • What should I check before merging agent-written code?

    Check the claim, not the chat. Read the diff, run tests, inspect edge cases, and ask for a handoff receipt that names commands run and assumptions made. A code review llm can help find suspicious changes, but it should not be the only reviewer.

Best ways to use this research

  • Best for: Claude Code users who already keep two to four agents running and lose time hunting through terminal panes.
  • Best first artifact: A branch-level handoff receipt with files changed, commands run, tests updated, and open questions.
  • Best comparison angle: Abralo versus editor-native agents is mainly about visibility. Editor agents keep work close to code; Abralo keeps several live sessions close to your attention.
  • Best safety habit: Keep command permissions boring. Parallel agents are easier to supervise when dangerous actions always stop for a human decision.

Further reading

Next step

Try Abralo on one small issue with two Claude Code agents: one test branch and one implementation branch. If the handoffs are clearer than your terminal splits, keep the pattern; if review gets noisier, reduce the agent count.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Related training topics

Related research

Continue through the research archive

Ready to start?

Transform how your team builds software.

Get in touch