Anti-Abuse & Rate Limiting (防薅羊毛策略)

Use this strategy to design, implement or review a product's free quotas and rate limits. Users can pass parameters to apply only some sections: --registered, --visitor, --rate-limiting, --captcha; without parameters, all sections apply.

1. Core Principles

• Control costs: Giveaways are a customer acquisition tool. They must be affordable, and they must not be farmed to death.
• Revocable at any time: Free quotas and benefits must be adjustable and withdrawable at any time, and accounts that violate the rules can be banned directly.
• Tiered controls: Normal users' experience is unaffected; only malicious bulk requests are strictly limited.

Before you start, list every entry point in the product that gives something away (sign-up bonuses, visitor trials, daily check-in, invite rewards, free model calls), then add protections to each one following the sections below.

2. User Identity and Device Identification

Registered User Identification (--registered)

• Limit or prioritize trusted email providers, such as Gmail or GitHub accounts.
• Perform secondary verification on ordinary or arbitrary email addresses, or set a sign-up threshold.

Visitor Device Identification (--visitor)

• Use a browser device fingerprint similar to FingerprintJS, and authenticate on the backend: check how many times this device has been used today, and do not trust the frontend alone.
• Incognito mode: directly refuse registration, and do not grant visitor bonuses.
• After the limit is exceeded, force a login or sign-up window to appear.

3. Sign-Up and Login Security Protection

Request Rate Limiting and Cooldown (--rate-limiting)

• Set cooldown periods and rate limits for sign-up, login, password recovery and email verification code (OTP) requests.
• If the same IP address makes consecutive sign-up attempts within a short time (for example, within one minute), block them.

Human Verification (--captcha)

• Use the free Cloudflare Turnstile widget, enforce verification before critical actions such as form submission and sign-up, and verify the result on the server.
• When encountering crawlers or high-risk scenarios, you can enable the Managed Challenge full-page screen.

4. Business Operations and Model Cost Isolation

Quota and Task Control

• Use a credit or quota system with a "fixed grant + daily or weekly cap", for example a 5-hour limit plus a weekly limit.
• Launch paid plans on day one. Free credits should be earned through tasks such as daily check-in, rather than granting the full amount at once.

Regional Risk Control

• Disable sign-up credits and visitor credits for high-risk regions (for example, Indian IP addresses).
• Alternatively, apply full-screen watermarks to results produced with free credits, and unlock them after payment.

Model and Cost Downgrading

• Route free users to low-cost, lightweight APIs or models.
• Open official and high-performance models to paying users.

5. Execution Steps

1. List all entry points that give something away, as a checklist.
2. Set the quota, cap and cooldown period for each entry point, and confirm these numbers are kept in configuration so changes do not require a release.
3. Add protections item by item following Sections 2 to 4, and for each one, explain which kind of abuse it blocks.
4. Add "withdrawal" switches: the ability to stop issuing bonuses, reset free quotas to zero, and ban accounts.
5. Self-check: try bulk registration using the same device, the same IP and a disposable email, confirm all are blocked, and confirm normal sign-up and login are unaffected.

6. Output Requirements

• First provide the entry point checklist and the protection plan for each entry point, then change the code.
• Mark all numbers (quotas, cooldown periods, caps) clearly as examples, to be determined by the user according to their own costs.
• Do not harm normal users in the name of anti-abuse: for each rule, state what message a blocked user will see.