Is Gryndel worth it?
Sooner or later someone asks "is Gryndel worth it?". This guide shows which numbers answer that, where to find them, and a short monthly routine that keeps the answer up to date and turns it into improvements.
Before you start: anyone in the workspace can open Reports and Costs. Acting on what you find (changing settings, rules or agents) needs a workspace admin.
What "worth it" means
Gryndel's value is problems found before merge, at a cost in money and in people's attention. Measure all three:
| Question | Where | Number |
|---|---|---|
| Does it find things people act on? | Reports | Acceptance, Fixes applied |
| Does it waste people's time? | Reports | Rejected (dismissed and disputed), Left open |
| Does it find serious problems? | Reports, Acceptance by → Severity | Accepted P0 and P1 findings |
| What does it cost? | Costs | Total cost for the period |
| Does it slow merges down? | Reports, Usage | Review time (median and 90%) |
How Gryndel decides a finding was useful
Gryndel reads each finding's thread back from GitLab or GitHub about every 10 minutes while the merge request (GitLab) or pull request (GitHub) is open, and once more when it's merged or closed:
| Outcome | What happened | Counts as |
|---|---|---|
| Fix applied | The suggested fix was applied. GitLab only: GitHub doesn't report applied suggestions, so there a committed suggestion counts as Resolved once its thread is resolved. | Accepted |
| Resolved | The thread was resolved, by a person or by @gryndel check. | Accepted |
| Dismissed | Someone replied @gryndel ignore this. | Rejected |
| Disputed | More 👎 than 👍 on the finding. | Rejected |
| Left open | Merged or closed with the thread unresolved. | Decided, not accepted |
| Open | The merge or pull request is still open. | Not counted yet |
Acceptance is accepted findings out of all decided ones. Keep its limits in mind:
- A resolved thread usually means someone fixed the problem, but people sometimes resolve threads just to tidy up.
- Left open is ambiguous: the finding may have been ignored, or fixed without anyone resolving the thread.
- Recent weeks are incomplete, because findings on open merge or pull requests aren't counted yet.
- On GitHub, Fixes applied stays at zero; compare GitHub repositories by Acceptance instead.
These numbers are only as good as the team's habits. Ask developers to respond to every thread; see Respond to Gryndel's findings.
The monthly review
Put 30 minutes in the calendar once a month, with whoever owns Gryndel and one or two developers.
1. Collect the numbers
- Open Reports and choose 30 days. Click Refresh to read the latest outcomes from GitLab or GitHub.
- Write down Acceptance, Fixes applied, Rejected, Left open · still open, and from Usage: Reviews, Findings posted and Review time.
- In Acceptance by, choose Severity and note how many P0 and P1 findings were accepted.
- Open Costs, choose 30 days, and note the total.
- Optional: on Reports, click Export CSV under Findings to keep the list of findings and outcomes for the month.
Keep the numbers in a simple table, one row per month, so you can see trends.
2. Work out the ratios
| Ratio | How | Tells you |
|---|---|---|
| Cost per review | Cost ÷ Reviews | Whether reviews are getting more or less expensive |
| Cost per accepted finding | Cost ÷ accepted findings | What one useful finding costs you |
| Serious problems caught | Accepted P0 + P1 findings | The headline value: bugs that would otherwise have reached review or production |
For example (illustrative numbers): a month with 400 reviews, 120 accepted findings, of which 15 were P0 or P1, and a cost of $60, is $0.15 per review, $0.50 per accepted finding, and 15 serious problems caught before merge. Compare that with what one production bug costs your team.
If your model provider has no prices set, Costs shows $0 for it. Enter prices in Model settings to get a real figure. A price you enter also applies to earlier usage.
3. Look for where it isn't working
On Reports, switch Acceptance by between Repository, Category and Agent.
| You see | Action |
|---|---|
| One repository with low acceptance | Tune that repository. See Make Gryndel quieter and more accurate. |
| One category mostly rejected | Raise the severity threshold, or write a rule saying not to report it. |
| One agent mostly rejected | Check its Efficiency on Review agents and improve its prompt. |
| Many Left open | Remind the team to respond to threads, or lower the comment level. |
| Failures under Usage | Fix the cause. See Investigate a review. |
| Review time going up | See Control costs. |
4. Ask the people
Numbers don't capture everything. Ask the developers present:
- Which findings this month were genuinely useful?
- Which were annoying?
- Did Gryndel slow anyone down?
5. Decide one or two changes
Pick at most two changes for next month, such as a new rule, a different comment level, or a cheaper model for one agent. Write down what you changed and when, so next month you can tell whether it helped.
Comparing teams
If you have several workspaces, All workspaces compares cost, reviews, failures and findings across them, and exports the comparison with Export CSV. Acceptance is per workspace, on each workspace's own Reports page.
Signs it's working, and signs it isn't
| Healthy | Worth a closer look |
|---|---|
| Acceptance is steady or rising | Acceptance falling month after month |
| Accepted P0 and P1 findings most months | Mostly P2 findings accepted, few serious ones |
| Few disputed findings | Many disputed findings, or developers asking to turn it off |
| Cost per review stable | Cost per review rising without a reason |
| Reviews finish before people start human review | Reviews routinely finish after the merge |
No accepted P0 findings in a month isn't necessarily bad: it may mean the code was good. Look at the trend over several months, not one.