Your First Run & Costs

Credentials saved, modules created, Lane enabled — this chapter covers the last mile. You'll mark a ticket ready, follow the run minute by minute, read the result on the record page, and see exactly what it cost. At the end: the caps that govern how much you can run, and where to go when a run misbehaves.

Before you start, confirm the stack is actually in place:

✓	Where	What
1	Settings → Credentials	An Anthropic credential (API key or OAuth token) and a default model — see Credentials
2	Settings → Credentials	The service credentials your tickets and repos need (GitHub PAT, Jira, …), each Verify-green
3	Modules	A Ticketing module and a Version Control module — see Modules
4	Lanes	A Lane with both modules attached, at least one verified repo, and Enabled on — see Lanes

Not set up yet? The pieces stack in a fixed order — Claude credential → service credentials → modules → a Lane. First Steps walks the whole chain end to end.

Kick it off: mark a ticket ready

Pick a real ticket — small and well-described beats big and vague for a first run — and mark it ready in your tracker:

• Label tracker (GitHub Issues): apply the Lane's discovery label (e.g. ai-eligible). If the Lane uses several discovery labels, the ticket needs all of them.
• Status tracker (Jira / Shortcut): move the ticket into the Lane's Ready status.

That's the entire trigger. The Lane polls its ticketing source on its own interval (default 30 seconds), and on the next tick, discovery matches your ticket and creates a record — the in-flight work item you watch on the Dashboard.

Running the same ticket twice? Discovery never re-picks a ticket that already has a record. To run it again: add the Lane's re-run label (default ai-redo) on GitHub, move the ticket back to Ready on Jira / Shortcut, or press Rerun on the record. Details in Lanes and Troubleshooting.

Tip: the PM agent turns the ticket text into requirements, so the better the ticket reads — clear title, expected behavior, constraints — the better the PR. Oversized tickets are the top cause of timeouts and mediocre results; split them.

What happens, minute by minute

Open the Dashboard and press Refresh after a poll cycle (~30 seconds). Your ticket appears as a row — the Active stat card ticks up with it — and its State pill walks through the workflow.

A run normally flows through these states top to bottom:

Picked Up — the ticket matched your Lane and a record was created. On a status tracker, this is also the moment the ticket moves out of Ready (if you mapped the In Progress stage). Nothing to do; it advances on its own.

Queued (you may not see this) — the run is waiting its turn, for one of two reasons:

• Every concurrent run slot is busy — see capacity below. The run is admitted automatically as slots free up.
• The Lane has Optimize enabled and the repos' artifacts aren't generated yet — the run waits for them rather than working unoptimized.

Either way, Queued is a waiting room, not a failure state. Nothing fails here.

Starting — the workspace and runner container are being provisioned: your Lane's repos are cloned into a multi-repo workspace and the agent team boots.

Planning — the PM agent turns the ticket into a requirements document (the PRD). You can already watch this live in Record Detail.

Coding — architecture and design, failing tests, then implementation. Usually the longest state — often many minutes on real tickets. A climbing duration with no state change is normal here; if you want proof of life, the record's live output shows the agents working.

Reviewing — the QA agent adversarially reviews the work against the requirements.

Finalizing — committing, pushing the branch, and opening the pull request(s).

Notifying — posting results back: the ticket comment, lifecycle updates, and any Messaging notifications.

Done — finished. This is your cue: a PR is open and waiting for your review.

The full state reference — including Failed and Cancelled — is in Dashboard.

The Dashboard doesn't auto-update — it loads when you open it and refreshes when you press Refresh. If you're going to sit and watch (recommended for your first run), open the record itself instead: Record Detail streams live.

What lands where

When the run reaches Done, the results are already distributed:

• Pull requests — one PR in every repo the run modified. A single-repo Lane gets one PR; a cross-repo ticket on a multi-repo Lane gets a PR in each affected repo, opened in the same run. Links appear in the record's Repos & PRs section.
• The ticket — gets a comment with the results, and (if you mapped lifecycle stages on the Lane) moves on your board or picks up labels as the run progresses. Lifecycle updates are best-effort: a tracker hiccup is logged, never fatal.
• Your channel — if the Lane has a Messaging module (Discord / Slack), a notification lands there too.

Done means "ready for your code review," never "merged." Tenbi keeps the human checkpoint at the end — nothing lands on your base branch without you.

Reading the run

Click the row on the Dashboard to open Record Detail — the page for investigating one run. The Dashboard is the overview; this is the microscope. What you'll find, top to bottom:

• The header — the ticket's title and state, plus the Lane, the attempt number, the start time, and the model the run used. Open ticket jumps to the ticket in your tracker.
• Ticket Snapshot — the ticket's labels and description exactly as the run saw them.
• The phase stepper — the happy path (Picked Up → Starting → Planning → Coding → Reviewing → Finalizing → Notifying → Done) with the current step highlighted; a failed run marks the phase it died in.
• Cost Telemetry — this run's cost and token counts: Cost (or Est. value (subscription) on OAuth auth — see below), Input, Output, and Cache read tokens.
• Live Output (opt-in) — press Go live to stream the run in real time: phase transitions, events, and runner stdout. It's idle by default; Stop and Clear control the stream. This is the best way to watch your first run work.
• Artifacts — the agents' deliverables as collapsible rendered markdown: Product Requirements, Architecture / Design, Test Plan, Implementation Summary, QA Report, DevOps Summary, and the PR Body. Each has a download button.
• Repos & PRs — per-repo branch, commit count, and the PR link with its status.
• Events — the timestamped event log for the run.

