Two different arXiv identifiers for one technical report

One report, two identifiers, and a promise already kept

The badge row at the top links the paper to one arXiv identifier. The release channel table, nine sections further down, lists the same paper under a different arXiv identifier with a citation file beside it. So the reference a reader copies depends on which of the two blocks they were reading. The updates table makes it stranger: one row says the PDF was uploaded and arXiv was coming soon, and that row sits in the same month as everything else on the page. A promise of a coming submission next to a table that already carries an identifier means one of the two is stale. Neither number is labelled as an error, so the honest read is that the header and the table were assembled separately and never reconciled.

The release link points at an empty fragment

The channel table's first row is the GitHub releases row, and its link is the repository address followed by a bare hash, with no path to a releases page at all. The support row at the end of the same table uses a relative path that climbs two directories before asking for the issues page. Both are one-character mistakes in a table whose entire job is to give you somewhere to go. The same carelessness shows in the badge row above the title, where the environment setup anchor appears three times in succession and a fourth badge links somewhere else entirely, so the header of the page is four links pointing at two destinations. Small, and it does tell you the page has not been read top to bottom by its owner since assembly.

The second training stage produces weights that are not released

The status table is the most honest thing on the page and it is worth reading in order. Marked released are the first-stage weights for both sizes, the two training scripts, the inference scripts with a stated frame rate and rollout length, and the tools for merging adapters and converting checkpoints. Marked as partially available are the data pipeline with its toy dataset, and the benchmark, which is described as partially open-sourced with fifteen fine-grained metrics and a language-model judge. Marked as coming are the distilled second-stage weights, the reinforcement-learning post-training scripts, other-domain checkpoints, and the acceleration stack. That first omission is the important one: the second stage is an acceleration distillation step that runs in a handful of steps, and its output is the model you would actually want to run.

One dependency is pinned exactly and everything else floats

The dependency list has two dozen entries and only two of them are pinned to an exact version: the distributed training library, fixed at a single patch release, and a text-fixing helper. Everything else is a floor with no ceiling. Only one entry is bounded at both ends, the numeric library, which allows anything below its next major. So a fresh environment resolves to the newest compatible release of the transformer library, the diffusion library, the image library and the video decoder, against a training setup tested against one specific version of one tool. That is fine for exploration and unpredictable for reproducing a training run. The list also makes experiment tracking a hard requirement rather than an extra, which is a choice researchers make deliberately and integrators do not.

There is no packaging metadata, so the install script is the whole story

The repository root holds two training scripts, an install script, a requirements file, and directories for the package itself, inference, helper scripts, vendored third-party code, tools, assets and an example. There is no project metadata file and no packaging script, so this is not installable as a library and nothing declares a package version. The install script is the only supported path, which means the dependency install and whatever else the script does are inseparable, and there is no way to inspect what it will do before running it. The vendored third-party directory is the other half of that story: some of the code lives in this repository and some does not, and the boundary is a directory rather than a manifest.

An upload cache and a misspelled folder are committed in the example

The example directory contains a readme, an assets folder, an inference assets folder, a toy pipeline dataset folder, and a hidden directory whose name marks it as an upload cache for a model hosting service. That cache is checked into version control, which means someone's upload state is part of the repository history and grows for anyone who later runs the upload path. Beside it, the inference assets folder is misspelled with a doubled letter, the kind of thing that quietly breaks a script referencing it. Neither is a design problem. Both are the fingerprint of an example folder assembled while testing rather than curated afterwards, which is a fair trade for a research release and worth knowing before you copy it into your own tree.

Production means eight accelerators on one node

The hardware table states the production configuration plainly: a single node with eight of one accelerator or eight of another, on Linux verified on two long-term distributions, with a recent CUDA release recommended to match the local framework build. The two model sizes are small by world-model standards, at 1.3B and 5B, and the inference row says consumer cards work with memory-saving settings. Training on consumer hardware is described as possible rather than supported, via sharding, offloading, gradient checkpointing and reduced batch or resolution. So the eight-card figure is what the reported results were produced on, and the consumer path is an experiment. Anyone budgeting this should treat that line as the cost of the numbers in the report rather than a starting suggestion.

Editorial conclusion

Read this as a research release in progress rather than as a finished system, which is what the status table says in its own colours. Four items are marked as coming, including the distilled second-stage weights, which means the code for the step that produces the model you would most want to run is released while its output is not. What is genuinely usable is stage one, the two model sizes, the inference scripts, the data conversion from a common robot dataset format with captioning and depth estimation, and the checkpoint merge and conversion tools. Before you commit hardware, note that the stated production configuration is eight datacenter accelerators on one node, and that the accelerated variant is one of the unreleased items rather than something the released code gives you.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. open-gigaai/giga-world-1 on GitHub
4. README