Six days after FilmCraft's repository opened, MrKeyoor's tracker counted 618 GitHub stars. The project's own readiness score was far lower: its maintainers rate the editor only 50-60% ready for real work, even though its feature checklist has reached about 87%. That 30-point gap makes FilmCraft more interesting than another fast-rising clone. It is a public attempt to measure the distance between having a button and trusting that button with a client's footage.
The repository README describes a clean-room, open-source reimplementation of the Adobe Premiere Pro workflow, written in Rust. It has familiar source and program monitors, bins, a multi-track timeline, color controls, audio mixing, captions, effects, export tools and Premiere-style shortcuts. The code is dual-licensed under MIT or Apache 2.0, and the developers say they use no Adobe code or assets.
FilmCraft is already packaged like software people can try. Version 0.2.0, published on October 5, includes installers or portable builds for macOS, Windows and several Linux formats, plus a command-line build and a web bundle. The release label and download menu look mature. The project's own documentation is much more cautious about what happens after installation.
The 87% figure counts presence
FilmCraft's roadmap says its menu comparison covers roughly 325 of 344 in-scope Premiere Pro 26.5 items. Tests also check catalogues of 93 video effects, 84 current video transitions and 53 audio effects. Those are wide numbers for a repository that appeared on September 30. They also explain why a screenshot or feature table can make the application look further along than it is.
The roadmap's methodology note spells out the limitation. An effect counts when it exists, including an approximation. Most areas outside the menus and effect catalogues are reported by the agents doing the work, and FilmCraft does not yet run an automated parity check across the whole application. Performance carries only 5% of the weighted checklist. Plugin support is absent from it. An editor can therefore gain checklist points without becoming meaningfully safer for a long, messy production.
The same honest assessment records four bugs a first-time contributor found within hours: failed AIFF imports, a Slide edit that left linked audio behind, transitions that did not follow ripple trims and export ignoring start and end times. A settings page can exist while some switches remain unwired. A decoder can pass conformance streams and still fail on an odd phone recording.
The lower estimate, 50-60% ready for real work, includes correctness, speed, stability and compatibility with professional workflows. It is still an estimate rather than an independently reproduced result. Yet it gives prospective users a better warning than the 87% score alone.
There is substantial engineering behind the interface
The October 5 roadmap records 35 Rust crates and more than 1,605 tests. Separate crates handle H.264, HEVC, VP9, AV1, ProRes, DNx, AAC, Opus, containers, rendering, color, captions and editing. FilmCraft says FFmpeg is used as an external test oracle and fixture generator, rather than linked or shipped inside the application.
The testing guide gives checkable tolerances instead of saying only that a suite passes. Codec tests compare decoded output with conformance vectors or FFmpeg. Golden-image tests require a peak signal-to-noise ratio of at least 45 dB and cap per-pixel differences. Headless interface tests open a demo project, cut clips, apply effects, undo actions and drive actual widgets through automation IDs. These are sensible defenses against a codebase growing faster than one person could inspect line by line.
The README says time is represented as integer ticks at 254,016,000,000 per second, chosen to divide evenly across common frame and audio sample rates. That design aims to prevent edits from drifting because of floating-point rounding. The application also uses one command system for menus, buttons, the command-line tool and its Model Context Protocol server. About 135 engine commands are exposed through that route.
The agent guide documents how a developer can run the desktop application with its local control server and launch the MCP endpoint separately:
filmcraft --control 9876
filmcraft-cli mcp --bridge 127.0.0.1:9876
That interface lets an agent inspect a sequence, place clips, adjust effects and render a frame using the same commands as the visible application. The agent documentation says FilmCraft was designed for AI control and was largely built by AI agents. It also requires each UI change to be driven through the control channel and checked in a screenshot before it is considered done.
Agent speed created the measurement problem
FilmCraft's roadmap records a work block in which five Claude Opus 5.5 agents ran in parallel for about 4.5 hours, or roughly 18 agent-hours. The maintainers estimate that the block moved the parity score by about four points. They also disclose the awkward parts: each worktree can consume 6-7GB, the full check can take 20-60 minutes under load, and one integrator must resolve overlapping changes.
Those recorded work conditions explain the repository's pace and the need for two progress numbers. Parallel agents can fill out menus, effects and format handlers quickly when the target behavior is already documented. Real production confidence arrives through slower evidence: varied camera files, damaged containers, long sessions, platform testing and reports from editors whose work does not resemble the demo project.
The public contributor graph is concentrated, with hundreds of commits credited to the lead account and only a small number to another contributor. The project's tests and disclosures therefore carry much of the burden that a longer field history or a broader maintainer group would otherwise share.
The missing work affects daily editing
Hardware acceleration is the clearest gap in the roadmap's performance assessment, which rates that area at only 35-40% of Premiere's level. Hardware decoding works on macOS, while Windows and Linux still lack a hardware path. Thirty-one common effects and basic compositing can run on the GPU, but Lumetri, masks, export and encoding remain on the CPU. The project says its 4K path can consume several CPU cores per real-time second, depending on the codec and machine.
Issue 30 tracks the planned work across VideoToolbox, VA-API and Media Foundation, as well as moving more effects and export to the GPU. The fallback design is sound on paper: try hardware first, retain the pure-Rust decoder as a reference path, and fall back when a profile or driver fails. The acceptance targets still need published results on representative hardware.
The media assessment has a similar split. Conformance streams receive detailed tests, but the maintainers say footage from cameras and phones is much less exercised. Variable frame rate, damaged files and unusual containers are exactly where editing applications earn or lose trust. A planned real-world corpus would turn those cases into repeatable import, edit and export checks.
The plugin and export gaps are direct constraints. There is no VST3 or Audio Units hosting for audio work and no OpenFX path for third-party video effects. HEVC and AV1 delivery export are also missing, and AAF or OMF interchange has not been validated in Avid Media Composer or Pro Tools. For many working editors, one of those omissions is enough to stop an evaluation before interface familiarity matters.
Windows and Linux builds exist, but the platform assessment says most development and runtime testing happen on macOS. The browser target compiles, while its application shell is unfinished. Those distinctions matter because a downloadable artifact proves that a build completed. It does not prove that audio devices, GPU drivers, file pickers and long exports behave correctly on the machine receiving it.
Who should install 0.2.0
FilmCraft 0.2.0 makes sense for Rust developers, codec specialists and editors willing to test copies of non-sensitive media. The project asks for reports made with real footage, and its atomic saves, rolling autosave and crash-recovery journal show that data loss is being treated as an engineering problem. Testers should still keep original media and project files outside any experiment.
It is too early to recommend replacing a paid production editor. FilmCraft's own 50-60% estimate says as much, and the missing plugin and acceleration paths are visible constraints rather than edge cases. The value today is access: developers can inspect the codec code, reproduce documented tests and argue with the project's percentages using evidence.
Watch Issue 30 for published before-and-after playback measurements and the roadmap for the promised automated parity tool. A public corpus of ordinary phone and camera files, paired with Windows and Linux runtime checks, would test the environments the project currently says are thin. Those results would show whether the 50-60% figure is moving for reasons an editor can feel on the timeline.