The moment before a deployment is a bad time to open a browser. You need three facts: which version of the model is currently in Production, whether that version finished registering cleanly, and which training run produced it. The MLflow UI can tell you, but getting there means a tab switch, a login, a tree to expand, and a registry page where you have to hunt for the stage column.

ML Experiment Cockpit is a free JetBrains plugin that shows the same facts in a tool window next to your code. This tutorial covers one task only: the pre-deployment check, using the free Models tab, plus the same check written as a script you can run in a pipeline.

What you need

  • A running MLflow tracking server with a Model Registry, in other words MLflow 2.0 or later. The plugin talks to a server you already run: it never starts one, and it does not read a local mlruns/ directory.
  • The plugin, installed from the Marketplace page linked above, in any IntelliJ-platform IDE from build 243 (2024.3) to build 263, which is the range the Marketplace listing states.
  • Your tracking URI, for example http://localhost:5000.

Step 1: point the plugin at your server

Open Settings | Tools | ML Experiment Cockpit and put the URL of your tracking server in the MLflow tracking URI field. This is the same URI you pass to mlflow commands. The Models tab reuses it, so there is nothing else to configure for this task.

Step 2: read the registry

Open View | Tool Windows | ML Experiment Cockpit and select the Models tab, then click Refresh.

The left pane lists the registered models your server returns, sorted by name, each one labelled with the number of versions it reports:

churn-model (2 version(s)) fraud-detector (1 version(s))

Expand a model. Each version appears with its number and its stage, exactly as the server reports it:

fraud-detector (1 version(s)) v4 [Production]

Select the version and the right pane shows the fields that decide whether you ship (the values below are an example):

name : fraud-detector version : 4 stage : Production status : READY run_id : 8f3c1a9d2b7e4c6f9a0d5e1b2c3d4e5f created : 2026-11-10 09:14:22

stage is the MLflow stage: None, Staging, Production or Archived. status is the registration status: READY means the version is registered and ready to be served, while a failed registration would read FAILED_REGISTRATION. run_id is the training run that produced the version, which is your thread back to the hyperparameters and the metric curves; the Experiments tab of the same tool window shows that run without leaving the IDE.

If the Models tab answers with an error about the endpoint, your server is older than MLflow 2.0: the Model Registry does not exist before that, and the plugin says so instead of showing you an empty list.

Step 3: the same answer, without the IDE

The tab is a convenience over one HTTP GET. This is the request the plugin sends your server when you click Refresh:

curl -s 'http://localhost:5000/api/2.0/mlflow/registered-models/search?max_results=500'

A plain GET, with no request body. The answer is JSON with a registered_models array, and each entry carries a name, a description, a creation timestamp and its latest_versions. The plugin reads those fields and nothing else. If your server runs with authentication turned on, add your own credentials to the call.

If you prefer Python, the official MLflow client gives you the same facts, and the same check fits easily into a pipeline:

from mlflow import MlflowClient client = MlflowClient("http://localhost:5000") for version in client.search_model_versions("name='fraud-detector'"): print(version.version, version.current_stage, version.status, version.run_id)

search_model_versions takes the filter syntax the registry uses internally, name='<model name>', and returns one object per matching version. Each object exposes version, current_stage, status, run_id, source and creation_timestamp, so the one-liner above prints exactly what the Models tab shows.

Honest limits

  • The Models tab shows the versions your server reports as the latest ones for each model, the latest_versions field of the response, not the complete history of every version you ever registered. When you need the full list, the script above or the raw GET gives it to you.
  • The plugin asks for at most 500 registered models and 500 model versions per query. Those are the plugin's own limits, not MLflow's.
  • The Model Registry exists in MLflow 2.0 and later. On an older server, the tab tells you the endpoint is missing instead of showing an empty list.
  • The plugin is read-only. It never promotes a version, never tags it, never deletes anything. Promotion stays with the mlflow client or the MLflow UI.
  • Everything in this tutorial is a free feature. No paid tier is involved.

If it is useful to you

If this plugin saved you a context switch, you can support its development with a free and optional donation: https://tggster.gumroad.com/l/piazge. It is a donation, not a purchase, and nothing in the free tier depends on it.

Disclosure: this article was written with the help of AI and reviewed before publication.