The anchor is
the interface.

Type a prompt, wait, get a video back. If it's wrong, type it again, differently, and hope. That's the interaction model behind almost every AI video tool shipping right now, and it's worth noticing how strange it is: the AI does the understanding, and when it gets that understanding wrong, your only lever is to throw the whole attempt away and re-describe what you wanted in English. There is no way to reach in and say "you had it right except for this one thing" — because there's no thing to point at. A prompt-and-generate loop has no handles.

We didn't set out to fix that in the abstract. We set out to build a cricket highlight app that could find the moment a bat meets a ball on a phone recording of a net session, cut a clip around it, and — because someone always asks for this — put a cartoon burst on the frame of contact. That last, frivolous request is what forced the question, because a burst can't be approximately right. It has to land on one instant, in one place, or it looks broken. Chasing that turned into the actual shape of the product: not a smarter prompt box, but a measurement the AI proposes, that many features share, and that a person can correct directly.

That measurement is what we've come to call the anchor. This post is about why it's the right unit of collaboration between a person and an AI editor, what it looks like concretely in CricCuts, and — since the question is worth asking honestly rather than assuming the answer — whether anyone else has already built it this way.

The one-shot trap

Generative video tools are extraordinary at producing a plausible first attempt from almost nothing. What they're still bad at is being corrected. The feedback loop is: describe, generate, judge, describe again. Every round trip discards what the model understood and starts over on the language. Traditional editors have the opposite problem — total control, zero understanding. You get precise handles (a timeline, keyframes, masks) but none of them know what a cricket shot is, so getting one lined up on the right instant is manual work, frame by frame, on every single clip.

Neither shape fits what we needed. A parent filming their kid's net session doesn't want to write a paragraph describing "the cover drive at 0:47," and they definitely don't want to hand-place forty keyframes across a ninety-minute recording. They want the app to find the shots, get the effects roughly right, and — the part every other tool skips — give them one specific, obvious thing to fix when it doesn't.

What a phone actually has to figure out

Here's the part that makes cricket a genuinely hard test case rather than a toy one: the loudest sound near a cricket shot is very often not the shot. A bowler's release, a ball smacking the side netting, a second net going at the same time — all of those can be louder than an actual middled contact, which off a good bat can be surprisingly quiet. And the moment your eye locks onto — the big, visible arc of the follow-through — happens after the ball has already left the bat, not when it left it. A tool that anchors on "the loudest sound" or "the biggest motion" is anchoring on the wrong instant almost by design.

Cricket already has a professional answer to a related problem — it's just aimed at a courtroom, not a highlight reel. Broadcast decision review systems use exactly this insight: a sensitive microphone near the stumps, and software that looks for the acoustic signature of bat meeting ball to help an umpire rule on a faint edge. It's a serious piece of engineering, vetted by outside labs before the sport trusted it. What it produces, though, is a spike on a waveform for a third umpire to eyeball — a decision aid, not an editing anchor. Nothing about it drives a visual effect, and nothing about it is meant to be corrected by the person watching; it's built to be trusted as-is or overruled by a human review, not adjusted.

That's the gap CricCuts sits in. Not "can a phone hear a bat-ball contact" — cricket has known that's possible for decades. The question is what you do with that measurement once you have it: can it become something forty different creative effects share, that the person filming — not a match official — can nudge with a tap, in a reel that renders on their own phone with nothing leaving the device.

Curation: propose, don't decide

Before any effect gets anchored to anything, there's a simpler division of labour worth stating plainly, because it sets the tone for everything after it: the detection pipeline never filters anything out. Every candidate it finds survives all the way to the screen you curate on — precision is the interface's job, not the engine's. If you deselect a shot and revisit the reel later, that choice sticks; the app doesn't quietly re-decide for you on the next pass. The one thing it will not do is disappear a shot you might have wanted, silently, before you ever saw it.

