Keras 3 puts one model API across 4 backends
Keras 3 targets JAX, TensorFlow, PyTorch, and OpenVINO through one high-level Python interface. The first 3 can train models; OpenVINO is an inference-only option. This arrangement suits teams that want familiar layers, losses, optimizers, and training calls while retaining some choice about the engine underneath. The README also presents Keras 3 as a replacement for Keras 2, which remains available separately as tf-keras.
Portability has practical limits in a codebase of about 329,907 source lines. Built-in Keras components are designed to cross backend boundaries. Custom work can do the same when it uses keras.ops and other neutral interfaces. Code written directly against TensorFlow operations stays tied to TensorFlow until someone rewrites it. Model definitions may travel, while custom training steps, data behavior, device code, and debugging habits still need tests on every backend a team intends to support.
A 4,167 MB install changes the meaning of easy setup
Our sandbox installed 196 packages in 98 seconds and ended with 4,167 MB on disk. The build itself took only 5 seconds. Keras is easy to request from pip, yet a development environment includes far more than the top-level package. The repository tells users to install a backend separately, and its local requirements can cover several of them. Budget storage and dependency resolution before adding this checkout to each developer machine or a small CI runner.
GPU setup is split across TensorFlow, JAX, and PyTorch dependency files. Each route expects an NVIDIA driver, and the README recommends a clean environment to avoid CUDA conflicts. Windows developers are directed to WSL2; Linux and macOS are the named local platforms. Keras reads the selected backend before import and will not change it in the same process. A service offering several engines needs separate processes or jobs that choose one engine per deployment.
What happened when we ran it
Our run cloned commit 53c11fd into an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. Installation succeeded in 98 seconds, adding 196 packages and consuming 4,167 MB. The source build succeeded in 5 seconds. Before installation, the checkout held 1,027 files, roughly 329,907 source lines, and occupied 11.9 MB.
The tests did not finish within our 900-second cap. The final log was still at 1%, in applications_test.py. Visible channels-last NASNet and ResNet cases had passed, while corresponding channels-first cases were skipped. The last line showed the ResNet50V2 channels-last case starting, without a recorded result. That tail does not prove a defect or a passing suite. It shows that this checkout needs a longer test window than our sandbox allowed.
Pip-audit reported 28 known vulnerabilities among the installed dependencies. Our measurement does not identify their severity, reachability, or source packages, so the count cannot be treated as 28 exploitable Keras flaws. An adopter still needs to export the resolved environment, map each advisory to runtime use, and update affected dependencies where possible. The repository includes 14 CI workflow files, no Dockerfile, and no top-level tests directory.
Backend portability stops at custom framework calls
The README names 4 backends, with its strongest portability case applying to code built from Keras interfaces. A standard model can use familiar compile, fit, evaluate, and predict calls across JAX, TensorFlow, and PyTorch. Custom components written with one framework's tensor operations remain specific to that framework. Keras says they can be converted through its neutral APIs, which is still engineering work. Port one representative model before treating backend choice as interchangeable.
OpenVINO has a narrower contract: inference only. Data input is broader because Keras accepts common pipeline forms, including TensorFlow datasets with other backends. Teams should still check preprocessing, random state, numerical tolerance, serialization, and exported artifacts. One shared API reduces duplicate model code; it does not make 3 training runtimes behave identically in every edge case.
Release v3.12.4 fixed 4 model-loading risks
Keras 3.12.4 was published on July 29, 2026 as a security patch. Its notes describe 4 hardening changes: restricted unpickling for IMDB and Reuters data, verification of intermediary H5 groups, decompression-ratio checks for .keras assets, and restricted unpickling for CIFAR data. Anyone loading downloaded datasets or model archives should treat the patch release as a minimum review point before keeping an older Keras 3 installation.
September 2026 activity shows maintainers are responding
GitHub recorded the last push on September 11, 2026, with 64,317 stars and 180 open issues and pull requests. The combined open count is not a bug count. Issue 23258, about an extra dictionary key being mistaken for a model input, closed on September 10. Issue 23555 proposed a backend-neutral linear-attention layer, and issue 23601 opened a discussion about requiring assigned issues before contributors submit pull requests.
That same-day issue activity and a recent source push show current maintenance. The project also has 14 CI workflow files and an Apache-2.0 license. The less comfortable signal comes from our validation: 900 seconds was insufficient to get beyond 1% of the suite. Contributors should run focused tests during development and reserve much more time for the full matrix.
Keras is worth the weight when backend choice is deliberate
A 5-second build makes Keras quick to inspect, while a 4,167 MB environment and a suite beyond our 900-second cap make it expensive to validate end to end. That cost is defensible when one approachable API must cover 3 training backends. It is harder to justify after a deployment has standardized on one engine and regularly uses its specialized interfaces. Test a representative model on the 2 backends you might deploy, including custom layers and saved files, before calling the code portable.