What do you give up by subclassing keras.Model instead of using the Functional API?

## The core distinction: a model as data versus a model as code A Functional model is a **declarative artifact**. Its topology is a recorded graph — which layer was applied to which tensor — and that graph is inspectable, serializable and sliceable. A subclassed model is an **imperative program**. The architecture exists only as the sequence of statements Python executes when `call()` runs. Every capability in the list below follows from this one distinction, and being able to derive them from it, rather than reciting them, is what separates a strong answer from a memorised one. ## What you actually lose **Shape inference before execution.** Functional models propagate shapes from `keras.Input` at construction time, so a wrong hidden dimension is a construction-time error. Subclassed models learn their shapes by running, so the same mistake costs you a forward pass — and in a distributed or long-warm-up setting, considerably more than that. **Full introspection.** `model.summary()` on a subclassed model reports layers and parameter counts once built, but frequently cannot report per-layer output shapes, because no node graph links one layer's output to the next layer's input. `keras.utils.plot_model` has correspondingly little to draw. For a model that other people review, this is a real loss of communicable structure. **Graph surgery.** `model.get_layer("block3").output` returns nothing on a subclassed model — the layer was only called inside Python. Feature extraction, perceptual losses, cutting a pretrained backbone at a chosen depth and attaching a new head: all of these depend on the recorded graph. **Free serialization.** A Functional topology is configuration, so it round-trips without help. A subclassed model's architecture is code, so restoring it requires that code to be importable, plus `get_config`/`from_config` and serialization registration if it is to be reconstructed from a saved file rather than rebuilt by hand. **Structural validation.** The Functional API rejects impossible wiring as you write it — mismatched merges, disconnected inputs. Subclassing accepts anything Python accepts and defers judgement to runtime. ## What you gain **Data-dependent control flow.** A branch taken on the basis of a runtime value, a loop whose count depends on the input, recursion, an early exit — none of these can be expressed as a static graph of layer calls, and all of them are ordinary Python in `call()`. **Multiple, stateful forward paths.** Models whose forward pass differs structurally between phases — some multi-stage generative and reinforcement-learning setups, models with internal memory or per-step caches — are far more natural to write imperatively. **Readability for genuinely algorithmic models.** When the model *is* an algorithm rather than a topology, code that reads like the algorithm beats a graph assembled out of merge layers. ## The Keras 3 portability angle Keras 3 runs on TensorFlow, JAX and PyTorch, chosen by the `KERAS_BACKEND` environment variable. A Functional model is portable by construction, because it is only ever built out of Keras layers. A subclassed `call()` is portable only if it stays within Keras's own operations — `keras.ops` is the backend-agnostic numerics layer for exactly this. The moment `call()` reaches for a raw backend tensor API, the model is pinned to that backend. This is a cost that did not exist in Keras 2 and it is worth naming explicitly, because it turns a stylistic choice into a portability decision. ## The pattern that resolves the tension Almost no real model needs a subclassed *Model*. What it usually needs is one novel *block* — a gated fusion, an unusual attention variant, a custom normalisation. Subclass `keras.layers.Layer` for that block, then wire it into a Functional graph like any other layer. You keep the arbitrary Python where you need it, and you keep shape inference, summary, plotting, surgery and serialisation for the model as a whole. This hybrid is the answer an experienced practitioner gives, and offering it unprompted is a strong signal. ## How to decide Ask what the forward pass depends on. If it depends only on the *shape* of the input, the graph is static and Functional is strictly better. If it depends on the *values* — a decision made per batch — you need the imperative path, and you should then pay the cost deliberately: build the model explicitly rather than lazily, write the serialization hooks, and document the expected input shapes that the framework no longer enforces for you.