The self-service plans are tiered by the number of developer seats (Starter up to 5, Team up to 10, Business up to 25). For teams with more than 25 developers there is the Enterprise plan without a seat cap — contact us. To help you choose the right tier when purchasing, here is a precise definition of what counts as a seat and what does not.
What is a seat
One seat license per person who actively uses CodeCharter. Actively means at least one of the following:
- The CLI runs on that person's workstation.
- The VS Code extension is installed on that person's workstation.
- That person regularly commits code to a repository whose pull requests are checked by your CodeCharter integration in CI.
"Regularly" means at least one commit per month as a rule of thumb. One-off contributions from external contributors do not count.
What is not a seat
- CI service accounts. The API key your GitHub Action, GitLab pipeline, Azure pipeline, or similar uses to run CodeCharter is not a separate seat. This is also true if you use multiple service accounts per stage for purely technical reasons.
- Read-only reviewers who review pull requests for content but do not contribute code themselves. Anyone who only reads annotations does not need a seat.
- Engineering managers and product owners who do not commit code.
- QA testers who do not commit code.
- External contractors who contribute a one-off pull request.
Rule of thumb: only someone who writes code or whose machine calls CodeCharter directly is a seat.
What happens if you exceed the threshold?
We do not enforce this technically. You commit in the terms and conditions to switching to the appropriate plan promptly when you reach the next tier. You make the switch yourself in the portal under /account/billing — Stripe prorates the difference for the remainder of the period. If your team shrinks below a threshold, you can downgrade the same way; the downgrade takes effect at the end of the current billing period and is not prorated. More at Plan overview and Cancellation and plan change.
If you are unsure whether you are just below or just above the threshold, feel free to write to us at [email protected]. We will review it together and suggest the appropriate plan.
Rolling out CodeCharter to your team
CodeCharter uses a single-account model: one person on your team purchases the plan through their own portal account, and that account holds the subscription, the license, and the API keys for the whole team. There are no organisation accounts, member invitations, or per-seat assignments in the portal.
After the purchase, the rollout looks like this:
- The buyer downloads the CLI archive with the embedded
codecharter.license, or just the bare license file, from the Downloads page. - Copy the archive or the license file to every developer machine that should use CodeCharter, up to the seat count of your plan. The license file is not bound to a machine, so the same file works everywhere — see License file.
- For CI, create an API key in the buying account and store it as a
pipeline secret (
CODECHARTER_API_KEY) — see API keys in secrets.
Your colleagues do not need portal accounts of their own. If they register one anyway, that account only ever carries its own 7-day trial; it cannot be attached to your paid subscription. Keep license downloads, plan changes, and API keys with the buying account.
Seat counts are trust-based
CodeCharter does not track your usage by default — anonymous telemetry is strictly opt-in (see Telemetry). By default the CLI sends nothing back, and your source code and findings never leave your machine; in CI the CLI contacts the portal only to fetch its short-lived license. The VS Code extension sends no usage data either. Seat counts are trust-based: pick the tier that matches your team and upgrade anytime you outgrow it.