taskr

Coordination layer · Claude Code, Codex, Cursor, opencode

One record. Every agent you run.

taskr connects your models into one hive without becoming the thing that runs them. There is no orchestrator, no runtime, no graph to hand your agents to — only a shared record they read before they start and write before they stop. The strong model’s plan is still sitting there when a cheaper one picks it up, and neither had to be running at the same time.

Start free trial Free 14 days, no card. $5 a seat a month after. Have an account? Sign in.
  • coordinates Many models, many tools, one record. Any agent that can run a shell joins the hive; none of them has to know about the others.
  • without controlling Four commands, called by the agent when it chooses. Nothing to declare up front, nothing supervising the run, nothing to rewrite.
  • and nothing is lost Append-only and attributed. What one session worked out is what the next one starts from, whichever model that turns out to be.
curl -fsSL https://aitaskr.com/install.sh | sh

macOS and Linux, no Go toolchain needed. Windows and other options on the releases page.

Why it isn’t an orchestrator

A coordination layer with nothing in the middle.

Every multi-agent framework asks for the same thing first: hand us your agents. Declare the graph, run them inside our loop, rewrite the tool calls our way. That buys coordination at the price of owning the execution — and the moment a run dies, so does everything it knew. taskr takes the opposite trade. It owns the record and nothing else, so there is no middle for your agents to be stuck inside.

  • a runtime your agents execute inside
  • a graph you declare before you start
  • a supervisor process that has to stay alive
  • a framework you rewrite your agent around
  • taskr context where am I, what was I doing
  • taskr start open a session, print the resume packet
  • taskr offload file what you find, without derailing
  • taskr park stop by naming the next action

That is the whole integration. The CLI is an HTTP client and nothing else — it never runs git, never opens a database, never launches an agent. Coordination happens because every agent reads the same record, not because something is standing over them making it happen.

Proof — sessions, not tickets

A tracker records that work exists. This records that work happened.

A coordination layer needs to know who is working right now, on which model, and why the last one stopped. Jira, Linear and GitHub Issues track something else — a body of work, a feature, an epic — and they are good at it. They just cannot answer the question the hive asks. Same eleven days, both records:

a planning tracker
  • status In Progress
  • since 11 days ago
  • assignee unassigned
  • last comment “picking this up” · 9 days ago

Four fields, none of which moved while the work did. Nothing here is wrong — it is answering a different question.

taskr PAY-203 · sessions, in order
  • 09:03–11:47 Claude Opus 5 started read the spec, wrote the plan, attached both
  • 11:47 Claude Opus 5 parked handoff — “steps 1–3 are ready to execute”
  • 14:02–17:20 GLM-5.3 started resumed cold, off the plan
  • 17:20 GLM-5.3 parked context_exhausted — “replay test still red”
  • 09:41 +1d you closed unique index on event_id; one invoice per event

Five spans, each with edges, two of them on different models. “In progress” is not a state anything sits in here — it is whether a session is open right now.

Proof — planned, built, reviewed

Plan with your best model. Build with any of them.

The expensive model earns its price on the spec and the plan, and wastes it on the fourth mechanical edit. The hive makes that split practical: the design is attached to the issue, the work is a group of ordered steps, and every step records which model planned it and which model built it — so the review at the end checks work against a document, not against somebody else’s vanished chat log.

roster who this page names, and why measured 19 Aug 2026
  • plans Claude Opus 5 intelligence 63.1 · coding 78
  • builds GLM-5.3 agentic 59.1 · $4.40/Mtok out

Provided by Artificial Analysis via OpenRouter.

PAY-200 group high Billing: move from one-off charges to subscriptions 3/10 closed
spec webhook-idempotency-design.mdplan phase-3-implementation.mdnote stripe-retry-semantics.md
  1. 1 PAY-201 closed Claude Opus 5 GLM-5.3 Phase 1: customer and subscription tables, backfilled from charges
  2. 2 PAY-202 closed Claude Opus 5 GLM-5.3 Phase 2: Stripe Checkout for new signups
  3. 3 PAY-203 in_progress Claude Opus 5 GLM-5.3 Phase 3: webhook ingestion — invoices, payment failures, cancellations
  4. 4 PAY-204 in_progress Claude Opus 5 Gemini 3.7 Flash Phase 4: proration on plan change
  5. 5 PAY-205 open not started Phase 5: dunning emails and a grace period before downgrade
  6. 6 PAY-209 open not started Invoice PDF still renders the old company address
  7. 7 PAY-216 open Claude Opus 5 review Read phases 1–4 back against the spec before phase 5 builds on them

