GO — Healthy across all four use cases

• Last commit 1d ago
• 25+ active contributors
• Distributed ownership (top contributor 14% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Scorecard: known vulnerabilities detected (scored 0/10 by OpenSSF)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

Keras 3 is a multi-backend deep learning framework that provides a unified Python API for building and training neural networks across JAX, TensorFlow, PyTorch, and OpenVINO backends. It abstracts away backend-specific implementation details while allowing users to switch between execution engines (GPU, TPU, CPU) to optimize performance for different model architectures, offering 20-350% speedup improvements by selecting the fastest backend per use case. Monorepo structure: keras/ package is the core API, backend-specific implementations likely split by backend (jax/, tensorflow/, torch/, openvino/), with benchmarks/ containing layer-specific performance tests (activation_benchmark.py, conv_benchmark.py, etc). GitHub Actions workflows in .github/workflows/ define multi-backend CI, with config files (.github/workflows/config/{jax,tensorflow,torch,numpy,openvino}/keras.json) tuning test parameters per backend.

ML engineers and data scientists building production deep learning systems who need framework portability (not locked into one backend), researchers wanting to benchmark models across backends, and organizations scaling from laptop prototypes to datacenter GPU/TPU clusters. Contributors are framework developers maintaining backend implementations and researchers adding new layer types.

Production-ready and actively developed. Keras 3 is the official successor to Keras 2 (now tf-keras), maintains minimum version requirements (TensorFlow 2.16.1, JAX 0.4.20, PyTorch 2.1.0, OpenVINO 2025.3.0), has extensive CI/CD via GitHub Actions (GPU/TPU test workflows, nightly runs), and the large 11.4M+ Python LOC codebase indicates mature, substantial project with active maintenance.

Multi-backend support adds complexity: bugs may surface only on specific backends (JAX/torch/TF), and breaking changes must be coordinated across all four implementations. Windows support is limited (WSL2 recommended per README). Dependency matrix is large (each backend + CUDA variants via requirements-{backend}-cuda.txt), creating version mismatch risks. However, the official Google backing and regular releases reduce abandonment risk.

Active development on backend standardization and performance optimization: GPU/TPU test workflows run regularly, nightly test suite is present, API generation is tracked (api_gen.py and shell/api_gen.sh for keras_export updates), and automated issue triage/labeling is configured. Multi-backend support is the ongoing focus (4 keras.json configs suggest continuous testing/optimization per backend).

git clone https://github.com/keras-team/keras.git
cd keras
pip install -r requirements.txt
python pip_build.py --install
./shell/api_gen.sh  # if modifying keras_export APIs

For GPU support, use requirements-{jax,tensorflow,torch}-cuda.txt instead. Recommend WSL2 on Windows.

Daily commands: No traditional 'dev server' — Keras is a library. Instead: verify installation with python -c 'import keras; print(keras.__version__)', then run benchmarks via python benchmarks/layer_benchmark/activation_benchmark.py or tests via pytest (assumed, not shown). For interactive development, use Jupyter or IPython.

• keras/__init__.py — Main entry point exposing the public Keras API across all backends.
• keras/api — Core API surface definitions and backend-agnostic layer/model abstractions.
• keras/backend — Backend abstraction layer routing operations to JAX, TensorFlow, PyTorch, or OpenVINO.
• keras/layers — All layer implementations (Dense, Conv, RNN, etc.) used across models.
• keras/models — Model classes (Sequential, Functional, Subclass) providing the primary user-facing API.
• conftest.py — Test configuration and fixtures for backend-specific test execution.
• .github/workflows/actions.yml — CI/CD pipeline ensuring multi-backend test coverage on every commit.

• Backend module (keras.backend.*) (Python, NumPy-like API) — Routes all tensor operations to active backend; abstracts JAX, TensorFlow, PyTorch APIs.
  • Failure mode: Operation unavailable on selected backend → TypeError or NotImplementedError.
• Layer classes (keras.layers.*) (Python, backend ops) — Implements layer logic (weight initialization, forward computation) using backend ops.
  • Failure mode: Numerical mismatch across backends if ops differ; gradient computation fails if backprop unsupported.
• Model classes (Sequential, Functional, Subclass) (Python, callbacks, optimizers) — Composes layers, manages training state, orchestrates fit/evaluate/predict loops.
  • Failure mode: Model fails to compile if layer dependency graph is malformed; training diverges if optimizer or loss mismatched.
• Optimizer (keras.optimizers.*) (Backend ops, variable management) — Computes parameter updates given gradients; supports SGD, Adam, RMSprop, etc.
  • Failure mode: Divergence or non-convergence if learning rate or decay schedule is invalid.
• Loss functions (keras.losses.*) (Backend ops) — Computes scalar loss from predictions and ground truth; supports classification, regression, custom losses.
  • Failure mode: NaN/Inf if inputs out of expected range (e.g., log of negative in CrossEntropy).
• Callbacks (keras.callbacks.*) (Python, file I/O) — Hooks into training lifecycle (on_epoch_end, on_batch_end) for early stopping, checkpointing, logging.
  • Failure mode: Early stopping may trigger incorrectly if metric calculation is delayed or stale.

• User data (numpy/dataset) → keras.backend (batching & prefetch) — Data is sliced into batches and prepared for backend-specific tensor conversion.
• keras.backend tensor → Layer.call() (forward pass) — Batched input tensors flow through stacked layers using backend ops.
• Model output tensor → Loss function — Final layer output is compared to ground truth via loss computation.
• Loss scalar → Autodiff engine (gradient computation) — Backward pass computes gradients w.r.t. all trainable variables using chain rule.
• Gradients → Optimizer.update_step() — Gradients are fed to optimizer which applies update rule (e.g., w -= lr * grad).
• Updated weights → Callback & metrics logging — Training metrics and checkpoints are recorded after each epoch.

Add a New Layer Type

1. Create layer class inheriting from keras.layers.Layer with build() and call() methods. (keras/layers/__init__.py)
2. Implement forward pass using backend-agnostic ops (keras.backend.*). (keras/backend/__init__.py)
3. Export in public API via keras/api/layers.py. (keras/api/layers.py)
4. Add layer benchmark test in benchmarks/layer_benchmark/. (benchmarks/layer_benchmark/base_benchmark.py)
5. Write unit tests validating behavior across JAX, TensorFlow, and PyTorch. (conftest.py)

Add a New Optimizer

1. Create optimizer class inheriting from keras.optimizers.Optimizer. (keras/optimizers/__init__.py)
2. Implement update_step() using backend-agnostic variable operations. (keras/backend/__init__.py)
3. Expose in keras/api/optimizers.py. (keras/api/optimizers.py)
4. Test convergence on simple models across all backends. (conftest.py)

Add Support for a New Backend

1. Create backend module (e.g., keras/backend/openvino/) implementing core ops (matmul, reshape, etc.). (keras/backend/__init__.py)
2. Add conditional import logic in keras/backend/init.py to detect and route to new backend. (keras/backend/__init__.py)
3. Add backend config file in .github/workflows/config/<backend>/keras.json. (.github/workflows/config/openvino/keras.json)
4. Create CI workflow step in actions.yml to test all layers and models on new backend. (.github/workflows/actions.yml)

Add a New Benchmark

1. Create benchmark class inheriting from BaseBenchmark in benchmarks/layer_benchmark/base_benchmark.py. (benchmarks/layer_benchmark/base_benchmark.py)
2. Define setup(), run(), and optional teardown() methods with timing instrumentation. (benchmarks/layer_benchmark/base_benchmark.py)
3. Execute via pytest with markers to isolate backend-specific runs. (conftest.py)

• Multi-backend abstraction (JAX, TensorFlow, PyTorch, OpenVINO) — Enables users to switch backends for same model, optimizing performance per architecture (20–350% speedups).
• Functional & Subclass model APIs — Allows both declarative (Sequential/Functional) and imperative (Subclass) model definitions for different developer preferences.
• Python-first design with eager execution — Reduces debugging friction and ship time compared to graph-mode frameworks, especially with JAX/PyTorch backends.
• XLA compilation & JIT — Leverages JAX and TensorFlow's XLA for automatic performance optimization without explicit kernel tuning.

• Backend abstraction layer over monolithic implementation

  • Why: Achieves multi-framework support and performance portability.
  • Consequence: Adds complexity; operations must be implemented in backend-specific ways, risking subtle numerical differences across backends.

• Eager execution by default (vs. graph-mode only)

  • Why: Better debugging and faster iteration during development.
  • Consequence: Cannot automatically optimize dynamic control flow; users must use backend-specific APIs (e.g., jax.lax.cond) for advanced optimizations.

• Inference-only support for OpenVINO

  • Why: Narrows scope to deployment optimization; training still requires JAX, TensorFlow, or PyTorch.
  • Consequence: Limits OpenVINO users to pre-trained models; cannot train directly on Intel hardware.

• Real-time online learning or streaming inference (batch-oriented design).
• Native support for reinforcement learning (focus on supervised/unsupervised learning).
• Hardware initialization or cluster orchestration (assumes pre-configured distributed setup).
• Graph visualization or interactive IDE integration (relies on external tools).

• Avg cyclomatic complexity: ~6.5 — Large codebase with multi-backend abstraction, custom autodiff, and distributed training support; deep inheritance hierarchies in layers and models.
• Largest file: keras/layers (15,000 lines)
• Estimated quality issues: ~12 — Scattered backend-specific imports, inconsistent error handling across backends, and lack of comprehensive type hints in some modules.

• Backend-specific imports leaked into user code (High) — keras/layers, keras/models: Layers directly import TensorFlow or PyTorch instead of routing through keras.backend, breaking portability.
• Inconsistent tensor shape handling across backends (Medium) — keras/backend: Dynamic shape inference differs between JAX (static) and TensorFlow (dynamic), causing shape mismatches at runtime.
• Loss function assumes single-batch reduction (Medium) — keras/losses: Custom losses may not handle batch reduction correctly, causing incorrect gradient magnitudes.
• Stateful layer weights not properly reset between fits (Low) — keras/layers, keras/models: RNN/LSTM layers retain hidden state across multiple model.fit() calls if user does not explicitly reset.

• keras/backend (operation dispatch) (Performance) — Every tensor op must check active backend and route; adds per-op overhead ~1–5% vs. native backend.
• keras/models (Model.fit custom training loop) (Performance) — Python-based training loop with callbacks cannot be JIT-compiled; serializes batch iteration and loss computation.
• Data loading & batching (I/O) — No built-in async data pipeline; users must provide pre-batched numpy arrays or tf.data.Dataset for efficient training.
• Multi-GPU synchronization (distributed training) (Scalability) — All-reduce gradients across devices incurs communication overhead; scales sublinearly beyond ~8 GPUs.

1. Backend selection: Default backend determined by KERAS_BACKEND env var or first installed backend; ensure you export KERAS_BACKEND={jax,tensorflow,torch} to test against a specific backend. 2. CUDA version mismatch: Requirements files install CUDA via pip; can conflict with system NVIDIA driver — separate conda envs per backend recommended (as shown in README). 3. API generation: Modifying keras_export decorators requires running ./shell/api_gen.sh before PR submission, or CI will fail. 4. Windows limitation: Official Windows support absent; WSL2 required, not native.

• Backend abstraction layer — Keras 3's core strength is transparent backend swapping; understanding how it abstracts JAX/TF/PyTorch operations is key to contributing cross-backend features without code duplication.
• Automatic differentiation (autodiff) — All Keras backends (JAX, PyTorch, TensorFlow) rely on autodiff for gradient computation; understanding how each backend implements it explains performance differences and debugging issues.
• Tensor shape inference — Keras layers infer output shapes without materializing tensors; critical for building graphs and debugging shape mismatches across backends.
• Mixed precision training — Performance optimization using float16/bfloat16; Keras abstracts this across backends, but backend-specific bugs surface here.
• Stateful layer serialization — Keras models must save/load weights and config across backends; serialization format must be backend-agnostic, making this a common source of cross-backend bugs.
• Distributed training (data parallelism) — Keras 3 supports datacenter-scale training via backend-specific distribution APIs; understanding how synchronization works per backend is essential for scaling contributions.
• Ragged tensors — Support for variable-length sequences (e.g., NLP); backend implementations differ, requiring careful test coverage.

• tensorflow/tensorflow — TensorFlow is one of four supported backends; Keras 3 depends on it and maintains compatibility.
• google/jax — JAX is the primary high-performance backend for Keras 3; often fastest for model architectures per benchmarks.
• pytorch/pytorch — PyTorch is a supported backend; Keras 3 provides PyTorch eager execution integration.
• keras-team/keras-io — Official Keras documentation and tutorials site; companion repo for keras.io docs and example notebooks.
• huggingface/transformers — Popular downstream consumer of Keras 3 for NLP models; demonstrates production integration patterns.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive cross-backend integration tests for layer benchmarks

The benchmarks directory contains layer_benchmark and model_benchmark modules with individual backend configs (.github/workflows/config/{jax,numpy,tensorflow,torch,openvino}/keras.json), but there's no unified test suite validating that all benchmark modules run correctly across all 5 backends. This would catch regressions when backends diverge in API or performance characteristics.

• [ ] Create benchmarks/test_benchmarks.py to import and validate all benchmark modules from benchmarks/layer_benchmark/ and benchmarks/model_benchmark/
• [ ] Add parametrized tests for each backend (jax, tensorflow, torch, numpy, openvino) using the existing keras.json configs
• [ ] Add a new GitHub Actions workflow (.github/workflows/benchmark_validation.yml) that runs these tests on PRs to catch backend compatibility issues early

Implement backend-agnostic example tests for examples/ directory

The examples/ directory contains demo scripts for custom workflows across different backends (demo_custom_jax_workflow.py, demo_custom_tf_workflow.py, demo_custom_torch_workflow.py), but there are no tests validating that these examples actually run without errors. New contributors often break examples when refactoring core APIs.

• [ ] Create tests/test_examples.py with pytest fixtures that import and execute each example script in examples/
• [ ] Use conftest.py (already present) to set up backend-specific environments for each demo
• [ ] Add these tests to the main CI workflow to prevent example bitrot

Add missing workflow configuration for OpenVINO backend testing parity

The .github/workflows/config/ directory has separate keras.json configs for jax, numpy, tensorflow, and torch, with gpu_tests.yml and tpu_tests.yml workflows, but OpenVINO (an inference-only backend mentioned in README) appears to lack dedicated test coverage workflows comparable to other backends. This leaves a gap in ensuring inference-only functionality doesn't regress.

• [ ] Review .github/workflows/gpu_tests.yml and tpu_tests.yml to understand the test matrix pattern
• [ ] Create .github/workflows/inference_tests.yml that specifically targets the openvino backend using .github/workflows/config/openvino/keras.json
• [ ] Add integration tests in tests/ directory specifically for inference-only operations (forward passes, model loading, quantization) that openvino supports

• Add missing benchmark for a layer type: Check benchmarks/layer_benchmark/ and identify a layer in keras/layers/ without a corresponding _benchmark.py file (e.g., if keras/layers/attention.py exists but attention_benchmark.py lacks full layer coverage), then extend it following BaseBenchmark pattern.
• Improve GitHub Actions configurability: The .github/workflows/config/ directory has 5 keras.json files with likely duplicated test settings; refactor to a single base config with backend-specific overrides, reducing maintenance burden.
• Add Windows CI support: Currently .github/workflows/ lacks Windows test matrix; add conditional step in actions.yml to run pytest on Windows-latest or WSL2, validating the 'WSL2 recommended' claim with actual CI proof.

Keras demonstrates a reasonable security posture with some security documentation (SECURITY.md) and GitHub Actions-based CI/CD controls (Dependabot, scorecard.yml). However, there are gaps in the incomplete security policy, missing dependency analysis capability, and unclear enforcement of security practices. The project handles multiple backends and untrusted inputs, which requires robust security guidance. Primary recommendations: (1) Complete the security policy documentation, (2) implement and enforce pre-commit security hooks, (3) provide comprehensive security guidelines for users handling untrusted inputs and model deployment, and (4) conduct a formal dependency audit given the complex dependency chain across JAX, TensorFlow, PyTorch, and OpenVINO.

• Medium · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file contains incomplete guidance on handling untrusted inputs. The section on 'Untrusted inputs' ends abruptly mid-sentence regarding fuzzing for prompt injection, leaving security recommendations incomplete. This could lead to developers not fully understanding security best practices. Fix: Complete the security policy documentation with comprehensive guidance on input validation, sanitization, and sandboxing strategies. Provide specific code examples and clear recommendations for each threat model.
• Medium · Potential Dependency Vulnerabilities Not Visible — Project root (missing dependency manifest). No dependency files (requirements.txt, setup.py, pyproject.toml, poetry.lock, etc.) were provided for analysis. This prevents assessment of known vulnerabilities in third-party packages used by Keras, including backend dependencies (JAX, TensorFlow, PyTorch, OpenVINO). Fix: Provide and regularly audit dependency files. Implement automated dependency scanning using tools like pip-audit, Snyk, or GitHub's Dependabot (already present in .github/dependabot.yml). Pin versions appropriately and use lock files for reproducibility.
• Low · Hardcoded Configuration Files in Version Control — .github/workflows/config/. GitHub workflow configuration files for different backends (.github/workflows/config/) are committed to version control. While these appear to be public configuration, they should be reviewed to ensure no sensitive defaults or credentials could be accidentally exposed. Fix: Review all configuration files to ensure they contain no credentials, API keys, or sensitive defaults. Consider using environment variables for sensitive configuration values in CI/CD workflows.
• Low · Pre-commit Configuration Present but Enforcement Unclear — .pre-commit-config.yaml. A .pre-commit-config.yaml file exists, indicating a pre-commit framework is configured. However, without reviewing the content, it's unclear if security-focused hooks (secret scanning, code quality) are enforced before commits. Fix: Ensure pre-commit hooks include security scanners such as: detect-secrets, bandit (Python security issues), and gitguardian. Make pre-commit hooks mandatory for all contributors.
• Low · Public Benchmark Code May Contain Test Data Exposures — benchmarks/. Benchmark files in the /benchmarks directory may contain hardcoded test data, model paths, or credentials used during testing. These should be reviewed to prevent accidental exposure of sensitive information. Fix: Review all benchmark files to ensure they use only synthetic or public test data. Store any necessary credentials or paths in environment variables or secure configuration management systems.
• Low · Missing Input Validation Documentation for Models — Documentation and guides (partial visibility). While Keras provides model building capabilities, there's limited visible documentation on input validation best practices for end-users deploying models with untrusted data. The framework should provide clear security guidelines. Fix: Create security-focused guides on: input validation strategies, model serialization security, safe deserialization patterns, and defense against adversarial inputs.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/keras-team/keras shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live keras-team/keras repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/keras-team/keras.

What it runs against: a local clone of keras-team/keras — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in keras-team/keras | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of keras-team/keras. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/keras-team/keras.git
#   cd keras
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of keras-team/keras and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "keras-team/keras(\\.git)?\\b" \\
  && ok "origin remote is keras-team/keras" \\
  || miss "origin remote is not keras-team/keras (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "keras/__init__.py" \\
  && ok "keras/__init__.py" \\
  || miss "missing critical file: keras/__init__.py"
test -f "keras/api" \\
  && ok "keras/api" \\
  || miss "missing critical file: keras/api"
test -f "keras/backend" \\
  && ok "keras/backend" \\
  || miss "missing critical file: keras/backend"
test -f "keras/layers" \\
  && ok "keras/layers" \\
  || miss "missing critical file: keras/layers"
test -f "keras/models" \\
  && ok "keras/models" \\
  || miss "missing critical file: keras/models"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/keras-team/keras"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.