YT Short Clipper v2: An LLM Picks the Highlights, FFmpeg Cuts Them

The editing step it removes, and the people it removes it for

Cutting a 90-minute interview into vertical clips is mostly mechanical: find the segment, crop it, caption it, export. YT Short Clipper takes that sequence and hands the first step to a language model. You paste a YouTube URL, upload a cookies.txt, and the app proposes highlight segments, by default between 58 and 120 seconds long, drawn from the video's subtitle transcript rather than from audio analysis. The audience is a solo operator who publishes to TikTok, Instagram Reels or YouTube Shorts and who does not want to open a nonlinear editor for every clip. It is not a batch transcoder and it is not a browser-based service. It is a Tauri v2 desktop app: React 19 and TypeScript in the WebView, a Rust shell, and a Python sidecar that carries yt-dlp, FFmpeg and MediaPipe. The README is blunt that this is Windows only, that the build scripts are PowerShell, and that the app ships as a portable zip with a WebView2 bootstrapper. Caption and hook rendering reads fonts from C:\Windows\Fonts, which is one of the concrete reasons a macOS port is not a packaging exercise.

How a URL becomes an MP4, stage by stage

The data flow is linear and each stage has a named owner. yt-dlp fetches the video and its original subtitle track using the cookies you supplied. The transcript goes to the LLM, which returns highlight segments; the model also generates titles and hook text. Each segment is then cut, reframed to 9:16, captioned, and written out as an MP4. Optionally the finished clips are uploaded and scheduled through Repliz. The reframe stage offers three modes, and the trade-off between them is explicit in the README: face tracking via MediaPipe, centered on black bars, or centered on a blurred fill. The two centered modes skip per-frame face detection, which the documentation describes as dramatically faster. That is the single most consequential knob in the app, because face tracking is the only mode that does real per-frame work. Captions come from YouTube's original subtitle track, so there is no transcription API call and no local Whisper model. The consequence is that a video without a usable subtitle track has nothing to caption from, and word-by-word timing is only as good as the source track's own timing.

AI direction: the escape hatch when the model picks badly

Left empty, the direction field lets the model choose on its own. Filled in, it outranks the built-in selection principles, and the README documents three behaviours worth knowing. An explicit clock range such as 2:00 - 2:50 is used exactly: that clip is exempt from the usual 58 to 120 second duration filter, and the run samples at a lower temperature so the instruction is actually followed. Array order is clip order, so a direction written in Indonesian that asks for the first clip lands that clip first in the list. Anything the direction rules out is left out. Custom system messages configured under AI Models can position the direction with a {user_direction} placeholder; without that placeholder the direction is appended at the end of the message. The placeholder detail matters more than it looks. If you write a custom system message and omit {user_direction}, your steering text arrives after your instructions rather than inside them, and the model's compliance is no longer something the app can shape.

Getting it running on a clean Windows machine

The prerequisites are Node.js v18 or later, the latest stable Rust, Python 3.13 or later, and Windows 10 or 11 with PowerShell. Setup is four commands. Run npm install, then py -m pip install -r requirements.txt, then powershell -ExecutionPolicy Bypass -File scripts/fetch-deps.ps1 to pull FFmpeg and Deno, then npm run build:sidecar to freeze the Python sidecar executable. For development, npm run dev starts Vite and npm run tauri dev opens the Tauri window. One trap is documented plainly: src-tauri/binaries/ytclip-sidecar-*.exe takes precedence over the dev Python module, so edits under yt_short_clipper_core/ do nothing until you rebuild the sidecar, and the app keeps running the frozen copy without complaining. Deleting that binary falls back to py -m yt_short_clipper_core.sidecar for fast iteration. The FFmpeg requirement is stricter than most: it must be a GnuTLS build, and the fetch script pulls one from gyan.dev, because Schannel builds hang forever on the byte-range requests used for section downloads. A release build is a single npm run release, which produces a full portable zip and a smaller update zip in src-tauri/target/release/bundle/.

The cookies.txt dependency is the real onboarding cost

