onnx-tensorflow: Running ONNX Models Through TensorFlow, and Why the Repo Is Looking for a New Owner

The Direction Problem onnx-tensorflow Solves

ONNX is a serialization format, not a runtime. A model saved as an ONNX graph still needs an execution engine, and if your serving stack is TensorFlow, you cannot hand an ONNX file to TensorFlow directly. onnx-tensorflow closes that gap in one direction: it takes an ONNX model, converts it to a TensorFlow representation, and delegates execution to TensorFlow to produce the output. The README frames this as one of two converter projects in the ONNX community, with tf2onnx handling the opposite direction, TensorFlow models to ONNX. That split matters more than it first appears. The two projects share a lineage but not a purpose, and the README explicitly says the code from onnx-tf's frontend work was merged into tf-onnx, with a migration recommendation for current onnx-tf frontend users. The audience for this repository is therefore narrow: teams that already have ONNX artifacts and a TensorFlow 2.8.0 environment they intend to keep.

Conversion and Execution: Two Modes, One Pipeline

The mechanism is a conversion step followed by delegation. The README describes it plainly: the ONNX model is first converted to a TensorFlow model and then delegated for execution on TensorFlow to produce the output. There are two ways to reach that pipeline. The CLI form is onnx-tf convert -i /path/to/input.onnx -o /path/to/output, which writes a TensorFlow representation to disk. The programmatic form skips the intermediate artifact: load the ONNX file with onnx.load, call prepare(onnx_model) from onnx_tf.backend, and call run(input) on the result. The README's snippet is three lines, and the third line is where inference actually happens. That distinction is worth holding onto. Conversion alone gives you a graph you can inspect or save; prepare().run() gives you an execution path. The repository layout supports this reading: onnx_tf holds the main source, test holds the test files, and the operator coverage is tracked separately in doc/support_status.md rather than in the README. Coverage is not uniform across the ONNX operator set, and the support status document is the only place that answers whether a given model will convert.

Installing It Without Breaking Your TensorFlow Environment

Installation is deliberately split so that onnx-tf does not drag a TensorFlow variant into your environment. The README says users often have their own preferences for CPU versus GPU builds, so tensorflow is not a declared install requirement, and it becomes the user's responsibility to provide a suitable variant. The constraint is explicit: TensorFlow version == 2.8.0. Not a range, not a minimum. The production install is pip install onnx-tf, with ONNX as an external dependency, and the README notes that protoc should be available if you install ONNX via pip. The supported ONNX release version is recorded in ONNX_VERSION_NUMBER and encoded into setup.py, so pip resolves it for you rather than leaving you to match versions by hand. For development, the README lists a different path: install ONNX from the master branch, install TensorFlow >= 2.8.0 along with tensorflow-probability and tensorflow-addons, clone the repository, and run pip install -e . in the onnx-tensorflow directory. Note the discrepancy between the two sections. Production says TensorFlow == 2.8.0; development says >= 2.8.0. The README also states TensorFlow 1.x is no longer supported, which closes off older serving stacks entirely.

The Maintenance Status Is the Headline, Not a Footnote

Before any technical evaluation, the README carries a note at the top: this repo is not actively maintained and will be deprecated, and anyone interested in becoming the owner should contact the ONNX Steering Committee. That is unusually direct for a project README, and it reframes everything below it. The most recent listed release is v1.10.0 from March 2022, with v1.9.0 and v1.8.0 in the two prior years. The repository is not archived and its last push is recent, but a recent push is not the same as active maintenance, and the project's own text says it is not actively maintained. Practically, this means bug reports may not receive a response, operator coverage gaps may stay open, and the TensorFlow 2.8.0 pin is unlikely to move. If you are evaluating this for a production dependency, you are evaluating a project that has announced its own end and is waiting for a successor. That is not automatically disqualifying, but it changes what you are signing up for: you are adopting a frozen artifact, not a maintained library.

What the Test Suite Tells You Before You Commit

