Cards

A card is both a work item and the durable home of its agent sessions, messages, files, Git state, comments, and history.

Create a card

Select New card or the plus button in a column. The prompt is the agent's objective; the title is optional and can be generated from that prompt.

The creation dialog can configure:

• destination column and labels;
• credential, provider agent, model, reasoning effort and, for Claude Code and OpenCode, compaction;
• main repository or an isolated Git worktree and custom branch;
• Auto mode and per-card pipeline choices;
• a scheduled Loop that relaunches the card in place;
• structured Agent execution or interactive Terminal execution.

Use attachments for required input files. Use @ file mentions and / commands or skills when the selected agent supports them. Never paste a password or token into the normal prompt: the padlock in the composer attaches it to the message being written, like a file, so the request and its secret leave together. The padlock can also designate a secret from the project's vault and, in the desktop app, read one from 1Password, Bitwarden or Windows Credentials. The conversation keeps only its label; the agent receives a private file, never the value.

Write an effective prompt

State the desired outcome, important constraints, relevant files or components, and how completion should be verified. Avoid prescribing implementation details that are not actually required. A good card lets the agent inspect the repository before committing to a plan.

Open and follow work

Select a card to open its panel. The main tabs are:

• Conversation — user messages, agent output, tool calls, questions, and composer;
• Diff — files changed by the active worktree or repository;
• Costs — what the card's runs would have cost at the providers' public API rates;
• History — sessions and important card events.

The header exposes the current status/column, execution controls, and more actions. Several card panels can be open at once, subject to the user's panel limit and available width.

Costs

Run costs are off on a new server: the host operator turns them on in Server settings › Costs. Tokens are recorded either way, so the history is complete from the first run.

The Costs tab shows the API equivalent of the card: what the tokens its agents consumed would have cost at each provider's public API rate, whatever credential ran them. A subscription is not billed that way — the figure is a comparison, not an invoice.

• Each run is priced at the rates in force the day it started, at the speed it ran (fast mode doubles Opus 5.5, for instance) and at the price tier each request fell in (long-context tiers are decided request by request).
• A run expands into its agents: the main one, then every sub-agent — a workflow or Ultracode fan-out — on its own model. When the runner's own per-model totals hold more than the requests Stib saw (Claude Code), the rest closes the list as Not attributed.
• Saved by the cache compares with the same tokens billed without prompt caching; What if… re-prices the card with fast mode or caching switched off.
• When the runner announces its own figure (Claude Code, OpenCode, Grok…), it is shown beside Stib's for comparison.
• On a card that ran before per-run tracking, that earlier usage appears on one line, priced at today's rates.
• The footer names what the figure leaves out or approximates — a model with no published rate, a runner that reports no tokens, cache writes without a lifetime — and links the price sources with the date they were checked.

The project's costs over a period — by model, member or runner, the costliest cards, and each subscription's monthly price against what it served — open from the project menu of the sidebar, Costs. A subscription's monthly price is entered in its credential settings; Stib cannot know it.

Status and activation

Typical runtime states include idle, running, waiting for input, completed, failed, and cancelled. A column move and a runtime status are different concepts: a completed session does not necessarily move the card unless Auto mode or an automation says so.

You can activate deferred work, cancel a running agent, retry a failed/completed session, send another message, or move the card. Controls are disabled when a lock, permission, or incompatible state makes the action unsafe.

Move, archive, and delete

Drag cards between columns or use card actions. Moving into an active column may start work; moving out can pause, resume, reset context, clean a worktree, archive, or fire hooks depending on column settings.

Archive hides completed work without deleting its history. Deleted cards enter the project trash when retention is enabled and can be restored until permanent deletion. Check the project's retention policy before relying on trash as a backup.

External and project-agent cards

Integrations can import external issues as linked cards. Some boards also display project-agent work alongside Kanban cards. Their available actions and source-of-truth fields can differ; Stib shows integration state and sync errors rather than silently overwriting unsupported changes.

Next: Agents, Pipeline, and Git Integration.