Standard v3.3 returns 216 high-level file labels
Magika identifies content from file bytes rather than a name or extension. The standard v3.3 model's documented tool output contains 216 labels spanning source code, documents, archives, media, executables, fonts, and several generic results. Empty files, directories, symbolic links, and inputs too small for the model take separate heuristic paths. A successful result includes a simple label, human description, MIME type, group, text flag, possible extensions, and the model's confidence score.
Our full checkout measured 578 files, roughly 22,586 lines of source, and 98.2 MB. The repository contains a Rust CLI and library, a Python package, an experimental JavaScript package, model assets, a website, and a Go binding marked work in progress. The command line can scan many paths recursively and return plain text, custom fields, JSON, or JSONL. For application code, the project recommends using its simple label rather than parsing the prose description or treating MIME type as stable.
A few 2 KB slices make classification fast and imperfect
The documentation says the model usually inspects up to 2 KB from selected parts of a file instead of reading the whole payload. Google reports training and evaluation on about 100 million samples across more than 200 content types, roughly 99 percent average precision and recall on its test set, and about 5 ms inference after model loading on one CPU. Those are project claims from its data and method, not numbers from our Go sandbox.
Limited sampling is also the design tradeoff. Per-type thresholds decide whether Magika returns the model's specific guess or falls back to generic text or unknown binary data. Version 1.1.0 issue 1413 shows a 1,560-line shell script classified as Tcl after syntax from embedded Awk appeared near the sampled tail. Issue 1414 reports scripts with long licence headers or POD documentation returning unknown. A label is a routing hint, not proof that the rest of the file matches it.
What happened when we ran it
Our sandbox entered ./go/ at commit 174e00c and installed 2 packages in 7 seconds. The build passed in 12 seconds. go test then completed in 14 seconds with 2 passed and 0 failed out of 2. The run used a fresh Go 1.24 Debian container with 3 CPUs and 8 GB of RAM. The repository scan found 18 CI workflow files and no top-level tests directory.
Those 2 tests are a small signal for a project with 578 files. The result confirms that the detected Go target installed, compiled, and passed its available lab command in our stated environment. It does not reproduce the README's accuracy, 5 ms inference, or large-scale Google deployment claims. We did not measure classification speed or feed a file corpus through the model, so this review makes no independent accuracy or throughput claim.
The Go binding adds cgo and ONNX Runtime to deployment
Go users create a scanner with an assets directory and model name, then scan a byte reader. The example uses the cgo and onnxruntime build tags, external link mode, and a library search path for ONNX Runtime. The runtime and Magika assets must already be accessible. A sample Dockerfile shows one way to assemble the C library, model, and Go CLI, but the host application still owns native library discovery and asset updates.
The measured Go setup added only 2 packages and built in 12 seconds, which can hide that production requirement. Teams avoiding native dependencies should call the Rust CLI as a separate process or choose another detector. Other users have lower-friction install paths: pipx, Homebrew, a shell installer, Cargo, and platform archives. No API key, hosted service, or GPU is required for local classification, and the browser demo runs the JavaScript model on the user's device.
Three prediction modes expose the precision tradeoff
Magika offers high-confidence, medium-confidence, and best-guess modes. Thresholds vary by content type because an 80 percent score does not mean the same thing for every class. High-confidence returns fewer specific identifications in exchange for stricter acceptance, while best-guess always exposes the model choice. Automated systems should consume the final output label, log the score and raw model label for diagnosis, and decide how generic results flow through later scanners.
Passing 2 Go tests cannot cover all 216 output labels or hostile file constructions. Open issue 1439 reports a HEIF image identified as MP4 by CLI 1.1.0. Issue 1430 shows GGUF model files returning unknown or unrelated low-confidence guesses, while issue 1421 requests GNU MO support. These reports do not erase the project's published aggregate results. They show why a production pipeline needs representative fixtures, a fallback detector, and explicit handling for unknown results.
The April CLI release trails active September development
GitHub recorded 18,508 stars, 165 combined issues and pull requests, and a last push on September 9, 2026. The latest fixed release is cli/v1.1.0, published April 24, with prebuilt archives for major desktop platforms and GitHub artifact attestations. Python 1.0.2 shipped in February. Same-day repository activity and issue updates show continuing work even though the most recent CLI tag is several months old.
The 18 CI workflows, active content-type fixture request, and detailed model changelog support a mature maintenance process. Open Go issue 1444 reports possible C allocation and error-path leaks in the ONNX wrapper, which deserves attention from long-lived Go services. For a new integration, start with the stable Rust CLI or Python package, pin the model version, record generic results, and test the exact file families your system receives before allowing the label to choose a privileged parser.