Long-running coding work is rarely a one-prompt job. A useful result usually needs planning, challenge, implementation, and review—but most coding-agent sessions blur those responsibilities together.
I built Stringbean to make that process explicit. Stringbean is a lightweight, local multi-agent orchestrator for coding-agent CLIs. It coordinates Codex, Claude Code, Grok Build, and configurable generic agents without replacing their native interfaces or requiring a new model service.
The short version: give
sbxa substantial coding task, and Stringbean turns it into a visible, resumable workflow with separate planning, advisory, implementation, and review stages.
Why I built it
Modern coding agents are capable, but the surrounding workflow still creates avoidable problems. One session may plan and edit at the same time. A long command can appear silent even while useful work is happening. An interrupted run can lose its context. The strongest model may be used for every step, even when a lighter one would be enough. Switching providers can also mean rebuilding the workflow from scratch.
Stringbean addresses those problems with coordination rather than another chat interface. It launches the tools already installed on the machine, gives each agent a defined role, records what happens, and keeps the final result distinct from intermediate activity.
How a Stringbean run works
A typical run moves through four roles:
| Role | Responsibility |
|---|---|
| Orchestrator | Translates the request into concrete, ordered tasks. |
| Advisor | Challenges assumptions, identifies missing constraints, and improves the plan. |
| Implementer | Executes the approved work in the target workspace. |
| Reviewer | Inspects the result and either accepts it or requests another pass. |
This separation makes the workflow easier to reason about. Planning can be reviewed before implementation begins, and implementation can be checked by a fresh role rather than accepted simply because the editing agent says it is finished.
Stringbean persists prompts, raw and parsed output, metadata, state transitions, and an event log under .stringbean/runs/. If a long job is interrupted, the run can be inspected and resumed instead of becoming an opaque terminal transcript.
Automatic model selection—with overrides when they matter
Not every stage needs the same model or reasoning budget. A routine repository inspection should not automatically consume the same resources as a difficult cross-cutting refactor.
Stringbean’s default auto mode chooses from the models and reasoning levels configured for each role. Users can still override the overall mode or choose the model and reasoning level separately for the orchestrator, advisor, implementer, and reviewer. The aim is not to hide control; it is to provide a sensible default while preserving explicit selection.
Use it from the coding interface you already prefer
Stringbean supports adapter plugins for Codex, Claude Code, Grok Build, and generic command-line agents. It uses the provider CLIs and credentials already available locally, so it does not replace a subscription or proxy requests through a new hosted account.
The concise entry point is sbx. Local integrations let it participate in slash-style workflows inside Codex, Claude Code, and Grok Build, while the full stringbean command provides configuration, diagnostics, status, logs, and resume controls.
sbx "Audit this repository and rank the most likely bugs" --ro
sbx "Implement retry logic and test the result" --rw --mode highDuring a run, Stringbean can show formatted provider output and regular progress heartbeats. Plugin-oriented output modes clearly label intermediate activity and wrap the reviewed final result in a machine-detectable sentinel block. That keeps the host interface informed without burying the answer in raw prompts or JSON.
Designed for real workspaces, with explicit safety profiles
Stringbean works in both Git repositories and ordinary directories. Git provides richer status and diff information, but it is an enhancement rather than a requirement.
- Read-write (
rw) is the default for implementation tasks and allows agents to modify the workspace. - Read-only/create-only (
ro) allows inspection and the creation of new files or directories, while rejecting changes, renames, moves, or deletion of existing paths.
Subagents also receive a denylist for destructive commands such as disk-formatting operations, shutdown commands, and destructive Git actions. Policy decisions and violations are recorded with the run, so safety behavior is inspectable rather than implied.
Where Stringbean fits—and where it does not
Stringbean is intended for work that benefits from several deliberate passes: diagnosing a subtle defect, implementing a feature across multiple files, hardening a sensitive code path, or auditing a project and fixing the resulting findings.
It is deliberately not the fastest tool for a tiny typo or a single shell command. Multi-agent planning and review add overhead. For small jobs, the native coding agent is usually the better choice. Stringbean becomes useful when the cost of a missed assumption or an unreviewed change is greater than the orchestration time.
Try Stringbean
Stringbean is open-source software released under the MIT License. Version 0.1.0 is currently marked as beta. It supports Python versions from 3.10 through 3.14, with Python 3.12 or newer recommended.
git clone https://github.com/ZenulAbidin/stringbean.git
cd stringbean
python3 -m pip install .
scripts/install-local-shims.sh
stringbean init
stringbean doctor
sbx "Inspect this project and propose the safest next change"The project is early, but its direction is clear: coding agents become more dependable when planning, implementation, and review are explicit stages with visible state—not one long, opaque session.
Explore Stringbean on GitHub to read the documentation, inspect the source, report an issue, or try it on a substantial coding task.
-Ali