TL;DR: We built a Premiere Pro panel that lets editors use their own AI subscription (Claude, ChatGPT, or Gemini) without leaving the editor. The hard parts weren’t the AI calls—they were the boring infrastructure: bundling a Node runtime so the panel works on machines that don’t have one, injecting the right PATH on both macOS and Windows, syncing timestamped comments to Premiere markers in both directions, and shipping updates through a launcher so users never chase a version number. Here’s how the pieces fit together.
The Challenge
We wanted one thing: an editor should be able to talk to AI inside Premiere Pro, using the AI plan they already pay for, and have that AI understand the project they’re working on.
That single sentence hides a stack of constraints:
- No marked-up billing. The AI had to run on the user’s own subscription or API key—not a reseller plan we profit from. That ruled out routing everything through our own backend.
- Cross-OS from day one. Editors are split across macOS and Windows. Anything OS-specific had to branch cleanly, not break silently on the other platform.
- Zero-dependency install. We couldn’t assume the user had Node, a package manager, or any CLI tooling. The panel had to work on a fresh machine.
- Real context, not a wrapped chatbot. The assistant needed the transcript, the frames, and the reviewer comments—otherwise it’s just a browser tab inside a panel.
Options We Considered
Option A: A pure web panel calling our backend
Pros: Simplest to build; one codebase; we control the AI calls. Cons: Every request goes through us, which means we’d be reselling AI usage and marking up the bill. It also breaks the “bring your own subscription” promise. Rejected on principle and on cost.
Option B: A CEP panel that shells out to local AI CLIs
Pros: The user’s own claude, codex, or Gemini access runs locally; no markup; their subscription, their usage.
Cons: Now we depend on local tooling existing and being on PATH—a genuine mess across macOS and Windows. Spawning processes from a panel is fiddly.
Option C: CEP panel + bundled runtime + a launcher
Pros: We bundle what the panel needs so a fresh machine works, and a separate launcher owns install and updates for every plugin. Cons: More moving parts—two repos, a signing pipeline, a manifest system.
We chose Option C. The “bring your own AI, no markup” constraint made Option A a non-starter, and Option B’s dependency problems were real enough that we needed the bundling and launcher work anyway.
Our Approach
Running on the user’s own AI
The panel connects to whichever provider the editor already uses. For Gemini, that’s an API key from AI Studio (with a free tier of 1,500 requests/day). For Claude and ChatGPT, it’s an OAuth login flow so usage draws from the existing subscription. Crucially, if an API key is sitting in an environment variable, the panel flags it with a warning—so nobody accidentally runs up a bill they didn’t mean to.
The dependency problem nobody sees
The least glamorous work mattered most. A panel that spawns a local CLI is at the mercy of whether that CLI exists and whether the shell can find it.
Two fixes did the heavy lifting. First, we bundle a Node runtime with the panel so providers that need it work on a machine that has nothing installed. Second, we inject the correct PATH at spawn time, because a panel process doesn’t inherit the same environment a terminal does—what works when you test it in a shell silently fails when launched from inside Premiere.
This is the kind of bug that only appears on someone else’s computer, which is exactly why it took several release iterations to get right across both operating systems.
Two-way comment sync
Review comments are useless to an editor if they live in another window. So timestamped comments from the review platform map to Premiere markers, and the sync runs both directions: a reviewer’s note becomes a marker on the timeline, and resolving it in the editor reflects back to the reviewer. Replies, resolution state, and new comments all stay consistent across the two surfaces.
Shipping updates without making users think
A panel is only as good as its update story. We split the system into two repos—the plugins and a launcher—and let the launcher own install and update for every plugin. A code push triggers a signed CI build, publishes the artifact, opens an automatic pull request to the launcher’s manifest, and the launcher then self-updates and surfaces an “Update” card. The user clicks once. They never look up a version number.
Results So Far
The Premiere panel is shipping and in active use, and the supporting infrastructure is doing its job:
| Area | State |
|---|---|
| Premiere Pro (CEP) panel | Shipping, in active dogfooding |
| Bring-your-own-AI (Claude / ChatGPT / Gemini) | Working, with API-key cost warnings |
| Cross-OS (macOS + Windows) | Both supported; OS-specific paths branched |
| Zero-dependency install | Bundled Node + PATH injection |
| Internationalization | 6 locales, parity-checked in CI |
| Code signing | macOS notarized; Windows in progress |
The honest caveat: the Premiere panel is the first of several planned tools (After Effects, Final Cut Pro, DaVinci Resolve, and design apps are on the roadmap), and the deeper automation features are still being built. What ships today is the foundation.
Lessons Learned
The AI was the easy part. Wiring up a model is a weekend. Making a panel work on a stranger’s machine—their PATH, their missing runtime, their OS—is where the real engineering went.
Test on a machine that isn’t yours. PATH and runtime bugs are invisible on the developer’s box. Dogfooding on a colleague’s computer surfaced issues no local test could.
Own the update path or users will fall behind. A launcher that self-updates and pushes a single “Update” card beats asking editors to track versions. Distribution is a feature.
Constraints clarify architecture. “No markup on AI” instantly killed the simplest design and pointed us at the harder-but-right one. A good constraint does that.
What’s Next
The same panel pattern extends to the rest of an editor’s toolkit—After Effects, Final Cut Pro, DaVinci Resolve, and design tools like Photoshop and Figma—each as its own plugin under one launcher. And the larger bet, turning editing know-how into reusable AI building blocks, is the subject of its own post.
Frequently Asked Questions
Why a CEP panel instead of a standalone app?
A panel lives inside Premiere, so it can read the active project and act on the timeline directly. A standalone app would be back to copy-pasting between windows—the exact friction we set out to remove.
How do you avoid marking up AI costs?
The AI runs on the user’s own subscription or API key, not through our backend. We don’t sit in the billing path, so there’s nothing to mark up.
Does the panel work without Node installed?
Yes. We bundle the runtime the panel needs and inject the correct PATH at launch, so a fresh machine works without manual setup.
Related Reading
- Editing Know-How as Code: How YouViCo Turns Editing Into Reusable AI Skills — the bigger architectural bet
- What Is an AI Video Editing Assistant? — the concept, for non-engineers