The README is unusually candid about testing cost, and that candour is useful. Unit tests run with pip install pytest tabulate followed by python -m unittest discover test, and the README notes that only the ONNX backend tests in test/backend/test_onnx_backend.py require pytest and tabulate. The full suite typically takes between 15 and 45 minutes depending on hardware, and the README recommends running it before deploying onnx-tf. The model zoo tests are a separate exercise. test/test_modelzoo.py scans a cloned copy of the ONNX Model Zoo, and for each model found it downloads the model, converts it to TensorFlow, generates a status report, and deletes the model. The README states that model inferencing on the converted model is not tested currently, which is a meaningful gap: a model can pass conversion and still fail at runtime. The zoo uses Git LFS, so git-lfs must be installed, and the default assumption is that the models repository sits inside the project directory. Testing all models takes at least an hour. Reports from merged commits are published on the project wiki.

Where onnx-tensorflow Is the Wrong Tool

Three cases stand out. First, TensorFlow 2.9 or later. The production requirement is pinned to 2.8.0, and nothing in the README suggests a path around it. If your environment has moved on, this project is not a candidate. Second, converting TensorFlow models to ONNX. That is tf2onnx, and the README's migration note points current onnx-tf frontend users there because the code was merged into it. Third, any deployment where you cannot run the full test suite against your actual models. The README is explicit that inferencing on converted model zoo files is not tested, so a successful conversion is not evidence that the model runs correctly. If your operators are not covered in doc/support_status.md, you will find out at conversion time, and the support status document is the only place that answers the question. There is also a subtler limitation: because tensorflow is not an install dependency, a mismatched TensorFlow variant will not be caught at install time. It surfaces later, as a runtime failure.

tf2onnx Is the Mirror Image, Not a Drop-In Substitute

The natural comparison is tf2onnx, and the README names it directly. The difference is direction, and direction determines which one you want. onnx-tensorflow takes an ONNX graph and produces a TensorFlow graph for execution on TensorFlow. tf2onnx takes a TensorFlow model and produces an ONNX graph for execution on an ONNX runtime. They are not interchangeable, and choosing between them is not a matter of preference: it depends on which format your artifacts are already in and which runtime you intend to serve from. The relationship is closer than a simple rivalry, though. The README states that the two projects joined forces to co-develop the ONNX TensorFlow frontend, and that onnx-tf's code was merged into tf-onnx, with a migration recommendation for existing onnx-tf frontend users. So for the frontend direction specifically, the README's own guidance is to move to tf2onnx. onnx-tensorflow remains the project for the backend direction, ONNX in, TensorFlow out.

Licence, Upgrade Cost and the Decision

The repository's licence is recorded as NOASSERTION, which means the licence could not be automatically identified from the repository metadata. That is a flag, not a verdict. If you intend to redistribute onnx-tf or ship it inside a product, read the actual LICENSE file in the repository and get your own legal review; nothing here substitutes for that. On upgrade cost, the picture is straightforward and unappealing. The TensorFlow pin to 2.8.0 is a hard constraint stated in the README, the latest listed release is from March 2022, and the README says the project is not actively maintained and will be deprecated. Upgrading your TensorFlow version is therefore an upgrade away from this project, not within it. The realistic adoption profile is a team with an existing ONNX artifact, a TensorFlow 2.8.0 environment they are not moving, and a willingness to run python -m unittest discover test and check doc/support_status.md for their operators before trusting a conversion. Everyone else should look at the ONNX runtime for ONNX execution, or tf2onnx if the goal is to produce ONNX rather than consume it.

Editorial conclusion

Adopt onnx-tensorflow only if you are pinned to TensorFlow 2.8.0 and need to execute an existing ONNX graph on that runtime; the README states the repo is not actively maintained and will be deprecated, and it asks interested parties to contact the ONNX Steering Committee about ownership. Do not adopt it for new TensorFlow 2.9+ work or for converting TensorFlow models outward; that direction belongs to tf2onnx. Before committing, run the unit suite (python -m unittest discover test) on your target hardware and check your operators against doc/support_status.md, because the README notes the full suite takes 15 to 45 minutes.

Official sources

1. Issues
2. onnx/onnx-tensorflow on GitHub
3. README
4. Releases