The sorting the app offers is plain about what it's ranking, too — real labels off the actual sort menu: Delivery probability (how likely this is a real ball bowled and faced, not stance-shuffle or someone fiddling with a bag), Power (hardest contact first), and Beaten chance — deliveries the batter swung hard at and didn't middle, surfaced separately because a play-and-miss matters for a coaching reel in a way a pure "loudest first" sort would bury. None of that is a black-box "AI score." It's the app telling you, in cricket terms, what it thinks it's looking at, and leaving the yes/no to you.

The one upfront ask CricCuts makes — draw a box around the batter — is optional by design, and deliberately narrow in what it claims to know. It answers where in the frame the person you care about is standing, not who they are; there's no face recognition anywhere in it. Skip it and the app falls back to audio alone. It exists because the honest failure mode of a purely audio-driven tool is picking up the net next door, and one drawn box is a cheaper, more reliable fix than trying to filter that out after the fact from sound alone.

Three clocks, on purpose

Once you accept that "when did the shot happen" matters, the tempting next move is to compute one number and use it everywhere. We tried that. It's wrong, and it's wrong for a reason worth naming: a cricket delivery isn't one instant, it's several correlated but genuinely different instants, and a tool that flattens them into a single timestamp inherits whichever one it happened to measure — which is rarely the one every downstream use actually needs.

• The instant that decides whether this was a shot at all — the acoustic impact, which drives selection, loudness ranking and which candidates get grouped as "the same delivery." This has to be robust to noise, because it's making a keep/discard call across an entire session.
• The instant that decides how much footage to keep — the window anchor, biased toward the batter's actual body motion when the app can measure it, because a clip windowed purely off the loud release crops off the stroke that made the sound in the first place.
• The instant an effect actually lands on — the contact anchor: audio-first, checked against what the video shows, and never allowed to fall outside the clip. This is the one a burst, a slow-mo ramp or a replay pass reads — and it's read by both the live preview you scrub while editing and the final export, off one function. What you see while trimming is not an approximation of what renders; it's the same number.

Keeping those three deliberately separate — rather than merging them into a single "the moment" value — is a small design choice with a large consequence: it's what makes the anchor trustworthy enough for dozens of unrelated effects to build on without each of them silently disagreeing about what "the moment" even means.

One resolver, dozens of effects

This is the part that makes "anchor" more than a nice word for "timestamp." The contact anchor above and a matching spatial anchor — where the batter's body actually is in the frame, measured by pose estimation when it can be, falling back to the drawn box when it can't — aren't private to any one effect. They're read by everything that needs them, and there are a lot of things that need them:

That last group is worth a beat on its own. CricCuts ships eight full animated scene backdrops a clip can drop the batter into — a floodlit stadium, a portal, a temple gate, a neon skyline, a hollowed-out tree, a corridor built from typography lifted from real-world scripts. Every one of them is required to leave a hole for the batter, cut to their actual measured height and stance, not a fixed rectangle in the middle of the frame — because a scene that's wrong once, painting over an arm or a helmet on the one framing nobody tested, reads as broken no matter how good the art is. All eight solve that opening from the same one batter-position measurement. Improve that measurement once, and all eight scenes get more accurate at the same time — because they're not eight separate guesses, they're eight consumers of one shared answer.

Sound follows the identical pattern on its own clock: cricking-bat cracks, crowd swells, applause and more all key off the same contact anchor, layered rather than picked one-at-a-time, and all riding whatever speed the picture is playing at — so a slow-mo pass slows its sound down for free, because both are reading the same anchor through the same clock, not two separately-timed tracks that happen to usually agree.

Correct the measurement, not the picture

None of the above matters if the AI's first guess is the only thing you can ever ship. The measurement is sometimes wrong — a play-and-miss with no crisp crack to lock onto, a batter half-obscured by another player, a session loud enough to fool anyone. So every clip carries two direct-manipulation gestures, and this is the actual help text shown in the editor, word for word:

