The job succeeded. There was no error and no retry, just a valid MP4 of a blonde woman in a pink shirt. The dog wasn't in it, and the full price had been charged.

The same customer also tried a dog photo on another of my tools, built on a different pipeline. That one came out right, with the correct markings and the correct moves, apart from the dog facing away for the first second.

So neither pipeline had a bug. I'd picked the model behind the first tool because, in my tests, it kept a person's face better than the others. It's only built for people, and it doesn't refuse when you hand it something else. The model that handled the dog well had lost people's faces in those same tests.

One model couldn't do both, so photos needed routing. The fix went live the same day. Here's how it works, and where it still gets things wrong.

A face isn't always a person

The plan was to look for a human face in the browser before the job starts, so the check needs no server call and no GPU time. I used an open-source short-range face detector that runs through WebAssembly. It's about 10 MB, so it only loads on first use.

Then I looked at the scores:

With the detector's minimum set to 0.5, the rule "found a face" would have sent both dogs straight back to the pipeline that failed them. So a face only counts as human at 0.7 or above. That line comes from a small set of photos, not a proper calibration, and I'll come back to what that costs.

Look twice, because it's a selfie model

A short-range model expects a face close to the camera. In a head-to-toe photo, the face can be too small to find. So if the whole photo has no confident face, I crop the upper middle (70% of the width, the top 55% of the height) and run the detector again.

"No face" and "couldn't look" are different answers

The detector can fail to load, or take too long on a slow connection. I give up after 15 seconds. If that returned an empty list, it would look the same as "no face", and every visitor on a bad connection would be pushed to the pet route.

So a pass returns null when it couldn't run, and the decision has three outcomes:

type Subject = 'person' | 'character';

const PERSON_MIN_SCORE = 0.7;

function subjectFromFacePasses(
  passes: Array<FoundFace[] | null>
): Subject | null {
  const human = (faces: FoundFace[] | null) =>
    Boolean(faces?.some((face) => face.score >= PERSON_MIN_SCORE));

  if (passes.some(human)) return 'person';
  if (passes.length === 0 || passes.some((faces) => faces === null)) {
    return null;
  }
  return 'character';
}

A confident face on any pass means a person. If a pass couldn't run, null leaves the current choice alone. Only clean passes with no confident face mean a pet or character. It's also a pure function, so I can test it without a browser or a model.

It suggests, and the visitor decides

The result only preselects an option on the form. When it picks the pet route, the page says no human face was found and asks the visitor to switch if that's wrong.

Because detection is async, that creates three timing problems: the visitor can choose before the check finishes, they can swap the photo, or they can click Generate while it's still running. Here's a simplified version of how the component handles them:

function detectSubject(file: File) {
  const token = ++detectToken.current;
  pickedByVisitor.current = false;

  detecting.current = detectSubjectFromPhoto(file).then((found) => {
    if (token !== detectToken.current) return; // a newer photo replaced this one
    if (!found || pickedByVisitor.current) return; // no verdict, or they already chose
    subjectRef.current = found;
    setSubject(found);
  });
}

// When they click Generate:
await detecting.current; // on a slow phone the check may still be running
const subject = subjectRef.current;

The last line reads a ref rather than React state. After the await, the click handler's closure still holds the value from before the check finished.

The route changes more than the model

Each route has its own inputs, reference clip and prompt. A person sends a face crop plus the full photo, and a pet or character sends only the photo.

The server doesn't run the face check. It treats the subject as ordinary user input, checks it against an allowlist, and uses it to work out how many images the job should carry.

Keeping the choice as one subject value paid off later. I've changed the person route's pipeline several times since then, and the check didn't have to change. Two more tools now use the same check.

Where it's still wrong

A later real order showed the limit. The photo was of someone in a costume, with a hat, sunglasses and a small face in the frame. The detector found nothing on the whole photo and scored the head region 0.52, so it most likely went to the pet route by preselection. My logs show the route, not whether the visitor picked it by hand.

That 0.52 sits right next to the dog's 0.53. No threshold can separate those two photos.

The video still came out well. It kept the outfit, hat and sunglasses, and none of the original dancer was left, with some small flaws in the clothing. That's only one order, but it suggests wrong guesses don't cost the same. A dog on the person route was a total loss. A person on the pet route, at least once, was a usable video.

