PromptLens: reverse engineering the prompt behind a video

The tool and the loop it is built around

PromptLens is an AI video prompt analysis tool in web form, and the description gives the three jobs in one line: it reverse engineers the prompt of an AI generated video, it comes with audio analysis that can pull the dialogue out of a video, and it can cut the video you want in one sentence.

The workflow is laid out as a five step cycle, and the shape of the cycle is the product idea.

The first step is discovery, which is browsing short videos and finding an AI clip you like. The second is reverse engineering the prompt: you upload the video, the application analyses the frames, the scenes, and the actions, and the extracted description of the original video becomes a prompt.

The third step is the second creation. You change the prompt, adjusting the scene, the style, the characters, or the action, and you add your own elements. The fourth step is generation, where the edited prompt goes to a video generation API. The fifth is publishing, and then the loop returns to the first step with the feedback from what you published.

So the tool is not a generator, it is the first two steps of a loop that ends in somebody else's generator. That is a useful framing, because it explains the odd emphasis in the documentation on what to feed it.

The application is MIT licensed, written in TypeScript, and the last push was on 2026-10-19, with the hosted version available online so that a newcomer can sign in and use it with no setup.

The feature set, and the API surface behind it

The feature list has six entries, and the middle ones are the ones that turn a demo into something you can keep using.

Video analysis is the core: upload a video and the application extracts the key frames and analyses them with a model. Image analysis is the same idea for stills, and it supports a single image or a batch of several.

Multiple API providers are supported, and the list names three for the analysis work: a Chinese provider, Google Gemini, and OpenRouter, which is an aggregator that routes to several models. The video generation step has its own provider, and the transcription step has its own two.

Then there is the history feature, which saves and analyses your prompt history, and the user system, with Google sign-in and data isolation between users, and a logging system that records operations in full.

The history and the logging are what make the tool a practice rather than a one-off. If you are trying to work out which prompt phrasing produces a particular effect, you need the prompts you have already tried, and you need to know which of them you actually sent.

The HTTP surface is small and worth knowing about. There is a post endpoint for uploading a video or an image, a post endpoint for analysing the media and generating the prompt, and a get endpoint for the history, which requires a login.

The repository also carries a product requirements document, a tutorial document, a local setup guide, and a script for testing the audio path, alongside the application code, which is the file layout of a project that has been worked on rather than sketched.

Shot detection, and why a six second clip beats a five minute video

The most useful piece of practical advice in the documentation is about how to cut the input before uploading, and it comes in the form of a recommendation rather than a warning.

For long videos, the advice is to split them into shots of six to ten seconds and analyse the shots separately, because the prompts that come out of that are more detailed. And the corresponding warning is against uploading a video of several minutes directly, because the key frames will not be extracted and the resulting prompt will be very general.

That is the whole failure mode of the tool in one sentence. The analysis is only as good as the frames it sees, and a model given a long video samples frames across it, so it describes the video rather than any particular moment of it.

The project has this on its roadmap as a feature rather than as a user habit, and the readme explains how it intends to do it. Automatic shot splitting would use the scene detection experience in FFmpeg, treating a change past a threshold as a change of shot, and it would combine that with a library for scene detection, or with the audio waveform, since a place where the waveform changes sharply usually has a transition in it.

So the plan is to do on the server what the documentation currently asks you to do by hand, and the current advice is the fallback.

There is a second roadmap item about analysing a video from a link rather than an upload, and it comes with an honest account of why that is hard: the downloader it would use can only handle some public videos, because it gets stuck on the login state or cannot obtain the cookies, and many cases still fail to parse, so a third party parsing service may be the only way, and the author is unsure there is a better approach.

That is worth noting for anyone planning to build on it, because the same login wall applies to every hosted video platform, and it is the reason the upload path is the primary one.

Audio: two transcription engines and automatic segmenting

The audio tab is a separate path with its own choices, and it does two things at once: it transcribes, and it segments.

You upload a video or give a video URL, and you choose the transcription engine. There is a cloud service that includes a free hour each month and works out of the box, and there is a self-hosted engine that is free but that you have to deploy yourself, and the readme recommends it for frequent use.

