How small local LLMs approach cloud-model results in video editing
In One prompt, from local AI video understanding to multilingual clips, we described three ways to start: discover a topic, generate a highlight cut or tell BonFrame what you want a clip to explain. After reviewing the edit, you can move into translation, dubbing and lip sync.
That workflow raises a practical question: can a small local model choose the right material and preserve what the speaker meant?
This article follows the selection stage of that same workflow. It explains the architecture behind the three starting points, then separates what our tests support from what still needs evaluation.
The answer is in the work around the model. BonFrame uses semantic retrieval to find relevant material, source-linked IDs to identify it and a constrained editing workflow to assemble it. The local model makes a smaller editorial decision inside that system.
The idea is straightforward: search the recording first, give the model relevant passages, then check its choices against the source. A smaller model has less work to do, and you have a clearer way to inspect the result.
Our historical comparisons include OpenAI GPT-5.1 on candidate selection and DeepSeek on complete cuts. They support this approach on those specific tasks, rather than general equivalence between a local model and ChatGPT. The results and detailed evidence appear below.
Give the model an editorial decision it can actually make
“Turn this interview into a short explanation of the hiring mistake” contains several jobs: understand the request, find the relevant story, preserve its cause and consequence, locate real cuts and fit the result into a duration.
Asking one model to handle all of that in a single response makes its output difficult to check. A plausible summary may describe the story well without identifying usable source passages. A timestamp may look precise while pointing to the wrong sentence.
BonFrame separates those responsibilities:
Video and speech
→ transcript with source IDs and timing
→ local semantic index
→ editing request: topic, required content, exclusions, duration
→ retrieval of relevant passages and surrounding context
→ candidate blocks with real source IDs
→ bounded model selection
→ assembly and constraint checks
→ a cut you can review
The model does not have to remember every sentence or invent coordinates. It chooses from material the workflow has already identified.
For example, a request to explain a hiring mistake may need three passages: what the team expected, what went wrong and what they changed afterward. Retrieval looks for those parts, and the selector decides which candidate blocks tell that story. The workflow maps the selected blocks to the recording and checks the duration. This is an illustrative example, not a measured test case.
Retrieval gives the small model a relevant working set
A local embedding model, such as multilingual E5, represents transcript passages in a form that can be searched by meaning. This helps connect a request to relevant wording even when the speaker used different terms.
The full transcript stays available as an indexed project asset. Each request retrieves a smaller working set for the next decision. Related context can help turn a matching sentence into a usable explanation or question-and-answer block.
This reduces what the language model needs to process. It also introduces a limit: if retrieval misses a crucial explanation, a good selector cannot choose it. Putting every sentence into an index does not guarantee every relevant passage will be retrieved.
Source IDs remove the need to guess timestamps
A candidate comes with a reference to actual transcript content and its timing. The model selects allowed IDs; the workflow resolves those IDs back to the recording.
This makes source validation possible. An unknown ID can be rejected instead of becoming a guessed cut point. It also helps you compare a proposal with the original material.
Source validity is only one part of accuracy. Real sentences can still become misleading when a qualification, question or negation is removed. Meaning and continuity need their own checks.
Constraints turn a broad request into a bounded task
A request such as “explain the mistake, keep the example and remove the promotion” supplies more useful guidance than “find the best part.”
BonFrame organizes the request into an editorial brief: what the clip is about, what it needs, what it should exclude and how long it should be. Some explicit requirements can be handled by rules. Where a model participates, it works within the relevant stage rather than taking responsibility for every part of the edit.
Assembly then applies the selected source blocks and checks structural constraints. Duration is a calculation; source references can be validated. Neither requires a model to freely generate an answer.
That division is why model size becomes less decisive for this particular task. The system supplies evidence and coordinates, leaving a more manageable selection problem.
How this supports the workflow in the first article
The three starting points share a foundation, but the evidence is different for each:
| What you want to do | How the architecture helps | What the evidence establishes |
|---|---|---|
| Discover a topic worth developing | Semantic retrieval finds candidate passages; the model helps name a direction | The architecture explains where suggestions come from. The selection tests below do not measure topic-discovery quality. |
| Build a highlight cut | Candidate blocks preserve related passages; a selector chooses what stays | The candidate-selection tests compare local 8B with GPT-5.1 within an already narrowed working set. They do not predict virality. |
| Describe a clip in one prompt | The brief turns your goal into requirements, followed by retrieval, selection and assembly | The complete-cut tests compare the local product workflow with a DeepSeek full-transcript baseline on eight held-out cases. |
Return to the hiring example from the first article. “Keep the example” becomes a requirement; retrieval looks for the hiring story and its context; selection chooses the useful passages; assembly maps them back to the source. Each stage answers a smaller part of your original request.
The tests below examine selection and complete cuts. They do not establish translation accuracy or lip-sync quality. Those are later stages of the workflow, with their own review requirements.
What we tested against OpenAI GPT-5.1
Our August 3, 2026 historical test examined choosing which source passages to keep within existing candidate cards. Retrieval had already narrowed the material. The model could choose among existing source IDs; it was not asked to discover every topic in a long video or generate a complete timeline.
| Selector | Chinese suite: passed cases | English suite: passed cases |
|---|---|---|
| Local Ministral 8B Q4 | 13/13 | 9/11 |
| OpenAI GPT-5.1 | 13/13 | 8/11 |
| DeepSeek v4-flash | 13/13 | 8/11 |
This is the direct evidence involving GPT-5.1. The local 8B path recorded no rule fallbacks in either suite. Other indicators differed, including consistency across paraphrased requests; equal pass counts do not mean identical behavior.
These are small, task-specific historical suites. They do not show that Ministral matches the current ChatGPT product, all OpenAI models or an entire cloud editing workflow. See the detailed test tables and interpretation notes.
What the complete-cut comparison showed
A broader test began with an abstract editing request and produced a source-grounded cut. Eight held-out transcripts were each run three times, giving 24 trials per path. Repeats are repeated attempts on eight cases, not 24 independent videos.
The local path selected from retrieved blocks. The main cloud baseline gave DeepSeek the full transcript and required real source references. A separate GPT-5.1 judge assessed grounding, coverage, exclusions and coherence under swapped labels. A pass required both the structural checks and the judge’s assessment. Here, grounding means the cut stays faithful to the source; coverage means it includes the requested explanation; exclusions check what should have been removed; and coherence checks whether the selected passages make sense together.
| Path | Combined passes | Mean generation input |
|---|---|---|
| Product workflow + local Ministral 8B | 17/24 | 860 tokens |
| Product workflow + local Ministral 3B | 14/24 | 860 tokens |
| DeepSeek full-transcript baseline | 15/24 | 4,600 tokens |
Local 8B’s observed pass rate was 8.3 percentage points above this baseline; 3B’s was 4.2 points below it. Generation input was 81.3% lower. This token measure excludes transcription, indexing, output generation and downstream translation or lip sync; it is not an end-to-end speed or cost reduction.
The original protocol accepted an observed pass-rate difference of no worse than five percentage points. The 3B result met that rule. With only eight source cases and no confidence-interval analysis, this remains an exploratory result; see the appendix for its statistical limits.
Crucially, GPT-5.1 judged this experiment; it was not the full-transcript editing baseline. These results cannot be presented as a complete-cut victory over ChatGPT.
Retrieval alone was not enough
An earlier version used retrieval followed by rule assembly. It passed only 2 of 8 held-out cases, while the full-transcript baseline passed 5 of 8.
Adding constrained local block selection introduced an editorial decision between finding content and assembling it. The later results are consistent with that step helping, although the earlier single-run test and later repeated protocol are not a clean causal ablation.
The lesson is practical: relevant sentences still need to be selected and organized. A vector index by itself does not produce a good short video.
Where the system still failed
The complete-cut tests included clear failures. In the 8B protocol, every path failed all three attempts on a Docker case. Topically relevant introductions and demonstrations survived while the requested explanation remained incomplete.
On photosynthesis, the full-transcript baseline more consistently retained the complete mechanism. Short candidates sometimes ended too early. On fair use, a cloud selector using the same short evidence outperformed local 3B on that individual case.
These failures expose different limits: retrieval coverage, block boundaries, editorial selection and the definition of a useful explanation. A larger model may help with some of them, but cannot automatically fix missing candidates or a poorly specified task.
The complete-cut results used model judging, not human editorial review. They do not measure audience engagement, visual continuity or whether a clip will go viral. Larger held-out sets and human blind review are still needed.
What this means for your workflow
A local model can be useful because the architecture gives it a focused task with source material it can act on. You can ask for a topic-led cut, inspect the result and refine the direction while reusing the same transcript and index.
Once you confirm the content, you can move into translation, dubbing and optional lip sync. The selection results here do not benchmark those later stages; each needs its own quality checks.
For a practical introduction, read One prompt, from local AI video understanding to multilingual clips. For the evidence behind this article, see the detailed test appendix and the held-out benchmark protocol.