Retasc
The work queue your coding agents pull from
Your agents take different issues when you run multiple Claude Code agents in parallel with Retasc, a work queue for AI coding agents, because each claim is one server transaction. Two agents can never hold the same issue. An agent calls next_issue and claims the highest effective-priority issue that is unblocked and unclaimed. Setup is one command, npx @retasc/cli@latest bind, run in the folder to connect. It asks for browser approval once if you are not signed in. It gives the folder an agent key. It wires the MCP server. You then start or restart the agent in that folder. Setup wires Claude Code, Codex, Cursor, OpenCode, Gemini CLI, Grok and Pi on the machine in one step.
Features
- A claim is one server transaction. Two agents can never hold the same issue.
- Retasc refuses a create that looks like open work until your agent names the look-alike issues it read.
- Blocking is computed live from links, never stored. Closing a blocker frees its dependents at once.
- Checkpoints stay on the issue for whoever resumes, with what is done, what is next and the gotchas.
- Work in review jumps the queue. It starts at least High, is Urgent at 21.6 hours and first after 24 hours.
- The Retasc CLI renews your agent's leases every 10 minutes on its own. A long build does not lose the claim.
Use Cases
- You run Claude Code, Codex and Cursor together. Agents pull from one queue. Atomic claims keep them on different issues.
- You run an orchestrator. next_batch supplies issues with no dependencies between them for parallel agents.
- Your laptop closes mid-task. When the lease expires, your next agent resumes the issue from its checkpoint.
- You can't tell who holds what. The Dash lists all agents, runtimes like Claude Code, held issues and lease minutes left.
Comments
Doing the claim as one atomic transaction is the right call. I've had two Claude Code sessions both grab "fix the auth bug" and then fight over the same files. The checkpoint-on-the-issue part is what I'd actually use most, because picking up a half-done task after the laptop sleeps is rough right now. Does next_batch look at which files an issue will probably touch, or just at dependency links? Two unrelated issues in the same file still make for ugly merges.
The duplicate check, refusing a create that looks like open work until the agent names the look-alikes it read, is the feature I haven't seen elsewhere. Agents love opening a fresh ticket for something already in flight. A question from running two agents on one Mac: our collisions weren't over issues but over shared local things, the one iOS simulator, a fixed test-driver port, the same git checkout. Could an issue declare a resource it needs, so next_issue skips work whose resource another agent holds right now?
Premium Products
Sponsors
Buy
Makers
Makers
Comments
Doing the claim as one atomic transaction is the right call. I've had two Claude Code sessions both grab "fix the auth bug" and then fight over the same files. The checkpoint-on-the-issue part is what I'd actually use most, because picking up a half-done task after the laptop sleeps is rough right now. Does next_batch look at which files an issue will probably touch, or just at dependency links? Two unrelated issues in the same file still make for ugly merges.
The duplicate check, refusing a create that looks like open work until the agent names the look-alikes it read, is the feature I haven't seen elsewhere. Agents love opening a fresh ticket for something already in flight. A question from running two agents on one Mac: our collisions weren't over issues but over shared local things, the one iOS simulator, a fixed test-driver port, the same git checkout. Could an issue declare a resource it needs, so next_issue skips work whose resource another agent holds right now?
Premium Products
New to Fazier?
Find your next favorite product or submit your own. Made by @FalakDigital.
Copyright ©2026. All Rights Reserved