Labels describe and configure. They never spend money by themselves — actions come from commands and review requests.
A label tells me how to work. It doesn’t tell me to start.
Agent fix is comment-driven. The old plan / todo trigger labels are gone — applying them does nothing. See the agentic workflow.

​
The label set

Tier precedence. The command’s own tier (@codaban handle fast) wins. A tier label is only an optional modifier on top of it. Codaban auto-suggests a tier after drafting a plan — it asks a small model to bucket the plan’s complexity — but never overrides a tier you set yourself. On collisions, the cheaper tier wins.

​
Provisioning

Codaban creates its user-applicable labels automatically on the first issue opened in a repo it watches. That’s the earliest moment it can know the repo exists — there is no “installed into repo” webhook on Forgejo.
  • Forgejo repos get the full set above.
  • GitHub repos get only the tier labels and the review-control labels: junior, middle, senior, codaban:deep-review, codaban:auto-review, codaban:no-auto-review. The change-type labels stay Forgejo-only — GitHub repos have their own labeling cultures.
Change-type labels (feat / fix / …) are not pre-provisioned. Codaban creates the one it needs on demand when it opens a PR.
Provisioning only ever creates labels — it never deletes or modifies ones you already have, and name matching is case-insensitive, so your existing Plan label won’t be duplicated.
One GitHub constraint worth knowing: label descriptions are capped at 100 characters, and custom labels beyond that limit are rejected by GitHub.