Read that carefully and it says something specific: Pin and Draw aren't "move this sticker" gestures. They correct the underlying claim the AI made — this is the instant of contact, this is the person to track — and every effect that reads that claim re-derives itself from the correction. Pin one frame, and the clip's window, its slow-mo band and its comic anchor all re-centre together, in one tap, because they were never three separate settings to begin with — they were three consumers of the one thing you just fixed. The app even quietly discards its own stale pose measurements the moment you correct the anchor, so the very next effect that asks "where is the batter standing" gets a fresh answer for the new instant, not a cached one from the old guess.

That's the difference between editing an output and correcting an understanding. A timeline lets you nudge a keyframe. This lets you fix the fact the AI got wrong, once, and watch every effect built on that fact follow.

The place it admits it can't know

That's a small feature, but it's a useful tell about the whole approach: an anchor is only trustworthy if the app is honest about which anchors it can actually measure and which ones it has to ask for. Guessing and hiding the guess would have been easy. It would also have meant every gust effect on every unmeasured clip pointing wrong, silently, forever.

Cricket has to know what it's watching

A generic "smart" effect fires on generic evidence — a beat in a soundtrack, a burst of any motion, a cut between any two shots. None of that requires knowing anything about the activity in frame. Cricket forces the opposite: telling a real delivery from a false one, a legal ball from a wide, a trigger movement from someone just resetting their stance, a beaten shot from a shot that connected, needs actual domain concepts wired in as first-class things the app reasons about — not generic motion or loudness dressed up in cricket vocabulary. Camera position matters for the same reason: what "forward" means inverts between a camera at the bowler's end and one side-on, and the app has to know which one it's looking at before "which way did that swing go" means anything at all.

That's the real reason a domain-blind editor can't do what CricCuts does, even with a better model behind it. It isn't a modelling-power gap. It's that "the moment of contact" and "the batter's stance" aren't concepts a generic video tool has any occasion to define. You can't anchor an effect to an event you have no representation of.

So — is this the first?

It's a fair question to ask plainly rather than assume the flattering answer, so we went looking — at the big professional editors, the mobile and social apps, the sports-AI category, and cricket's own broadcast tech — for anyone already doing the full thing: an AI anchor that's automatic in time, automatic in space, tied to a real domain event rather than a generic signal, shared by many effects rather than owned by one, and correctable by a person in a way that ripples through everything built on it.

Being straight about the right column is what makes the left column mean something. The closest things we found, and exactly what each one is missing:

So here's the honest verdict, stated at the size the evidence actually supports rather than the size that sounds best: we haven't found another video editor, cricket or otherwise, where a single AI-measured domain event is shared as one anchor across this many effects, correctable by one direct gesture that re-derives everything built on it. In cricket specifically — where "when did contact happen" has a decades-old professional answer that was never meant to touch a creative effect — we're confident enough to say it plainly: as far as we could find, CricCuts is the first cricket video editor to anchor its effects this way. Beyond cricket, the more durable claim isn't a "first" at all — priority races get overtaken by next quarter's release notes. It's the design pattern itself: treat "when and where did this happen" as a shared, correctable measurement, not a per-effect guess each feature makes on its own.

What this means beyond cricket

There's a broader idea in interface research called mixed-initiative interaction — the observation that the best human-AI systems aren't the ones where the AI does everything or the ones where the person does everything, but the ones where control genuinely passes back and forth, and where the AI's contribution stays legible and correctable rather than a black box you either accept whole or throw away. CricCuts didn't set out to be an instance of that research; it arrived at the same place by trying to ship a cartoon wind gust that actually landed on the right frame, for a sport where getting that wrong is instantly, embarrassingly obvious to the exact people using the app.

The lesson that generalises is a plain one. If an AI editor gets something wrong, the fix shouldn't be "type a different prompt and hope this time," and it shouldn't be "throw out everything the AI understood and hand-place every keyframe yourself." It should be: let the person correct the one measurement that was wrong, and let that correction propagate to everything the AI built on top of it. That's a small thing to ask for. Almost nothing asks for it yet.

Related reading: the gust that fixed the engine, designing a cricket video editor around the bat-ball moment, and the idea the AI missed. More on the CricCuts blog.