illustration · every ref on this page belongs to the same invented project

  • Claude Opus 5 → GLM-5.3 planned by, then built by
  • review a step like any other, so it cannot be the thing that gets skipped

No agent in that walk needed the one before it to still be running, or to know it existed. Each read the group, took the next open step, and wrote back what it did. That is the entire coordination protocol.

Proof — the thread outlives the chat

Write it down from inside the session you are already in.

A hive is only as good as what its members leave behind. The moment an agent notices something is the moment it has the context to describe it — and the moment it is least able to stop. So it doesn’t stop: taskr offload files the finding with a file:line and a definition of done without leaving the task, and taskr park ends the session by naming the next action. Same webhook bug, two models, seventeen hours apart:

events PAY-212 · one issue, two agents, seventeen hours apart
  1. #0728 14:02 session.started PAY-212 Claude Opus 5 · writes as agent
  2. #0729 14:19 comment.added PAY-212 handler returns 200 before the insert commits; the retry arrives first
  3. #0730 15:03 doc.attached PAY-212 webhook-idempotency-design.md
  4. #0731 15:31 issue.offloaded PAY-214 noticed mid-task: trial_end stored as a date, compared as a timestamp
  5. #0732 15:47 session.parked PAY-212 context_exhausted
  6. context window ended — 17h 16m — agent gone
  7. resume note
    Move the 200 below the insert in internal/billing/webhook.go:88 and put a unique index on stripe_events.event_id. Done when the replay test posts one event twice and gets one invoice.
  8. #0733 09:03 session.started PAY-212 GLM-5.3 · writes as agent · resumed cold
  9. #0734 09:41 issue.closed PAY-212 unique index on event_id; replay test proves one invoice per event

The second agent never saw the first one’s context, was not the same model, and did not run in the same tool. It saw the record, and the record was enough. Note #0731: the trial-end bug was found here and filed here, and it is still open on its own issue rather than dead in a transcript.

  • append-only Nothing is edited. A correction is a new entry that strikes the old one, so the record of how a decision changed is the record.
  • attributed Every write is stamped with the credential that made it, whatever the request body claims. An agent cannot file a note as you.
  • specs attached A design attached to its issue comes back in the resume packet. A spec that only lives in git is invisible to the next agent.
  • one record Shared across sessions, repos, tools and models. Not a CLAUDE.md per checkout, not a scratch file the agent may or may not re-read.
export TASKR_REMOTE=$(git remote get-url origin)
export TASKR_ROOT=$(git rev-parse --show-toplevel)
export TASKR_HEAD=$(git rev-parse HEAD)
taskr context

Drop the skill file in .claude/skills/ and your agent runs taskr context before it touches anything. taskr never runs git itself — you tell it, and it writes down that you did. A coordination layer that invents nothing is one every member can trust cold.

Early access

Five dollars a seat. The hive is free.

One plan, billed per person. Every agent you point at it writes under your seat at no charge — however many models you run, and whichever tools they run in. The rate is early-access pricing, and it stays yours for as long as the subscription does.

Monthly

$5

per seat, per month

Rate kept for as long as you stay subscribed.

Start free trial
Yearly two months free

$60 $48

per seat, per year · $4 a month

Rate kept for as long as you stay subscribed.

Start free trial
  • user a seat is a person agent agents are unlimited, and free
  • 14-day trial, no card: 10 projects, 2,000 issues, 50 MB of documents. Unlimited once you subscribe.
  • Already have an account? Sign in.

Put the hive on one record.

Every write is stamped by the credential that made it — user when it’s you, agent when it’s one of the things working beside you — and now with the model it was running.

Start free trial Free 14 days, no card. $5 a seat a month after. Have an account? Sign in.
taskr append-only · one Go binary · Postgres with row-level isolation