Scenic: Google Research's JAX and Flax Codebase for Attention-Based Vision Models
Scenic: A Jax Library for Computer Vision Research and Beyond
At a glance
- What is it?
- Scenic is a research codebase, not a framework. It pairs shared training libraries with per-project forks, and that choice shapes who can use it and what it costs to keep.
- Who is it for?
- Adopt Scenic if you are training attention-based vision models on multi-device hardware and you intend to modify the training loop, because the forking model assumes you will. Do not adopt it if you need a stable API with semantic versioning and a changelog; the repository has no releases retrieved, so pin a commit hash and read the project directory you depend on before upgrading.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Scenic solves, and for whom
Training a large vision transformer involves a lot of code that has nothing to do with the research idea: sharding parameters across devices, writing summaries, checkpointing, building input pipelines, computing metrics. Scenic exists to hold that code once. The README describes it as two things: a set of shared light-weight libraries for tasks that come up when training large-scale (multi-device, multi-host) vision models, and several projects containing problem-specific training and evaluation loops built on those libraries.
The intended user is a researcher who has a model idea and does not want to rebuild the surrounding machinery. The listed projects make the scope concrete: ViViT for video, OmniNet, PolyViT, TokenLearner, MatFormer, DETR and Deformable DETR for detection, SAM and CLIP baselines, U-Net, MLP-Mixer, PonderNet. If your work sits in that neighbourhood, classification, segmentation, detection, over images, video, audio, or multimodal combinations, the boilerplate is already written. If your work is a small convolutional model on a single GPU, Scenic is more infrastructure than the problem needs.
The forking philosophy and what it does to the code
The README states the design position directly: Scenic prefers "forking and copy-pasting over adding complexity or increasing abstraction." That is an unusual thing for a library to say, and it explains the repository layout. The shared libraries stay thin. Each project under scenic/projects carries its own training entry point rather than inheriting a single configurable trainer.
The practical consequence is that model code is not parameterised behind a registry. A project's train loop is a file you read and edit. For research this removes a layer of indirection: when a paper's method needs a different loss or a different evaluation schedule, you change the loop instead of finding the hook that the abstraction left for you. The cost is duplication. Two projects that both train a ViT may share no more than the library imports, and a fix applied in one project does not reach the other. The README presents this as a trade for simplicity, and it is a real trade, not a free win. Anyone expecting a single trainer that covers every project will not find one.
How the libraries and projects fit together
The README lists what the shared layer offers: boilerplate for launching experiments, summary writing, logging and profiling; optimized training and evaluation loops, losses, metrics and bi-partite matchers; input pipelines for popular vision datasets; and baseline models including non-attentional ones. The bipartite matcher is a specific signal about the intended workload, since it is the component DETR-style detection training needs to assign predictions to targets.
The build rests on JAX and Flax. JAX supplies the array and transformation layer, Flax the module and parameter handling. The README does not describe the internal module names or the exact data flow from dataset to step function, so the precise wiring is something you read from the project you use, not from the top-level document. What is confirmed is the shape: shared libraries below, self-contained projects above, and a per-project main.py as the entry point. The README also points to a baselines directory described as containing strong non-attentional baselines, which matters if you need a comparison point that is not a transformer.
Getting a training run started
The README's getting started section is the place to look for install and launch commands, and the projects directory README lists the hosted projects. The pattern the repository documents is to run a project's main.py as a module with a config, rather than invoking a single top-level binary. Because the material supplied here does not include the verbatim command lines, treat the following as the shape to confirm against the project README before running anything: a python -m invocation of the project's main entry point, a --config flag pointing at a config module, and a --workdir flag for checkpoints and summaries.
Two constraints are visible from the repository description alone. First, the entry point is per project, so the module path differs between ViViT and DETR; there is no shared scenic.train. Second, the shared layer covers logging, profiling and summary writing, so the workdir is where you should expect those artifacts to land. Before committing to a run, open the project's config file and check the batch size and device count, since the README frames the libraries around multi-device, multi-host training and the defaults are set for that setting, not for one accelerator.
Where Scenic is the wrong tool
The absence of releases is the first limitation. No releases were retrieved for this repository, so there is no versioned artifact to pin by tag, no changelog to read before an upgrade, and no compatibility promise between the libraries and the projects. You pin a commit hash and you accept that a later commit may change a project's config keys or its entry point.
The second limitation follows from the forking philosophy. If you need one trainer that serves many model families through configuration, Scenic is built the other way. If you need a model that is not in the projects list and not close to one, you are writing the loop yourself, and the shared libraries will help with logging, metrics and input pipelines but not with the architecture.
The third is scale. The README frames the libraries around large-scale, multi-device, multi-host training. A single-device experiment gains little from the sharding and summary machinery and pays the setup cost anyway. A fourth, harder to quantify point: because projects are copied rather than shared, the quality of documentation and maintenance varies by project, and the top-level README does not claim otherwise.
Scenic against timm and Hugging Face Transformers
The obvious comparison is timm or the vision side of Hugging Face Transformers. Those projects optimise for a different thing: a stable, importable model zoo with a consistent interface, so that from_pretrained returns a model you can fine-tune without reading the training code. Scenic optimises for the opposite: the training loop is in the repository, editable, and specific to each project.
The difference shows up the moment you want to change something. With a model-zoo library you work through the configuration surface the maintainers exposed, and changes outside it mean forking anyway. With Scenic you fork from the start, which is more work up front and less friction later. The other difference is scope. Scenic's projects cover video, audio, multimodal and detection work that a classification-focused model zoo does not, and the README lists the papers those projects came from, which is useful when you need to check whether a reimplementation matches the published method.
Maintenance, licence and upgrade cost
Scenic is licensed under Apache-2.0, which permits commercial use and modification and requires that you retain the licence and notices; it also includes a patent grant. That is the standard permissive arrangement, and it is compatible with keeping a fork private. This is a description of the licence text, not legal advice; if you are shipping a product, have counsel review the NOTICE handling.
The maintenance cost is the forking model applied over time. Because projects are copies, upstream fixes do not arrive automatically in your fork, and because there are no releases, there is no upgrade path other than diffing commits. The realistic workflow is to pin a commit, keep your changes in a branch or a separate project directory, and re-apply them when you move forward. The repository's last push was 2026-09-03, so the codebase is active, but activity is not the same as a stability contract, and nothing in the README promises one.
Who should adopt Scenic
Adopt it if your research is attention-based vision, your compute is multi-device, and you expect to modify the training loop. The projects list is the strongest argument: if your method is adjacent to ViViT, DETR, PolyViT, MatFormer or the SAM and CLIP baselines, you are starting from a working loop rather than an empty file, and the README's links to the originating papers let you check the implementation against the method.
Do not adopt it if you need semantic versioning, a changelog, or a single trainer that covers many architectures through config. Do not adopt it for a small single-device experiment where the sharding and summary machinery is overhead. Before you commit, verify three things in the repository itself: that the project you need exists under scenic/projects, that its config matches your dataset and accelerator count, and that the licence headers in the files you copy are preserved in your fork. If the project you need is not there, the libraries alone will not carry the architecture work.
Editorial conclusion
Adopt Scenic if you are training attention-based vision models on multi-device hardware and you intend to modify the training loop, because the forking model assumes you will. Do not adopt it if you need a stable API with semantic versioning and a changelog; the repository has no releases retrieved, so pin a commit hash and read the project directory you depend on before upgrading. Verify first that the specific project you need (ViViT, DETR, SAM, or another) is present and that its config matches your dataset and accelerator count, since each project carries its own main.py.
Community notes