Control costs
Every review sends code to a model, and most model providers charge per token (a small piece of text, roughly a few characters). This guide shows you where your money goes, then the levers that reduce it, from the biggest to the smallest, and what each one costs you in review quality.
Before you start: anyone in the workspace can see costs. Changing models, agents and settings needs a workspace admin.
1. Make sure the costs are real
Gryndel works out costs from prices per model. A model without a price counts as $0, so an unpriced model can make costs look lower than they are.
- Open Costs (sidebar, under MANAGE).
- Under each model, check where its price comes from. No price: counted as $0 means nobody has priced it.
- For each unpriced model you pay for, open Model settings, edit its provider, and under Prices per model click Add a model price. Enter Input $/1M and Output $/1M from your provider's price list, then save.
Some providers publish their prices and Gryndel uses them until you enter your own. A price you enter also applies to earlier usage, so the history is corrected too. A self-hosted model may really cost $0 per token; its cost is the hardware it runs on.
2. See where the money goes
| Question | Where to look |
|---|---|
| Which providers and models cost the most? | Costs: the model table starts with the most expensive. Compare Calls, Reviews and tokens. |
| Which reviews cost the most? | Pull requests: click the Cost column heading to sort by it. |
| Which repository costs the most? | Pull requests: pick a repository in All repositories and sort by Cost. |
| Which step of a review costs the most? | Open the review and click Cost in its details. It lists each step with its provider and model. |
| What will a review cost before it runs? | The review's Change profile shows an Estimate. It says Not available when the repository uses Don't keep code. |
| Which workspace costs the most? | All workspaces. |
Look for patterns: one repository with huge merge requests (GitLab) or pull requests (GitHub), one agent on an expensive model, or reviews of generated files.
Costs also include @gryndel commands that use the model (check, explain and
questions), and failed or cancelled reviews.
3. Pull the levers
Start with the levers at the top of this table. They save the most.
| Lever | Typical saving | Trade-off | Where |
|---|---|---|---|
| Cheaper model | Large. Prices differ by ten times or more between models. | Weaker models find less and are wrong more often. | Model settings |
| Cheaper model for some agents | Medium to large, in Agents mode | Only that agent's quality changes. | Review agents |
| Review mode | Large for repositories in Agents mode | Fewer specialist reviewers, or no verification | Configure → Reviews |
| Fewer agents | Medium, in Agents mode | Less coverage of the areas you drop | Configure → Reviews → Review agents, or Review agents |
| Excluded paths | Small to large, depending on the repository | None, if you only exclude code nobody writes by hand | Configure → Scope |
| Max files and Max context chars | Medium on large merge or pull requests | Files that don't fit aren't reviewed | Configure → Scope |
Models
The model is usually the biggest cost. Options:
- A cheaper model on the default provider. The default provider runs single and verified reviews, coordinates and verifies agent reviews, and answers commands. Edit it in Model settings and choose another Default model.
- A cheaper provider. Prices for the same model can differ between providers. You can add up to twenty providers and choose which is the default.
- A self-hosted model. An OpenAI-compatible provider can point at a model server your organisation runs. You pay for the hardware instead of per token, and the code doesn't leave your network.
Before switching everything, try the cheaper model on one repository's reviews for a week and compare acceptance on Reports. A cheap model that's wrong half the time costs more in people's time than it saves. Use Test connection to check a new model can return structured results before you use it.
Agents
In Agents mode each agent is one or more model calls, and each agent can use its own provider and model.
- Open Review agents and compare Used in reviews with Efficiency.
- For agents that do simple work, such as Styles or Code structure, set a cheaper Provider or Model in the agent's panel.
- Keep stronger models for Security and Bugs & regressions, where accuracy matters most.
- Untick Enabled for agent reviews for agents you don't need anywhere, or limit a repository to the agents it needs under its Review agents setting.
Agents at once in Model settings changes how many agent calls run at the same time. It affects speed, not cost.
Review modes
| Mode | Model calls | Use for |
|---|---|---|
| Single pass | Fewest. The model reviews the change once; findings aren't verified. | Low-risk repositories where cost matters more than precision |
| Verified · draft and verify (default) | More: drafting, then a verification step | Most repositories |
| Agents · specialist reviewers | Most: choosing agents, each agent, combining, then verification | Critical code. See Stricter reviews for critical code. |
A good split: Verified in Organization settings for everything, Agents only on the repositories that need it.
Exclusions and limits
Generated code, lock files, vendored libraries, snapshots and fixtures cost tokens and rarely produce useful findings. Add them to Excluded paths in the Scope tab, one pattern per line:
vendor/**
**/generated/**
**/__snapshots__/**
**/*.min.js
tests/fixtures/**
Exclusions from Organization settings and the repository add up, so put the common ones at the organization level.
Max files (1 to 80, default 80) and Max context chars (default 400,000) cap how much
of a large merge or pull request is reviewed. When a change doesn't fit, Gryndel reviews source code
first, then tests, then documentation, and leaves lock files and generated output for last.
Left-out files show as a grey +N on Pull requests and lower Review confidence. Lower
these limits if very large merge or pull requests drive your costs, and accept that those
get a partial look.
4. Check the effect
Settings apply to reviews created after you save. After a week:
- On Costs, compare the cost and calls with the week before.
- On Reports, check Acceptance didn't drop. If it did, you cut too deep: put back the lever that hurt quality most.
Combine this with the monthly routine in Is Gryndel worth it?.
If it didn't work
| Problem | Cause | Fix |
|---|---|---|
| Costs didn't go down | The changed setting is overridden | Check Effective configuration → Preview for the repository. |
| Costs show $0 but you're paying | The model has no price | Add it under Prices per model (step 1). |
| A cheaper model fails reviews | It can't return structured results, or its context window is too small | Run Test connection, and see Investigate a review. |
| An agent stopped running | Its provider is disabled | The agent shows Inactive: provider disabled. Enable the provider or pick another. |