Then a language model does the segmenting on top of the transcript, and the result is a list of segments you can select from and cut in one action. The segment boundaries are chosen by the model rather than by a silence detector, which is the interesting part, because it means a long sentence that pauses in the middle is not split and a short line between two long ones is not merged.

The self-hosted option is the more interesting recommendation for anyone thinking about this properly, because the free tier of the cloud service is per month and the self-hosted one is a cost you pay in your own hardware. The readme frames it in terms of frequency of use, which is the right frame.

The transcription itself is not the only path in the repository. There is a local speech-to-text package in the dependency list and a script for testing the audio path directly, which is the sort of thing a project adds when it wants a developer to be able to try the audio pipeline without a cloud account.

The editing service, and the contract it expects

The cutting feature is the one part of the application that cannot run on the platform it is deployed to, and the readme says so directly: the editing function needs a self-hosted FFmpeg service, because the serverless platform it targets cannot run FFmpeg.

For ordinary users, the recommendation is to use a local editing application instead, which is an honest answer given the alternative.

For developers who want the feature enabled, the contract is given precisely. There is a post endpoint for a cut, taking a video URL and an instruction object, and the instruction is either a trim with a start and an end, or a speed change with a factor. The response is a URL.

There is a second post endpoint for concatenation, taking a video URL and an instruction with a list of segments, each with a start and an end, and a transition, and the response is a URL again.

The use of signed URLs in the request and a returned URL in the response is the detail that makes the design work: the editing service does not need your credentials, it needs a link to the file, and it hands back a link to the result. That is what lets the service be a separate machine with a different lifetime from the application.

The application side holds the FFmpeg libraries, a wrapper for driving them, an installer that fetches the binary, and a client for the video service, plus a hosted video service library and a charting library for the timeline.

The stack, the configuration, and where it runs

The technology list in the readme is a good map of what the application is.

The front end is Next.js 15 with React 19 and TypeScript, styled with Tailwind and a component set, and internationalised, which is a sensible choice for a tool aimed at the Chinese market that also wants a wider audience. The back end is the API routes of the same framework, so there is one application rather than two.

The database is PostgreSQL, through an object relational mapper with its own migration tooling, and the readme explains the choice: Docker locally or a hosted Postgres in the cloud, and either works. Storage is Cloudflare R2, with the object storage client and a presigner, and the configuration file has a public base URL for the bucket, which is the piece that makes the returned URLs work.

Authentication is handled by a library that supports Google and GitHub sign-in and email codes, and the configuration holds client identifiers and secrets for both providers along with a list of trusted origins and a list of administrator addresses.

The AI providers each have a system-wide key, and the comment in the configuration says that they are optional because users can bring their own. The readme adds that the project ships with the author's own key preconfigured so that it works out of the box, and recommends using your own to avoid rate limiting. That is a good default for a demonstration and a bad default for a public deployment, and the readme is candid about which it is.

Deployment is the platform the application was written for, and the two commands are a build and a deploy. The local path is the usual one for a Next.js project.

git clone https://github.com/raojiacui/prompt-lens.git
cd prompt-lens

pnpm install

cp .env.example .env.local

pnpm db:push

pnpm dev

That is clone, install with pnpm, copy the environment template, push the schema to the database, and start the development server, which is on port 3000.

The rest of the repository is conventional and thorough: a Drizzle configuration, a Tailwind configuration, a PostCSS configuration, a Playwright configuration for the end to end tests, a Vitest configuration for the unit tests, an internationalisation directory, a middleware file, a types directory, and a components directory.

Editorial conclusion

PromptLens fits a creator who keeps seeing a generated clip they cannot reproduce, and who wants a written description of the scene they can edit and re-run. It does not fit a team that needs the original prompt recovered exactly, because the application infers it from frames rather than reading it from somewhere. Verify first which model provider you will point it at, since the description is only as good as the vision model behind it, that the transcription engine you choose suits how often you will use it, and that you have read the licensing position of the model you are asking to imitate, because a prompt that reproduces a specific creator's work is a different question from a prompt that describes a scene.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. raojiacui/prompt-lens on GitHub
5. README