Nothing is bundled. You export cookies.txt yourself using a browser extension while logged in to youtube.com, then upload the file through an Upload YouTube cookies to continue prompt. The README lists the fields a valid export contains: SID, HSID, SSID, APISID, SAPISID and LOGIN_INFO. Three operational notes follow. Logging out of YouTube after exporting invalidates the cookies. Frequent 403 errors mean the export went stale and a fresh one is needed. And the file grants access to your Google account, so it should be treated like a password. The app gitignores it, stores it only in the local data directory and passes it to yt-dlp on your machine. This is not a design flaw so much as an inherited cost of using yt-dlp against a logged-in session, but it is the step most likely to stop a casual user, and it is the step that turns a one-time install into an occasional maintenance chore.

Where it breaks: yt-dlp, Deno and the silent failure mode

The dependency that ages fastest is yt-dlp, and the README gives the upgrade path: py -m pip install --upgrade yt-dlp, bump the floor in requirements.txt, then npm run build:sidecar to re-freeze it. The reason to care is Deno. Deno drives remote_components for YouTube's JavaScript challenges, and the README notes that yt-dlp 2026.06.09 raised the Deno floor to v2.3.0. An under-floor binary breaks extraction quietly, and fetch-deps.ps1 will not replace an existing deno.exe without the -Force flag. So the failure looks like a broken download rather than a version mismatch, and the script that would fix it declines to act by default. Two other limitations are worth stating. The app is Windows only, with no macOS or Linux path today. And it is beta: the README says to expect rough edges and breaking changes between releases, and the three most recent releases are all tagged -beta. Pair that with the sidecar precedence rule and you have a project where a stale frozen binary can silently diverge from the source you are editing.

What it sends, and where it sends it

The README publishes a network table, which is more than most projects at this stage do, and it separates third-party hosts from the maintainer's own. YouTube and googlevideo receive your cookies through yt-dlp when video and subtitles are fetched. Your configured AI provider receives the subtitle transcript, your prompt and your API key. Then there is api.ytclip.org, the maintainer's backend, hit on launch by three endpoints (latest-version, notification and menu) and after a clip renders by success-log, each sending a random installation ID and the app version, with the success-log call also carrying clip duration. The API key itself is stored in the app's local data directory and, per the README, is never sent anywhere except the provider you configured. The honest reading is that the launch calls are lightweight and identified by a random ID rather than an account, but they are calls to a personal backend, not a third party with a privacy policy, and that is a different kind of trust decision. The AI provider is a single configuration shared by highlight detection and title generation, so switching models means switching both.

The alternative approach, and when it wins

The obvious comparison is a general-purpose editor with a transcript panel, such as a DaVinci Resolve or a Premiere Pro, where you read the transcript, set in and out points by hand, and apply a portrait crop. The difference in approach is where the judgement lives. YT Short Clipper asks a language model to select segments from text and then executes the cut automatically, which means the selection is non-deterministic and depends on the model, the temperature and the prompt. A transcript-driven editor keeps the selection deterministic and puts a human on every boundary, at the cost of your time per clip. The second alternative is a hosted clipping service, which removes the cookies.txt chore and the local FFmpeg build entirely but moves your source video and your account to someone else's infrastructure. YT Short Clipper sits between them: local rendering, remote inference. If your videos have no usable subtitle track, or if you need a specific frame-accurate in-point that the model will not reliably produce, the manual editor is the correct tool and the AI direction field will not save you, since it can pin a clock range but not a frame.

Editorial conclusion

Adopt it if you already run Windows 10 or 11, you are comfortable exporting a cookies.txt from a logged-in YouTube session, and you want an OpenAI-compatible model to choose your clip boundaries rather than scrubbing a timeline yourself. Do not adopt it if you need macOS or Linux, if you refuse to hand Google session cookies to a desktop tool, or if you are not prepared to re-export cookies whenever 403s appear. Verify three things before you commit a workflow to it: that your chosen FFmpeg build is GnuTLS rather than Schannel, that your Deno binary meets the floor yt-dlp currently requires, and that you accept the launch-time calls to api.ytclip.org. The version string still says beta, and the README says to expect breaking changes between releases.

Official sources

1. Issues
2. jipraks/yt-short-clipper on GitHub
3. License: MIT
4. README
5. Releases