A terminal cost is an additional term in the MPC objective function that penalizes the predicted state at the end of the prediction horizon, while a terminal constraint is a requirement that this final predicted state must lie within a specific, pre-defined set (the terminal set). Together, they act as a surrogate for the infinite-horizon cost, ensuring the finite-horizon MPC optimization approximates a stabilizing, long-term control policy. This design is rooted in Lyapunov stability theory, where the terminal cost often serves as a control Lyapunov function for the system under a local stabilizing controller.
Glossary
Terminal Cost and Terminal Constraint

What is Terminal Cost and Terminal Constraint?
Terminal cost and terminal constraint are two key design elements in Model Predictive Control (MPC) used to mathematically guarantee the long-term stability of the closed-loop system.
The terminal set is typically designed as a positively invariant region under a local linear controller, such as a Linear Quadratic Regulator (LQR). Enforcing the terminal constraint ensures the system state enters this region where the local controller is known to be stabilizing. The terminal cost is frequently chosen as the value function from the associated infinite-horizon LQR problem, solving the Algebraic Riccati Equation (ARE). This combination provides a formal proof of nominal stability for the MPC law, a critical requirement for safety-critical applications in robotics and process control.
Key Functions and Mathematical Roles
Terminal cost and terminal constraint are complementary design tools in Model Predictive Control (MPC) used to mathematically guarantee the long-term stability of the closed-loop system, addressing the inherent limitation of a finite prediction horizon.
The Stability Guarantee Problem
The core challenge in finite-horizon MPC is that optimizing over a short window can lead to myopic control actions, potentially driving the system to a suboptimal or unstable state beyond the horizon. This is known as the infinite-horizon approximation problem. Terminal elements are the primary theoretical mechanism to ensure that the finite-horizon optimization yields a policy with desirable infinite-horizon properties, namely asymptotic stability.
Terminal Cost Function
A terminal cost is an additional term, $V_f(x_N)$, added to the standard MPC cost function and evaluated at the final predicted state, $x_N$, at the end of the prediction horizon. Its role is to approximate the cost-to-go from that state to infinity.
- Common Design: Often chosen as the value function of the associated infinite-horizon Linear Quadratic Regulator (LQR), solving the Algebraic Riccati Equation (ARE).
- Effect: It penalizes the optimizer for leaving the system in a state from which future control would be expensive, effectively 'looking beyond' the finite horizon and steering the solution toward long-term optimality.
Terminal Constraint Set
A terminal constraint requires the final predicted state, $x_N$, to lie within a pre-defined terminal region or set, $\mathbb{X}_f$. This set is designed to be a positively invariant and control-invariant set under a local stabilizing controller (e.g., the LQR gain).
- Purpose: It ensures the system reaches a 'safe harbor' by the end of the horizon, from which a simple backup controller can maintain stability and constraint satisfaction indefinitely.
- Typical Form: Often an ellipsoidal or polyhedral set where the local controller is known to be effective and safe.
The Dual Mechanism for Proof
Terminal cost and constraint work together to construct a Lyapunov function for the closed-loop MPC system, which is the standard tool for proving stability.
- The combined MPC cost function (including terminal cost) serves as a candidate Lyapunov function.
- The terminal constraint ensures that from the terminal state, a feasible (and stabilizing) control action exists for the next step.
- The optimization guarantees that the cost at the next time step is non-increasing. This monotonic decrease proves asymptotic stability.
This is formalized in Mayne's Stability Theorem for MPC.
Practical Design Trade-offs
Implementing terminal elements involves engineering trade-offs:
- Conservatism vs. Performance: A small, restrictive terminal set ($\mathbb{X}_f$) guarantees stability but can severely limit the region of attraction (the set of initial states the controller can handle). A larger set improves performance but is harder to design.
- Computational Complexity: Enforcing a terminal constraint adds to the online optimization problem's complexity. For nonlinear systems, defining a suitable invariant set is non-trivial.
- Zero-Terminal-State: A common simplification is setting $\mathbb{X}_f = {0}$ (the origin) and $V_f = 0$. This guarantees stability but often requires a very long prediction horizon to be feasible, increasing computation.
Advanced Variations & Alternatives
Modern MPC research has developed methods to reduce conservatism:
- Quasi-Infinite Horizon MPC: Uses a terminal cost from the LQR over an infinite horizon but only enforces a terminal constraint for a finite period, balancing guarantee and feasibility.
- Constraint Tuning: The terminal set can be computed offline via algorithms that find the maximal control-invariant set for the local controller.
- Stability without Terminal Constraints: Techniques like using a sufficiently long prediction horizon (horizon tuning) or a contractive constraint can sometimes ensure stability without an explicit terminal set, at the cost of less rigorous guarantees.
How They Guarantee Stability: The Lyapunov Argument
The Lyapunov argument is a formal mathematical proof technique used to guarantee the closed-loop stability of a Model Predictive Control (MPC) system. It leverages the concepts of a terminal cost and a terminal constraint to construct a Lyapunov function, proving that the controller drives the system state to a desired equilibrium.
In control theory, Lyapunov stability is proven by constructing a scalar Lyapunov function that acts like an energy measure for the system. For MPC, stability is not inherent due to the finite prediction horizon. The Lyapunov argument provides a remedy: by designing a terminal cost that approximates the cost-to-go beyond the horizon and a terminal constraint set that is control invariant, the finite-horizon MPC optimization can be shown to be a valid Lyapunov function, guaranteeing that the system state converges to the target.
The terminal cost is often chosen as the value function of a locally stabilizing controller, like a Linear Quadratic Regulator (LQR), evaluated at the final predicted state. The terminal constraint requires the final state to lie within a positively invariant set where this local controller is valid. Together, they ensure the optimal cost decreases over time, which is the key condition for asymptotic stability. This design transforms the MPC policy into a stabilizing control law, bridging the gap between optimal finite-horizon control and guaranteed long-term performance.
Design Approaches and Trade-offs
A comparison of the primary design methodologies for ensuring closed-loop stability in Model Predictive Control (MPC) by incorporating a terminal cost and/or terminal constraint.
| Design Feature / Metric | Terminal Cost Only | Terminal Constraint Only | Terminal Cost + Constraint |
|---|---|---|---|
Primary Stability Mechanism | Penalizes distance to target at horizon end | Forces final state into a pre-defined invariant set | Combines penalization and set invariance |
Typical Terminal Set | Not explicitly defined | Control Invariant Set (e.g., Maximal Positively Invariant Set) | Control Invariant Set (often a sub-level set of the terminal cost) |
Online Optimization Complexity | Low (adds one term to cost) | High (adds a potentially non-convex constraint) | High (adds both term and constraint) |
Feasibility Guarantee | No inherent guarantee | Yes, if initial problem is feasible | Yes, if initial problem is feasible |
Prediction Horizon Length Required | Long (to approximate infinite horizon) | Can be shorter (set provides stability) | Can be shortest (synergistic effect) |
Common Design Method | Solve Algebraic Riccati Equation (ARE) for LQR cost | Compute Maximal Positively Invariant Set offline | Use Lyapunov function as terminal cost within its invariant set |
Robustness to Initial Guess | High | Low (sensitive to feasible region) | Medium |
Implementation Example | LQR cost as quadratic terminal penalty | Terminal equality constraint (x_N = 0) | Terminal cost from LQR with constraint x_N ∈ Ω |
Frequently Asked Questions
Terminal cost and terminal constraint are critical design elements in Model Predictive Control (MPC) used to mathematically guarantee the long-term stability of the closed-loop system. These tools shape the controller's behavior at the end of its prediction horizon to ensure it acts as a stabilizing controller.
A terminal cost is an additional term, denoted as V_f(x_N), added to the standard MPC cost function and evaluated at the final predicted state x_N at the end of the prediction horizon. Its primary purpose is to approximate the "cost-to-go" from that final state to infinity, acting as a Lyapunov function to penalize states that are far from the desired equilibrium or target set. By incorporating this penalty, the controller is incentivized to drive the system toward a region where a simple, stabilizing local controller (like a Linear Quadratic Regulator (LQR)) could take over, thereby ensuring the finite-horizon optimization yields an infinite-horizon stabilizing policy. A common design is to set the terminal cost as the optimal cost function of the associated LQR problem, solved via the Algebraic Riccati Equation (ARE).
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Terminal cost and terminal constraint are design tools within Model Predictive Control (MPC) to ensure closed-loop stability. They are part of a broader mathematical framework for optimal, constrained control.
Lyapunov Function
A Lyapunov function is a scalar, energy-like function used to prove the stability of a dynamical system's equilibrium point. In MPC stability proofs, the terminal cost is often designed as a Lyapunov function for the system under a local controller. This guarantees that the predicted state at the horizon's end is moving toward the desired setpoint, ensuring the overall MPC law is stabilizing.
- Role in MPC: Provides the theoretical foundation for proving that an MPC controller will drive the system to its target.
- Terminal Cost Design: A common approach is to set the terminal cost equal to a Lyapunov function for the system linearized around the setpoint.
- Decrease Condition: Stability is proven by showing this function's value decreases along the system's trajectory.
Optimal Control Problem (OCP)
The Optimal Control Problem (OCP) is the core mathematical formulation solved at each step of MPC. It defines the optimization over a prediction horizon.
- Components: An OCP consists of a dynamic model (state equations), a cost function to minimize, and constraints on states and control inputs.
- Terminal Elements: The terminal cost and terminal constraint are specific components added to the standard OCP formulation to enforce stability guarantees.
- Solving: The MPC algorithm solves a discretized version of this OCP in real-time to generate the optimal control sequence.
Receding Horizon Control
Receding Horizon Control is the fundamental operating principle of MPC. Only the first control input from the optimized sequence is applied to the system. The horizon then "recedes" forward one step, and the OCP is re-solved with a new initial state measurement.
- Connection to Terminal Elements: The terminal cost and constraint work within this receding horizon framework. They ensure that each finite-horizon optimization, when applied in a receding horizon fashion, results in infinite-horizon stability.
- Practical Impact: This principle is what makes MPC feedback-based and adaptive to disturbances.
Constraint Handling
Constraint handling refers to the methods by which MPC enforces limits on system states and control inputs. Terminal constraints are a specific, powerful form of constraint.
- Hard vs. Soft Constraints: Hard constraints (like a terminal constraint) must never be violated. Soft constraints can be breached at a quantified penalty, often using slack variables to ensure the optimization problem remains feasible.
- Terminal Constraint Set: This is a hard constraint requiring the final predicted state to lie within a pre-computed invariant set (often a positively invariant set).
- Feasibility: A primary challenge is ensuring the OCP with a terminal constraint has a feasible solution at every time step.
Stability (Nominal and Robust)
Stability guarantees that the closed-loop system converges to a desired setpoint or region. Terminal cost and constraint are primary tools to achieve nominal stability (perfect model).
- Nominal Stability: Guaranteed if the terminal cost is a local Lyapunov function and the terminal set is positively invariant under a local controller. The combined design ensures the optimal cost function acts as a Lyapunov function for the closed-loop MPC system.
- Robust Stability: Extends guarantees to systems with model error or disturbances. Techniques like tube-based MPC or constraint tightening are used, which may also involve robust versions of terminal ingredients.
- Verification: Stability is a theoretical property proven during controller design, not just an observed outcome.
Algebraic Riccati Equation (ARE)
The Algebraic Riccati Equation (ARE) is a key matrix equation in linear optimal control. Its solution is central to designing the terminal cost for Linear Quadratic Regulator (LQR)-based MPC.
- LQR Connection: For an unconstrained linear system with a quadratic cost, the infinite-horizon optimal controller is a constant state-feedback gain found by solving the ARE.
- Terminal Cost Design: In linear MPC, a common and effective choice for the terminal cost is the quadratic form defined by the solution matrix P of the ARE. This makes the finite-horizon MPC cost approximate the infinite-horizon LQR cost.
- Terminal Set: The associated LQR controller often defines the local controller used to compute the terminal constraint set.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us