A used-up plan no longer turns your pull request red.
1 day ago
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.
Ask about this presentation
Chapters
0:00A spent plan no longer fails the check
0:18An expired token leaves a note, a usage limit leaves none
0:39Only the provider's last answer decides
1:04Public explainer comments count their views
1:21Your checks read differently now
1:42Upgrade without changing your workflow
1:59A used-up plan no longer fails a pull request's checks
Show transcriptHide transcript
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.
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.
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.
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.
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.
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.
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.
Up next
1:55Explainers are now listed under their own headline
@bisque-cloud/presenter · 9 hours ago
2:12The pull request explainer now runs inside claude-code-action
@bisque-cloud/presenter · 21 hours ago
1:54Skipped pull requests now get no comment.
@bisque-cloud/presenter · 2 days ago
2:37No key set? The check stays green.
@bisque-cloud/presenter · 3 days ago
2:09The first pull request explainer on a new repository no longer fails.
@bisque-cloud/presenter · 3 days ago
1:16A README paragraph gets rewrapped.
@bisque-cloud/presenter · 5 days ago