How I got an AI video model to change outfits exactly on the fan blade

lumm — Wed, 28 Oct 2026 02:21:52 +0000

There is a TikTok trend where the camera looks straight down at someone lying on a carpet, a ceiling fan turns above them, and every time a blade sweeps across the lens their outfit changes. I built it as an effect on BlinkPop, a site that turns one photo into the AI video trend of the week. It looked simple. It took three rounds to get right, and the fix was not a better prompt.

The pipeline

Every effect on the site follows the same shape:

Compose. An image model places the user's photo into the scene: the overhead shot, the carpet, the sofa, the person in outfit one. For the fan effect the user uploads one photo per outfit, so we make one still per outfit.
Animate. A video model (Seedance 2.0 Mini) turns the stills into a short vertical clip.

The site runs on Cloudflare Workers with D1 and R2. Jobs have two or three steps, and each step's callback starts the next one.

Attempt 1: describe the timing in the prompt

The first version gave the video model the stills and a prompt like "a ceiling fan turns slowly; each time a blade passes the lens, the outfit changes to the next one."

With three outfits, the blade swept past four or five times and the outfit changed on passes one and four. Passes two and three did nothing. The model understood "fan" and "outfit change" but had no idea those two things were supposed to happen at the same moment.

Attempt 2: be more precise

I tried a slower fan, written-out pass times ("a blade passes at 2.5s and 6s"), and fewer words. Six runs, same problem. Sometimes the fan even changed direction halfway through. Text alone could not pin the rhythm.

Attempt 3: show it the rhythm

Seedance 2.0 Mini has a reference mode: besides reference images, you can pass a reference video, and it copies camera, motion and timing from it.

So I made rhythm clips: short cuts of one of our own earlier renders where the fan timing came out right.

2 outfits: a 6-second clip with one blade pass at 2.5s
3 outfits: a 9-second clip with passes at 2.5s and 6s

The request now sends the outfit stills as reference_image_urls and the matching clip as reference_video_urls. The prompt says to copy the camera, the fan and the timing from the video, take the room, the person and the outfits from the images, and treat the woman in the clip as a stand-in.

Results:

2 and 3 outfits: 8 out of 8 correct (man, woman and a dog)
The user's face was not pulled toward the stand-in in the clip
The fan kept one direction in all 13 reference-mode runs
4 outfits: only 2 out of 4 correct, so the effect stops at three

Reference mode also bills the reference video's seconds plus the output seconds, which works out to about $0.14 to $0.21 per video. That's roughly what the prompt-only version cost.

What I took from it

Timing is a motion problem, not a language problem. If the result depends on two events happening at the same moment, show the model a video where they do.
Use your own footage as the reference. The rhythm clips are cut from our own render, not from the original TikTok.
Cap the feature where it stops being reliable. Three outfits that always work beat four that work half the time.

A few smaller lessons from the other effects:

When composing two people into one scene, put the user photos first and the scene image last, and say "image 1 stands on the left, image 2 on the right". Otherwise left and right swap often.
Check the photo before charging (is there a person or pet, is it too dark or blurry). If the check service is down, let the job through rather than block paying users.
Refund credits automatically on any failed step.

You can try the fan effect and the others at blinkpop.video. New accounts get enough free credits for one video. I'd love to hear how others handle timing in AI video pipelines.

7 cron expression gotchas that will silently break your scheduled jobs

lumm — Thu, 21 May 2026 03:40:21 +0000

I've been working with cron expressions across different platforms for a while now, and I keep running into the same traps — some of them cost me hours of debugging, one of them cost me a full day of missed backups.

Here are 7 gotchas I've collected, with fixes for each.

1. "Every 6 hours" vs "every minute of hour 6"

This is the classic. You write:

0 6 * * *

Thinking it means "every 6 hours." It doesn't. It means "at 06:00 every day." What you actually want:

0 */6 * * *

The */6 in the hour field means "every 6th hour." Without the slash, you're just picking hour 6.

2. GitHub Actions is UTC-only and lies about timing

Your workflow says:

on:
  schedule:
    - cron: '0 9 * * 1-5'

You think it runs at 9am your time. It runs at 9am UTC. If you're in US Eastern, that's 5am. If you're in Beijing, that's 5pm.

Worse: GitHub Actions can delay scheduled runs by 5-30 minutes under heavy load. A job scheduled for 9:00 UTC might actually fire at 9:22. This matters if you have downstream dependencies.

3. `*/5` doesn't work on AWS EventBridge

You write:

cron(*/5 * * * ? *)

EventBridge rejects it. AWS uses 0/5 instead of */5:

cron(0/5 * * * ? *)

No error message tells you this clearly. You just get a generic validation failure.

4. Day-of-month + day-of-week: OR vs AND

This one is genuinely confusing. The expression:

0 8 15 * 1

On Linux cron: fires on the 15th of every month OR every Monday. (OR semantics)

On AWS EventBridge / Quartz: you can't even set both — one field must be ?.

If you want "the first Monday of every month" on Linux, you need a shell guard:

0 8 1-7 * 1 [ $(date +\%u) -eq 1 ] && /your/command

5. Vercel Hobby plan: 1 cron job per day

You deploy a Vercel cron that runs every hour:

{
  "crons": [{
    "path": "/api/cleanup",
    "schedule": "0 * * * *"
  }]
}

On the Hobby plan, this silently gets throttled to once per day. No warning in the build output. You find out when your cleanup hasn't run for 23 hours.

Pro plan minimum interval is 1 minute. Hobby is 1 per day. Period.

6. Kubernetes timeZone field needs v1.27+

You add this to your CronJob spec:

spec:
  timeZone: "America/New_York"
  schedule: "0 9 * * *"

On clusters older than 1.27, the timeZone field is silently ignored. Your job runs in UTC. No error, no warning.

Always check your cluster version before relying on this field.

7. Quartz uses different weekday numbers

Linux cron: 0 or 7 = Sunday, 1 = Monday

Quartz: 1 = Sunday, 2 = Monday

So 0 8 ? * 2 means Monday on Quartz but Tuesday on Linux. Copy-paste between platforms and you've shifted your entire schedule by a day.

Why I built a tool for this

After hitting most of these myself, I built cronwiz.dev — type a schedule in plain English, get the cron expression for 7 platforms (Linux, AWS, K8s, GitHub Actions, Vercel, Quartz, Cloudflare Workers) with platform-specific warnings baked in.

It also works in reverse: paste a cron expression and get a human-readable explanation. Useful when you're debugging someone else's crontab at 3am.

Free, no signup. The source is on GitHub.

I'm also building a cron monitor (dead-man's-switch style — your job pings a URL on success, you get alerted if it doesn't fire on time). Waitlist is on the site if that's interesting.

What cron gotchas have bitten you? I'm always looking for more edge cases to add to the tool.

DEV Community: lumm