We Won $1,000 in AI Credits. Then Lost It to Trial Abuse Over the Weekend

We won about $1,000 in AI credits from a hackathon.

Then lost almost all of it to trial abuse over the weekend.

The painful part?

Our bot noticed.

It just could not act yet.

That is the story. Not a story about why free trials are bad, but a story about why detection needs a path to action.

The $1,000 Weekend

A few days earlier, we made our trial easier to start: no credit card upfront, less friction, faster path to the product.

That was intentional. For us, free trials are part of the marketing budget: a way for real teams, especially companies, to evaluate the product without budget or procurement blocking day one.

The risk was obvious in hindsight. Free access to expensive AI models became easier to try, which was the point. It also became easier to farm, which was not.

Then sign-ups jumped to about 30x normal.

For a few minutes, the dashboard looked beautiful. Sign-ups up, usage up, growth apparently working.

Then we looked closer. This was not demand. It was farming.

Free Trials Were Not the Problem

After digging around, we found the source.

A link had been dropped in a community, framed less like “try this product” and more like “farm these AI credits.”

That distinction matters. We were not upset that people used a promotion. The trial existed for that. The issue was coordinated abuse of a budget meant for legitimate evaluation.

Some users created fake business identities, worked around basic checks, and ran prompts that were clearly outside the spirit of the trial.

Once that spread, the traffic came in waves.

The useful lesson was not “make trials painful again.” It was “keep the happy path open for real buyers while making coordinated farming hard to scale.”

That also made the response tricky. We needed to stop clear abuse quickly, without blocking legitimate teams.

Detection Was Not Enough

We were not completely blind.

We already had an internal guardrail bot watching for suspicious new users. It noticed odd signup patterns, summarized what looked wrong, and put the evidence in front of us.

That helped. A human did not have to start from raw logs.

But that was the gap: we had detection, not an operator workflow.

The bot could say, “these new users look suspicious.” It could organize the evidence. But it could not verify signals, apply a response rule, block high-confidence abuse, escalate ambiguous cases, or leave an audit trail.

So it waited for a human to wake up. Credit farmers do not wait for that.

By the time we paused trials and banned the obvious farming accounts, those accounts had already burned through around $1,000 in credits.

That number hurt because it was almost exactly the amount of Anthropic credits I had just won from the hackathon. Posting about winning third place and then immediately writing about losing the prize credits was not the content calendar I had in mind.

So we turned the response into a reusable Runbear workflow:

detect suspicious orgs and usage patterns

summarize the evidence

apply the response rule

block high-confidence abuse

leave a report trail for the team

That part worked.

The credits were already gone, but the response workflow is now reusable. When a new farming pattern shows up, we can add a rule, apply it, and move on instead of rebuilding the whole response process from scratch.

The Workflow We Built After

After the blocks started working, we saw messages in the abuse channels saying things like “it seems blocked overnight” and “it does not work anymore.”

The Lesson

That was probably the first moment we relaxed a little. Then someone joked that since they had promoted us, maybe we should pay them. I respect the audacity. I do not respect the invoice.

If your product has free trials, usage credits, or access to expensive AI models, abuse prevention cannot just be a dashboard someone checks later.

Detection matters. But detection without fast action is still a delay. In an abuse incident, that delay has a dollar amount attached to it.

I do not think every bot should swing a ban hammer freely. But a carefully scoped operator with conservative rules can do more than observe. It can protect the system while the team sleeps, and still leave humans in charge of the edge cases.

This is the kind of internal workflow we think agents should handle: not replacing judgment, but turning clear operational rules into fast, reviewable action.

That is the direction we are building toward with Runbear.

Not because every incident can be prevented, but because losing credits is a much worse way to learn incident response than reading someone else’s weekend story.

If your team is reviewing abuse signals manually, Runbear can help turn detection into a scoped operator workflow: verify, escalate, block, and audit.