Chapter 10 of 15

Separate Customer Value From Abuse and Waste

High usage is not automatically bad. A power customer may be exactly what I want. The problem is high spend without corresponding value: bots, leaked API keys, accidental loops, repeated failed requests, scraping, free-tier abuse, or workflows nobody uses after generation.

  • Abuse patterns
  • Rate limiting
  • Free-tier economics
  • Anomaly detection
  • Waste versus valuable heavy usage

The situation

AI endpoints are economically sensitive in a way normal CRUD endpoints are not. A burst of traffic can translate directly into third-party charges, even if the traffic never becomes a paying customer.

The naive solution

Use normal web rate limiting and assume authentication is enough.

The hidden constraint

Ten legitimate requests can cost more than ten thousand cheap application requests. Limits therefore need to understand economic weight, not only request count.

The decision

Protect high-cost actions with usage-aware abuse controls. I want to distinguish a valuable customer intentionally doing a lot of work from automated or accidental consumption that produces no business outcome.

The implementation

Controls can include verified accounts for expensive features, free-tier daily or monthly allowances, per-user and per-organisation rate limits, spend-weighted throttling, concurrency limits, API-key restrictions, bot controls, and anomaly detection on cost velocity. I would also separate production, demo, staging, and internal testing budgets so test traffic cannot quietly inflate customer economics.

The tradeoff

Aggressive controls can block legitimate power users. This is why anomaly handling needs context and override paths rather than a single hard global threshold.

The evidence I would look for

I would monitor spend with no subsequent product engagement, repeated failures, unusually high cost velocity, many accounts sharing behavioural fingerprints, and large gaps between free consumption and conversion.

The reusable lesson

Rate-limit economic exposure, not just HTTP traffic.

The consultant's questions

  • What is the maximum free AI cost one unverified account can create?
  • Can internal testing be separated from customer spend?
  • Are limits based only on request count or on the cost of those requests?
  • How would you identify a leaked key or runaway automation within an hour rather than at month end?