Reading the Product Requirements artifact after your first run is worth the two minutes — it shows you exactly how the PM agent understood your ticket, which is the single best feedback loop for writing better tickets.

The Cancel and Rerun actions live at the top of the record. Rerun re-fetches the ticket, so if you edit the ticket text between attempts, the next run picks up your edits. What the agents do inside each phase is covered in Agent Reasoning; the full Dashboard table and filter reference is in Dashboard.

What your first run costs

Runs bill to your own Anthropic credential — Tenbi never marks up or meters your usage. As working figures from real runs: small, well-scoped fixes usually land in minutes for a few dollars in Claude usage; feature-sized tickets typically run $5–$20 and 15–45 minutes. Your actual number depends on the model (the biggest cost/quality lever — set as the default in Credentials, overridable per Lane) and on ticket size.

How the dollar figures work depends on your auth mode:

• API key (metered): the run's Cost is real spend — Anthropic bills you per token at their standard prices.
• OAuth token (subscription): the run drew on your flat-rate Claude plan, so the per-run dollar amount shown is the API-equivalent value of the usage — an estimate of what the run would have cost on a metered key, not a bill. The Cost Telemetry row is labeled Est. value (subscription) to make this unambiguous.

Tokens are the primary usage measure. Token counts (input, output, cache read, cache write) are captured reliably in both auth modes and drive any monthly token budget on your account. Dollars are secondary: spend totals in Analytics sum API-key runs only — subscription estimates are useful for judging a run's weight, but they're excluded from spend totals.

Reading your first run's numbers: open the record's Cost Telemetry and compare Cache read against Input. A high cache-read share means prompt caching is doing the heavy lifting — the single best signal your runs are cost-efficient. Analytics tracks this as the cache hit rate across all your runs.

Spend trends, per-Lane cost breakdowns, and averages across your whole history live in Analytics.

Quotas & capacity: the two caps

Two independent kinds of limit shape how much you can run. Plan specifics — how many runs, which caps — live on the pricing page, not here.

1. Monthly quota — how much you can run per month

Your account can carry a monthly run cap and/or a monthly token budget (tokens count identically in both auth modes). Both are checked when a ticket is picked up:

• Under the cap → the run proceeds normally.
• Over the cap → the new run fails immediately with Monthly quota reached — before any ticket side effects, so your board isn't touched.
• Runs already picked up — running or queued — always finish and their PRs land. The quota only gates new pickups.

The window resets at the start of the next calendar month (UTC). Need it raised sooner? Contact support with your account name — see Troubleshooting.

2. Concurrency — how much can run at once

Your account has a cap on simultaneous runs. Tickets beyond it aren't rejected — they sit in Queued and are admitted automatically as slots free up. Nothing fails from concurrency; a queue just means your runs execute in sequence instead of in parallel. Label ten tickets at once on day one and this is exactly what you'll see — and it's fine.

Subscription-auth users have a third, external limit: your Claude plan's own rolling usage windows. Heavy run volume (or running Tenbi alongside your own Claude use) can exhaust a window mid-run, and those runs fail as rate limited until it resets. This is Anthropic's limit, not Tenbi's — see Credentials for the trade-offs of each auth mode.

When it goes wrong

A first run that fails almost always fails for one of a handful of reasons, and each has a walkthrough:

Symptom	Usual cause	Start here
Ticket never appears on the Dashboard	Lane disabled, label/status mismatch, or just a poll cycle away	Troubleshooting — tickets not picked up
Run fails within seconds with an auth error	Anthropic credential missing, expired, or wrong mode selected	Troubleshooting — model key invalid, then Credentials
Repo won't verify / clone fails with not found	PAT scopes — a private repo the token can't see reads as 404	Troubleshooting — VCS repo not found / PAT scopes
Run fails with rate limit / overloaded in the log	Provider throttling — on subscription auth, often an exhausted usage window	Troubleshooting — rate limited
Record shows Failed with a reason you don't recognize	Varies — the callout names it	Troubleshooting — how to triage

When a failure's cause is known, the red callout at the top of the record carries a Troubleshoot this → link straight to the matching troubleshooting section — follow it before anything else. Auth failures additionally offer an Update Anthropic credential shortcut into Settings.

Whatever the cause: fix it, then press Rerun on the record. Reruns re-fetch the ticket and start fresh — nothing about a failed attempt contaminates the next one.

Where to go next

• Dashboard — the full table, filters, and state reference you'll use daily.
• Analytics — spend, tokens, cache hit rate, and success rate across all your runs.
• Lanes — lifecycle mapping, re-run triggers, multi-repo workspaces, and per-Lane model overrides.
• Optimize — the per-repo artifacts that make runs faster and cheaper on repos the agents visit often.
• Troubleshooting — every failure, symptom by symptom.