CorridorKey-Runtime: a native AI keying runtime and OFX plugin for DaVinci Resolve and Nuke

What CorridorKey-Runtime solves, and who it is aimed at

Chroma keying a green screen shot is usually a sequence of small decisions: pull a first key, clean the edges, recover spill, then hand the result to a compositor. CorridorKey-Runtime moves that first pass into a native AI runtime that runs on the artist's own machine and exposes itself through three surfaces. The README describes it as a native AI keying runtime and OFX plugin for DaVinci Resolve and Foundry Nuke, built with Corridor Digital. The product surfaces are named explicitly: an OFX plugin for interactive keying inside Resolve and Nuke, a CLI called corridorkey for local processing, diagnostics and automation, and a Tauri desktop GUI for people who prefer a graphical workflow. The stated focus is native local execution and practical deployment in real editing workflows, with support for NVIDIA RTX and Apple Silicon. The audience is therefore narrow and specific: Resolve and Nuke users on those two hardware families, plus integration engineers who want a command line, and desktop operators who want the GUI. If your finishing work happens in a host outside that list, or on hardware outside that list, the project is not addressing you yet.

How the runtime, OFX bundle and CLI fit together

The architecture the README describes is a shared runtime with several thin front ends. The Windows suite installer places the CLI and runtime core as the fixed base; the OFX plugin, the Adobe plugins, the GUI, the Green model pack and the Blue model/runtime pack are optional components layered on top. That ordering matters, because it means the runtime can exist on a machine without any host plugin installed. The OFX plugin is described as host-agnostic: it registers itself at the standard OpenFX bundle path, so any OFX 1.4-compliant host that scans that path picks it up. The README still names Resolve and Nuke as the supported surfaces, so host-agnostic discovery should not be read as a support promise for every OFX host. On Apple Silicon the plugin uses an MLX-accelerated path automatically on M-series chips. On Windows RTX it ships a public FP16 quality ladder with four named rungs (Draft 512, High 1024, Ultra 1536, Maximum 2048), and Auto respects a safe VRAM ceiling for the active GPU tier. The CLI is the same runtime without a host: the Windows suite registers its directory on PATH, and the portable Runtime bundle carries it for minimal installs. The GUI is distributed either as a suite component pointing at the shared runtime root or as a portable bundle that carries the GUI and a local runtime package together, so it does not require the OFX bundle to be present.

Installing the CorridorKey Resolve OFX plugin and running your first key

Releases live on the project's Releases page, and the README says to download the package that matches your platform and product track. On macOS with Apple Silicon the flow is a .pkg installer. Run it with DaVinci Resolve closed, then open Resolve 20, go to the Color or Fusion page, and search for "CorridorKey" in the OpenFX Library. Drag the node onto your clip; the README states that the MLX-accelerated path is used automatically on M-series chips. On Windows the choice is between the RTX installer for NVIDIA RTX 30 series and newer and an experimental DirectML package for DirectX 12 GPUs outside that path. The RTX installer should be run as Administrator with Resolve closed. Expect the first frame to be slow: the README warns that TensorRT RTX compilation on the first frame may take 10-30 seconds. If the node does not appear in the library, help/TROUBLESHOOTING.md is the documented place to look.

corridorkey doctor

The CLI is useful before you ever open a host. The command above checks hardware capability, which is the fastest way to confirm that the runtime sees a supported GPU. The README notes that macOS bundles and source builds use the name corridorkey, while the Windows portable runtime bundle uses ck-engine.exe instead, so substitute accordingly.

corridorkey process input.mp4 output.mp4 --preset max

This processes a video with a named preset; the README also shows a hardware-aware default that omits --preset entirely, and an --alpha-hint flag that takes an external alpha hint file. Appending --json to any command switches the output to NDJSON event streams for pipeline integration, which is the form you want if a render farm is going to parse the result. Building from source needs a C++20 compiler (Visual Studio 2022 v17.4+, Apple Clang 15+ or GCC 12+), CMake 3.28+, Ninja and vcpkg with VCPKG_ROOT set; the README gives the cmake --preset release and cmake --build --preset release sequence, and points Windows users at .\scripts\windows.ps1.

