Why does one connection add over a hundred models?

Because the provider exposes that many. Discovery reports the catalogue, not a filtered selection.

Can I remove models I will never use?

You can, but consider leaving them. An inventory of what is reachable is more defensible than one that only lists what is used, and the idle rows cost nothing to keep.

Why do models have incidents?

Because controls evaluate content, and content flows through models. A model that returns something a policy forbids produces an incident against that asset.

Do models have the same detail tabs as agents?

No — a model has five: Overview, Observability, Evaluation, Incidents and Policies. There is no Monitoring, Outcomes or Setup tab, and observability is span-based rather than trace-based. See Model Record Reference [/docs/ai-governance/model-registry-record-reference].

Introduction

The Model Registry is the inventory of every model your organisation has under governance — which models are reachable, who owns them, what they cost and what policies apply.

It is the same table as the Agent Registry with a few substitutions, and reading it that way is the fastest way to learn it.

Where to find it

AI Governance > Model Registry

Access to AI Governance is granted through platform roles. Ask your workspace administrator, or see Settings > Governance > Roles for how permissions are assigned.

How it differs from the Agent Registry

Everything else — filtering, sorting, ownership, incidents and policies — behaves the same way. There is no Type column.

	Agent Registry	Model Registry
Name column	`AGENT NAME`	`MODEL NAME`
Activity unit	`LAST TRACE` · `N traces`	`LAST SPAN` · `N spans`
Pending status label	`Setup Pending`	`Inactive`

The unit change is the substantive one. An agent's unit of work is a complete run, which is a trace. A model does not run agents — it serves calls, and a call is a span. See Sessions, Traces & Spans.

Because of that, a model's span count and an agent's trace count are not comparable numbers. A single busy agent generates many more spans than traces.

How models get into the registry

Discovery — A model-provider connection returns the models that provider exposes — commonly well over a hundred from a single connection. This is why the Model Registry fills up faster than anyone expects.
Manual addition — + Add Model, for a model served from a platform you have not connected. See Add a Model.

Reading the table

Column	What it tells you
`MODEL NAME`	The model identifier as the platform reports it.
`PLATFORM`	Where the model is served from.
`STATUS`	`Active` or `Inactive`. Models use `Inactive` where agents use `Setup Pending`.
`LAST SPAN`	When the model was last called. A dash means no span has been received.
`ACTIVITY`	Volume, as `N spans`.
`COST`	What the model has spent.
`INCIDENTS`	Governance incidents raised on this model.
`POLICIES`	How many policies apply to it.
`WORKSPACE`	The workspace the model belongs to.
`OWNER`	Who is accountable for it.
`LAST UPDATED`	When the record last changed. The table is sorted by it, newest first.

Filter, Sort and Search work as they do everywhere else.

Inventory, not usage

A model-provider connection returns the provider's whole catalogue, not the models you actually call. So the common state of this table is: many rows, most with 0 spans, a dash under LAST SPAN, and no cost.

That is correct, and it is useful. The catalogue tells you what is reachable — which is a governance question in its own right, because a model nobody has approved is still a model someone can call tomorrow.

The rows with spans are the ones in production. Sort by ACTIVITY to separate the two, and govern the second group first.

"The catalogue tells you what your developers could reach. The span count tells you what they actually reached for."

Models and agents are both assets

Policies do not apply to "agents" or to "models" — they apply to assets, and APPLIES TO on a policy reads as a count of assets. Incidents name an ASSET TYPE to tell you which kind you are looking at.

Worth internalising, because it means a single policy can cover both registries.

Best Practices

Govern by usage first — Sort by ACTIVITY and start with models that are actually being called. A hundred idle catalogue entries can wait.
Treat the catalogue as an approval surface — The full list is what your developers could reach. Reviewing it is a cheap way to catch a model class you never intended to allow.
Know who owns the models in production — The owner is set when the model arrives (the importer, or the connection owner for discovered models) and cannot be changed afterwards. Ownership matters where incidents can occur.
Watch for the same model on two platforms — The same underlying model served through two providers is two rows with two cost lines and two policy sets. That is accurate, and it surprises people at month end.

Model Registry Overview