A photo taken from behind goes to the pet route too, since there's no face to find.

I also can't give you an accuracy number. I don't log whether visitors change the suggestion, so I can't see how often it's wrong. I should add that.

What I'd keep from this

• A success status only means the model returned something. A video of the wrong subject looks the same as a good one in your logs.
• Check the input before you pay for the output. A check in the browser costs no GPU time.
• Read the scores before you pick a rule. "Found a face" would have failed on the exact photos that caused the problem.
• Keep "couldn't check" apart from "checked and found nothing". They need different behavior.
• If a check can be wrong, make it a suggestion people can see and change.

If you're interested in the cost side of running a tool like this, I wrote about letting visitors try the generator without an account.

You can see the choice on the Dime Dime Baby AI tool: add a photo and watch which option gets selected.

Have you had to route inputs between models? What did you use to decide? I'd like to hear about it in the comments.

The problem is that an AI video generator isn't a to-do app. Every time someone clicks Generate, I pay a model provider for the GPU time. A free trial with no account means I'm handing out money to people I can't identify. If I get it wrong, one bored person with a script can burn through a month of margin in an afternoon.

So I built a no-signup trial in layers. None of them is clever on its own, and each one can be walked around. Together they make farming the trial slow and boring enough that almost nobody bothers, and they put a hard cap on the worst day I can have.

Here are the six layers, roughly in the order a request hits them.

1. Lock the cost first, then worry about counts

Before thinking about who gets a free generation, I made each free generation as cheap as possible.

The trial locks exactly the settings that cost money:

• the lowest resolution
• the shortest clip length
• one clip per request (and one image per request for images)
• a cheap, fast model instead of the premium ones

Everything that doesn't change the bill stays the visitor's choice. Aspect ratio, for example, costs the same either way, so a guest can still make a vertical video for TikTok or a widescreen one for YouTube. A trial that's cheap and useless doesn't convert anyone.

The server enforces all of this. It clamps whatever it has to and ignores the rest. The client mirrors the same limits so the locked options are greyed out with a short note explaining why, instead of failing after the visitor clicks Generate.

The lesson I'd keep from this layer: before you limit how many times someone can try, limit how much each try costs you. It's the cheapest protection you'll ever add.

2. A cookie as the first identity

A guest gets an HttpOnly cookie with a random ID. That ID points to its own trial table: how much allowance is left, when the window started, and the jobs it ran.

None of this touches the real user tables. A guest has no row in user, no credits, and nothing in the history feed. That separation has paid off more than once: I can change the trial rules, reset it, or turn it off completely without any risk to paying customers' data.

Of course, a cookie can be cleared in one click. It's the front door, not the lock.

3. A device signature, without a fingerprinting library

This is the layer that does most of the work.

Clearing cookies and switching from wifi to mobile data is the classic way to get a fresh trial. To make that pointless, the server derives a signature from the headers a browser already sends about itself:

import { md5 } from './hash';

export function getDeviceId(request: Request): string {
  const h = request.headers;
  const userAgent = (h.get('user-agent') || '').trim();
  // No user agent (curl, scripts): no signature. Fall back to IP limits
  // instead of lumping every script onto one "device".
  if (!userAgent) return '';

  const languages = (h.get('accept-language') || '')
    .toLowerCase()
    .split(',')
    .map((part) => part.split(';')[0].trim())
    .filter(Boolean)
    .sort()
    .join(',');

  return md5(
    [
      userAgent.toLowerCase(),
      languages,
      (h.get('sec-ch-ua') || '').toLowerCase(),
      (h.get('sec-ch-ua-mobile') || '').toLowerCase(),
      (h.get('sec-ch-ua-platform') || '').toLowerCase(),
    ].join('|')
  );
}

The user agent, client hints and language list stay the same for a given browser on a given machine. Clearing the cookie doesn't change them. Switching networks doesn't change them. Meanwhile a genuinely different visitor on the same office wifi usually has a different browser version, platform or language list, so they still get their own trial.

I deliberately did not use a canvas or WebGL fingerprint. That would need a client-side library, would collect more about visitors than I actually need, and would deserve its own privacy notice. The server already has these headers on every request. The hash is one-way and never leaves the server.