Where CorridorKey-Runtime is the wrong tool

The support matrix is the honest constraint here, and it is narrow. Public builds cover Windows with NVIDIA RTX and macOS on Apple Silicon. The DirectML package is described as an experimental Windows track for DirectX 12 GPUs outside the official RTX path, and the README states plainly that it is not broadly validated across AMD, Intel or RTX 20 series hardware. That is not a marketing hedge; it is a statement that a whole class of machines is untested. The Windows RTX installer itself is scoped to RTX 30 series and newer, so an RTX 20 series card falls outside both tracks. The Adobe After Effects and Premiere plugins are described as packaged implementation targets that are not supported public surfaces until host validation passes, which means anyone whose pipeline is built around those hosts should not plan around them yet. There is also a first-frame cost on Windows: the 10-30 second TensorRT compilation is a real interruption in a session where an artist is iterating quickly, and the README does not document a way to pre-warm or cache that compilation. Finally, manual fixed quality settings on Windows may attempt a higher packaged rung than the hardware can hold, with what the README calls explicit runtime fallback if it fails. That fallback is a safety net, not a guarantee of the quality you selected.

How this differs from a node-based keyer such as Keylight

The obvious alternative for a Resolve or Nuke user is a conventional node-based keyer such as Keylight, which ships inside those hosts and is driven entirely by parameters the artist sets: screen colour, screen balance, clip black and white, despill. The difference in approach is not quality, it is where the decision-making lives. A conventional keyer asks you to describe the screen and then exposes the result for hand-tuning. CorridorKey-Runtime runs an AI model locally and exposes a quality ladder instead of a screen-colour picker, with an optional external alpha hint if you want to steer it. That shifts the work from parameter tuning to preset selection and edge cleanup, which is faster when the shot is difficult and slower when the shot is easy and a two-parameter key would have taken seconds. The other practical difference is hardware. Keylight runs wherever the host runs. CorridorKey-Runtime runs where the runtime supports it, which the README limits to Windows RTX and Apple Silicon. If you are on a CPU-only workstation or an Intel Mac, the conventional keyer is not a fallback, it is the only option.

Maintenance, licensing and build cost

The repository is not archived, and the last push was on 2026-08-05. The most recent release listed is v0.9.1-win.1 from 2026-06-12, whose title covers Resolve, Fusion, Nuke, After Effects, Premiere, a command line and a standalone GUI on Windows. Two earlier Windows releases, v0.9.0-win.2 and v0.9.0-win.1, are dated 2026-06-12 and 2026-05-25. The version numbering is still in the 0.9 range, and the release titles are Windows-specific, so the macOS track should be checked on the Releases page rather than assumed to move in step. Building from source carries a real setup cost: a C++20 toolchain, CMake 3.28+, Ninja and a vcpkg checkout with VCPKG_ROOT exported, plus a vendor/ directory in the tree. Most users should install a packaged release instead. On licensing, the repository metadata reports NOASSERTION, and the repository contains a LICENSE file at the top level. That means the metadata does not map to a recognised SPDX identifier, so the terms have to be read from the file itself. Whether the model packs carry separate terms from the runtime code is not stated in the README. This is not legal advice; if the keyer is going into commercial delivery, read LICENSE and any terms accompanying the model packs before you ship.

Editorial conclusion

Adopt CorridorKey-Runtime if you key on a Windows RTX 30-series or newer machine or an Apple Silicon Mac and want the keyer inside Resolve or Nuke rather than in a separate application. Do not adopt it if you are on DirectX 12 hardware outside the RTX path, on an Intel Mac, or if you need a public Adobe plugin, since After Effects and Premiere are packaged targets that the README says are not supported public surfaces until host validation passes. Verify first: run corridorkey doctor on the target machine, confirm your exact GPU against help/SUPPORT_MATRIX.md, and read LICENSE, because the repository metadata reports NOASSERTION rather than a recognised SPDX identifier.

Frequently asked questions

Official sources

1. alexandremendoncaalvaro/CorridorKey-Runtime on GitHub
2. Issues
3. Project website
4. README
5. Releases