You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
I’ve already spent more than $500 on credits and got a ban for 52,000 seconds just for turning on the VPN. #49728
Yesterday, I worked with the free big pickle model for about 3–4 hours before lunch, then I exhausted the limit and went to do other things. When I came back in the evening, there were 2000 seconds left until the limit reset, but it was already very late, so I went to bed. When I woke up and sat down at my computer, I immediately turned on the VPN — Psiphon — and my IP address changed to French. Then I turned on Opencode and wanted to continue from where I left off yesterday, so I wrote “continue” in the chat, but I was very surprised when I immediately received a new limit on “Free Use”. Exceeded, subscribe to repeat in 50,459 seconds — attempt # 1. How is this possible? Is it just because I turned on the VPN and my IP changed? That’s complete nonsense. I got the restriction because of a bug in your system, which decided that I was deceiving it.
Follow-up: paying user blocked by free-tier IP heuristic — proposal for a targeted fix
Hi team, I want to add context and a concrete proposal, because I don't think this is an isolated case.
What happened
I'm a paying user with $500+ in credits.
I was using the free Big Pickle model and hit the daily free-tier limit.
The previous restriction (52,000 seconds) had already expired.
This morning I connected a public VPN (Psiphon), which changed my IP to France.
On the very first request I received a new 52,000-second restriction on the free tier — with no prior abuse, no multiple accounts, no attempt to bypass anything.
So the restriction was triggered solely by an IP change, not by actual abuse. For a paying user, that means losing a full working day for a non-violation.
Why this matters beyond my case
Free-tier anti-abuse is usually IP-based because it's cheap and catches most abusers. But IP-based heuristics produce a well-known class of false positives:
users on public VPNs, corporate proxies, CGNAT, or mobile networks,
users in regions where a VPN is required for basic connectivity,
users who switch networks between sessions (home / office / mobile).
All of them look identical to an abuser from the IP signal alone. The result is that the people most likely to convert into paying customers — active, mobile, technically engaged users — are the ones most likely to be falsely flagged.
Proposal: make the free-tier heuristic account-aware, not just IP-aware
A few small changes would eliminate most false positives without weakening anti-abuse:
Trust score by account age + balance.
If an account has a positive credit balance and a history of legitimate usage, do not apply the free-tier IP restriction on IP change. Instead, fall back to a normal rate limit. Abusers with stolen cards get caught by payment verification; legitimate payers shouldn't be punished by an IP heuristic.
Distinguish "IP change" from "IP abuse."
A single IP change from a known VPN/proxy ASN should be a soft signal, not a hard ban. Reserve the 52,000-second tier for patterns: many distinct IPs in a short window, datacenter ASNs in sequence, or new-account + IP-change combinations.
Give paying users a self-serve unblock.
If an account has a positive balance, allow it to bypass the free-tier restriction immediately (with a rate limit). Manual support tickets for a 14-hour timer is a bad experience for someone who is literally paying you.
Verification instead of punishment.
For flagged accounts, offer email / 2FA / payment-method verification as an alternative to the timer. A verified payer is not the threat model the free tier is designed to stop.
Expose the reason in the error message.
"Free tier limit exceeded" is misleading when the real cause is an IP change. A message like "IP change detected on free tier — verify to continue or use a paid model" would have saved me and your support team a lot of time.
Please consider the account-aware logic above. It protects revenue, reduces support load, and stops punishing the exact users you want to keep.
Happy to provide screenshots, credit history, and timestamps if that helps. Thanks.
Thanks for reaching out, and sorry this didn't get a reply sooner.
We don't handle billing, account or usage-limit support in GitHub issues. The app only shows the error the OpenCode service returns, and the reason for a limit or a billing problem can only be checked in the service's own records. Please email help@anoma.ly about this. If you've already emailed that address, please reply in the same thread with anything new.
Please keep payment details, email addresses and account information out of this public issue and put them only in the email. We'd suggest editing this issue to remove any you've shared here.
Closing this issue, since support will continue over email.
Activity
lodpol commentedon Sep 18, 2026
Follow-up: paying user blocked by free-tier IP heuristic — proposal for a targeted fix
Hi team, I want to add context and a concrete proposal, because I don't think this is an isolated case.
What happened
I'm a paying user with $500+ in credits.
I was using the free Big Pickle model and hit the daily free-tier limit.
The previous restriction (52,000 seconds) had already expired.
This morning I connected a public VPN (Psiphon), which changed my IP to France.
On the very first request I received a new 52,000-second restriction on the free tier — with no prior abuse, no multiple accounts, no attempt to bypass anything.
So the restriction was triggered solely by an IP change, not by actual abuse. For a paying user, that means losing a full working day for a non-violation.
Why this matters beyond my case
Free-tier anti-abuse is usually IP-based because it's cheap and catches most abusers. But IP-based heuristics produce a well-known class of false positives:
users on public VPNs, corporate proxies, CGNAT, or mobile networks,
users in regions where a VPN is required for basic connectivity,
users who switch networks between sessions (home / office / mobile).
All of them look identical to an abuser from the IP signal alone. The result is that the people most likely to convert into paying customers — active, mobile, technically engaged users — are the ones most likely to be falsely flagged.
Proposal: make the free-tier heuristic account-aware, not just IP-aware
A few small changes would eliminate most false positives without weakening anti-abuse:
Trust score by account age + balance.
If an account has a positive credit balance and a history of legitimate usage, do not apply the free-tier IP restriction on IP change. Instead, fall back to a normal rate limit. Abusers with stolen cards get caught by payment verification; legitimate payers shouldn't be punished by an IP heuristic.
Distinguish "IP change" from "IP abuse."
A single IP change from a known VPN/proxy ASN should be a soft signal, not a hard ban. Reserve the 52,000-second tier for patterns: many distinct IPs in a short window, datacenter ASNs in sequence, or new-account + IP-change combinations.
Give paying users a self-serve unblock.
If an account has a positive balance, allow it to bypass the free-tier restriction immediately (with a rate limit). Manual support tickets for a 14-hour timer is a bad experience for someone who is literally paying you.
Verification instead of punishment.
For flagged accounts, offer email / 2FA / payment-method verification as an alternative to the timer. A verified payer is not the threat model the free tier is designed to stop.
Expose the reason in the error message.
"Free tier limit exceeded" is misleading when the real cause is an IP change. A message like "IP change detected on free tier — verify to continue or use a paid model" would have saved me and your support team a lot of time.
Please consider the account-aware logic above. It protects revenue, reduces support load, and stops punishing the exact users you want to keep.
Happy to provide screenshots, credit history, and timestamps if that helps. Thanks.
IntellsGamer commentedon Oct 12, 2026
Iranian?
Tarquinen commentedon Oct 20, 2026
Thanks for reaching out, and sorry this didn't get a reply sooner.
We don't handle billing, account or usage-limit support in GitHub issues. The app only shows the error the OpenCode service returns, and the reason for a limit or a billing problem can only be checked in the service's own records. Please email help@anoma.ly about this. If you've already emailed that address, please reply in the same thread with anything new.
Please keep payment details, email addresses and account information out of this public issue and put them only in the email. We'd suggest editing this issue to remove any you've shared here.
Closing this issue, since support will continue over email.
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