Two details that matter:

• An empty user agent gets an empty signature. Otherwise every request without one (curl, a stripped-down script) would share a single "device" and a single set of limits. Those requests fall back to the IP limits instead, so they're still counted per address.
• It's not meant to be perfect. Someone who switches browsers or spoofs headers can get past it. That's fine. The goal is to make casual farming boring, not impossible.

4. Three rolling 24-hour limits: per IP, per device, and for everyone

Each signal gets its own limits over a rolling 24 hours:

• Per IP: how many jobs, and how many new guests can appear from one address.
• Per device: the same pair, keyed on the signature above. The device limits are deliberately stricter than the IP ones, because the device is the layer that still holds after the cookie is cleared and the network changes.
• For the whole trial: one global ceiling on free jobs per day, across every visitor.

Only guests that actually generated something count toward the "new guests" limits. Someone who just loads the page and leaves doesn't use up anything.

All of these are settings in my admin panel, not constants in the code, so I can tighten them in a minute if I see a spike. I'm not going to share the actual numbers here, for the obvious reason.

That last limit, the global one, is the most important line in this whole system. More on that below.

5. Cloudflare Turnstile, and fail closed

Every free generation has to carry a fresh Cloudflare Turnstile token, which filters out most of the simple bots before they reach any of the counting logic.

The detail I'm glad I thought about: if the Turnstile secret is missing in production, the trial refuses every request. It doesn't quietly skip the check. A wiped or broken config should close the trial, not open it to every bot on the internet. In local development the check is skipped, so it doesn't get in the way while I'm building.

6. Refund failures, but only once

The last layer is about being fair to real visitors, which matters as much as stopping abuse.

The order of operations is:

1. Spend the allowance and create the job first, in one atomic write, before calling the model provider. Every attempt counts, even ones that fail later.
2. Call the provider.
3. Settle the result.

If the provider rejects the request or reports the job as failed or cancelled, the guest gets the allowance back. Losing your only free try to someone else's outage feels terrible, and that visitor is gone for good.

But the refund has rules:

• It happens once. A refunded flag is set in the same atomic write as the refund itself, so a retry or a second status check can't hand the allowance back twice. (My database is Cloudflare D1, which has no interactive transactions, so "atomic" here means a single batch with a guard condition.)
• Unknown outcomes aren't refunded. If I can't tell whether the job ran, I don't refund it.
• Content-policy rejections aren't refunded. If the input was refused by moderation, that attempt was the visitor's own doing.

Each guest can also only have one job in flight at a time, so nobody can fire twenty requests in parallel and race the counters. And because people close tabs mid-generation, jobs that have sat in "processing" for too long are closed out the next time that guest tries again. Without it, a guest who closed the tab could be locked out of their own trial forever.

What I learned

Make farming boring, not impossible. Every layer here can be beaten by someone determined enough. That's fine. Most people who try to farm a free trial give up after the second wall. The few who don't would never have paid anyway.

The global daily cap is the only layer that actually bounds the worst case. Detection can always be fooled. A hard ceiling on free jobs per day can't. Whatever else goes wrong, I know the maximum I can lose on the trial in a single day, and that's what lets me sleep.

Lock cost, not experience. The trial is cheap because of resolution, length and model choice, not because it's crippled. Letting guests keep the settings that don't cost anything makes the result something they'd actually want to post.

Fail closed on configuration. Anything that protects money should refuse to run when its config is missing, not skip itself.

Refund rules decide whether the trial feels fair. A visitor who loses their free try to a provider error doesn't care whose fault it was. Getting refunds right turned failures into "try again" instead of "this site is broken".

Keep trial data away from your real user data. Separate tables made it easy to change the rules over and over without worrying about paying users.

Wrapping up

The whole system, in one breath: make each free try cheap, identify guests with a cookie and a header-based device signature, cap them per IP, per device and for the whole site each day, stop bots with Turnstile that fails closed, and refund real failures exactly once.

If you want to see what the visitor side looks like, the image to video tool runs on this same trial: upload a photo and generate without an account.

How do you handle free trials for something that costs you money per use? I'd love to hear what's worked for you in the comments.