mirror of
https://github.com/KeygraphHQ/shannon.git
synced 2026-04-25 09:35:55 +03:00
[GH-ISSUE #36] resume later when reaching limits with Claude OAuth #8
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/shannon-KeygraphHQ#8
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @resident-ngo on GitHub (Dec 22, 2025).
Original GitHub issue: https://github.com/KeygraphHQ/shannon/issues/36
Claude Pro has some aggressive limits that are easily hit. It seems that some modules like SSRF can detect that limits were hit:
But then it tries to move forward - all the validations fail and final report is empty.
In other cases we can see no deliverables produced and it still tries to execute steps doomed to fail:
To reproduce the issue you can use Claude OAuth token and use any huge repo like existing Wordpress installation with some plugins.
The desired behavior is to pause the work, wait for the time when limits are reset and continue, ideally retrying failed jobs.
P.S. Awesome product, thank you so much for making it available for free for small security initiative and individuals! Many organizations have Claude Pro subscription, but can't afford to pay 50$ per run. From other hand they are very patient, so it is ok for them to wait for 12-24 hours for analysis and tests to finish.
@keygraphVarun commented on GitHub (Jan 18, 2026):
Sorry for the late reply! And thanks for the kind words, that's what makes OSS work worthwhile.
The "detect rate limit → wait for reset → resume" flow you're describing makes a lot of sense, especially for users on Claude Pro users who are happy to wait for limits to reset rather than burn through failed retries.
Quick update: we recently landed a big refactor using Temporal for durable execution, which gives us the foundation to support something like this. Can't promise if or when we'll build it, but I've added it to the backlog.
(Cc: @ajmallesh )
Thanks again for the detailed write-up!