Free tier · meeting Oct 20

Halving free-tier spend by tomorrow

The free tier costs about $117K a day, and the goal is $50–60K by tomorrow. The rules shipped so far haven't moved the daily number. Below are four proposals and the math for each.

goal $50–60K
yesterday $117K
$117K
free-tier spend yesterday (recent days $111–142K)
~2M
unique free-tier IPs a day, nearly double two weeks ago
$0.77
average cost of a user who maxes out 500 requests
1% → 35%
IPs over 600 requests a day, and their share of tokens
The shape of the problem

1% of IPs use 35% of the tokens

Each grid is 100 squares. The red squares are IPs that send more than 600 requests a day.

Share of IPs
1%
Share of tokens
35% ≈ $41K/day

Removing this whole group saves about $41K. The gap is $60K. Rules aimed only at heavy users can't close it, so the fix has to reach the other 65% of spend too.

Proposal 1

Cap dollars per user, not requests

Today every request counts as 1, whether it's a cached 5K-token call or an uncached 150K-token call. With a daily cap of about $0.75 in real cost, uncached requests, huge contexts and tiny outputs use up the budget faster on their own. That one change covers most of the 50 rules.

illustrative numbers
Real developer3–4 hrs, mostly cache hits
requests
our cost
Abuserspoofed client, uncached, big context
requests
our cost

Frank's concern: the free tier should feel like a few hours of real work a day. A dollar budget can match that. Measure what a typical 3–4 hour cached session costs and set the budget above it, so real users never hit it.

The idea was raised twice in the meeting. Frank suggested counting uncached requests as 10. Daniel noted that "we're not capping on tokens." Nobody proposed replacing the request cap outright.

Proposal 2

Apply every rule from existing logs

Daniel's objection is that rules only drain abusers slowly. That happens only when counters start at zero. Seed them from yesterday's and last month's logs, and anyone who already broke the rule is capped at tonight's reset. The monthly cap already worked this way: about 5,000 users hit it right away.

$117K today goal ~$57K day 0 day 14 counters start at zero: slow drain seeded from logs: drop at tonight's reset curve shape illustrative
Proposal 3

A rule simulator that answers Frank in dollars

Write one query over yesterday's logs with a row per rule: dollars saved, users affected, and the share of normal-looking users hit. Show marginal savings, applying the rules in order. Rules overlap, so 50 rules at $1K each won't add up to $50K. Ship from the top until the total reaches $60K.

Known savings so far
Bar = the $60K gap. Solid = known, striped = measured range. Dashed rows still need numbers.
Proposal 4

Stop using IP as identity

Free-tier IPs nearly doubled in two weeks while spend stayed flat. That looks like rotating proxies, and every per-IP limit loses to them. Carryover rules help, but they're catch-up.

Unique free-tier IPs a day
~1M
~2M
2 weeks ago
now
  • Require login for the free tier. For example a GitHub account a few months old, limited per account.
  • Ramp new identities up slowly. About 50 requests on day 1, the full limit after a week.
  • Block datacenter IP ranges. Cheap and same-day.
  • Swap models past the cap instead of blocking. Real users keep working; abusers get little of value.
Why the order matters

This is an arms race, so cap first and hunt second

Daniel said it himself: "all they have to do is put it into a prompt." Every pattern rule has a half-life. Abusers ask their own agent to vary timing, cache use and fingerprints, and a week later the pattern is gone. The search so far hasn't found a single signal worth 20% of tokens, so waiting for one is the slow path.

Pattern rules
  • Decay. Each one stops working once abusers adapt.
  • Small. Most save 0.3–3% each. Adding them up takes many rules.
  • Need constant upkeep. Someone keeps hunting forever.
Cost budget + identity
  • Hard to dodge. You can't fake costing us less.
  • Works today. No waiting for a signal to show up in the data.
  • Rules stack on top. Use them to raise the cap for real users.

A worry raised in the meeting: lowering the cap now makes abuse patterns harder to see. One fix is to keep logging requests that get blocked. Then the agents searching for patterns still have the full traffic to work with.

Signals already spotted, worth a row in the simulator: "no human pauses" (a request every 2–3 seconds for hours), the prompt and working-directory fingerprints, and one surprise: users sending 50 requests a day often look less human than heavy users. The hurricane-group ban cut about a third of one model's new traffic in a single move, so it's worth looking for more clusters like that before tuning thresholds.

The "1% of IPs = 35% of tokens" figure wasn't agreed in the meeting; it may really be the 99th percentile. Check it before relying on the $41K estimate above.

Also

Turn the cap into revenue

About 80% of enterprise inbound is companies trying to buy packs of Go subscriptions. When a heavy free user hits the cap, offer Go or Go for Teams instead of just an error.

What to say

One sentence for the room

Ship a $0.75-a-day cost budget tonight, seeded from yesterday's usage. In parallel, run the rule simulator so each extra rule comes with a dollar figure before it ships.