Skip to content

I’ve already spent more than $500 on credits and got a ban for 52,000 seconds just for turning on the VPN. #49728

Closed as not planned

Description

@lodpol

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.

Image

Activity

  1. lodpol commented on Sep 18, 2026

    @lodpol
    Author

    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.

  2. IntellsGamer commented on Oct 12, 2026

    @IntellsGamer

    Iranian?

  3. Tarquinen commented on Oct 20, 2026

    @Tarquinen
    Member

    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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions