A spent plan no longer fails the check
A used-up plan no longer turns your pull request red.
A used-up plan no longer turns your pull request red. Until now, an expired token or a spent Claude plan failed the explainer job, and a contributor saw a red check they could do nothing about. In version 1.8.0 the same run passes with one warning and publishes nothing.
An expired token leaves a note, a usage limit leaves none
An expired token leaves a note. A usage limit leaves no comment.
The new refused output says which of the two happened. If the provider turned down the key, the run passes and leaves one line on the pull request, naming the secret to replace. If the plan is out of usage, the run passes and leaves no comment at all, because a limit clears on its own. A later step can read the output to tell them apart.
Only the provider's last answer decides
The run ends green only when the provider's last answer was a refusal.
if (status === 401 || status === 403) return "auth"; if (status === 402 || status === 429) return "limit";
const last = lines.trim().split("\n").pop() ?? "";Here is how it decides. The key proxy now records the status of every response from the model provider, and never the body, which can quote the key. A 401 or 403 counts as auth. A 402 or 429 counts as limit. When the agent then fails, the action reads the final recorded line. A rate limit the run retried through, followed by a failure for some other reason, still fails the check.
Public explainer comments count their views
The comment now shows how many times it was watched.
On a public repository, the explainer comment now shows how many times it has been watched. The count sits beside the link as an image that is drawn fresh on each fetch, so it keeps climbing long after the run has finished. Until the first view, it stays blank.
Your checks read differently now
Your checks read differently now.
refused output when you need to know.A passing check no longer promises an explainer, so read the refused output when you need to know. Release runs are the exception. A refused key there still fails, because the person who sees that check is the maintainer who can fix it. And any 401 or 403 from the provider counts as a refused key, whatever the cause.
Upgrade without changing your workflow
Upgrading needs no change to your workflow.
The release adds an output and changes no inputs, so pointing your workflow at version 1.8.0 is the whole upgrade. If a run warns about auth, replace the secret the note names and re-run the job. If it warns about a limit, re-run once the limit resets.
A used-up plan no longer fails a pull request's checks
A used-up plan no longer fails a pull request's checks.
That is version 1.8.0. A used-up plan no longer fails a pull request's checks. The one reason to hold off is a workflow that depends on a red check to tell you a key expired. For an expired key the check now passes, and the note on the pull request is where you find out. The full release notes are on the project's releases page.
