---
title: Add a model
sidebar_label: 4. Add a model
description: "Register a Hugging Face model with the platform, and understand why registration moves no weights and why the task matters."
---

A benchmark measures a model. This part registers one. It takes about ten seconds, and the reason it is that fast is worth understanding.

## Register the model

Open **Models** and select **Add Model**.

![The Models list with the Add Model action](/img/platform/first-benchmark/03-models-list.png)

Paste a Hugging Face model URL or its `owner/repo` identifier. An access token is only needed for a gated or private repository; public ones need nothing.

![The Add HuggingFace model dialog, with a model URL field and an optional access token](/img/platform/first-benchmark/03-add-model.png)

For a first run, pick something small so the whole loop finishes in minutes rather than hours. `Qwen/Qwen2.5-0.5B-Instruct` is a reasonable first model on a workstation-class device.

## What registration did, and what it did not

The platform read the repository's metadata and stored a reference: the canonical URL, the task, and the architecture and framework where the metadata names them. **No weights moved.** You can register a 70B model from a laptop, because nothing is downloaded until a run needs it, and then it is downloaded by the device that will run it.

A Hugging Face repository has one record on the platform. When someone, in your organization or another, registered the same model before you, **Add Model** returns that record and lists it under your models as a platform catalog model, dated from the day it was added to your organization. Your benchmarks, results and deployments on it are yours and stay in your project; the record's own fields (name, task, architecture) are shared, so an edit to them is refused as shared.

The **task** is the field that does real work. It is the model's Hugging Face `pipeline_tag`, for example `text-generation`, `automatic-speech-recognition` or `image-text-to-text`, and it decides which quality tests can run against the model in the next part. If the metadata does not carry a task, the model still registers and you can set the task by hand; the picker then offers the right tests.

The list groups models into categories derived from that task: LLM, Vision, Audio, Image, Multimodal, Embedding. It is the same grouping the benchmark picker uses.

## The Hugging Face access token

The dialog has an access-token field, and it is worth understanding what it is for before you need it.

**What it is.** A personal access token from your Hugging Face account. It proves to the Hub that you are allowed to read a repository that is not public.

**Why the platform needs one.** Public repositories need nothing at all, and most first benchmarks use one. A token becomes necessary when the model or the dataset behind a benchmark is **gated** (you accepted terms to get access, as with several Llama and GPQA releases) or **private** (it belongs to you or your organization). Three moments need it: reading the repository's metadata when you register the model, fetching the checkpoint on the device when a benchmark runs, and fetching it again when you [deploy the model](../../concepts/model-deployment.mdx) as an endpoint.

**Where to get one.** In Hugging Face, under your account settings, at [huggingface.co/settings/tokens](https://huggingface.co/settings/tokens). A token with read permission is enough. A fine-grained token also works, as long as it grants access to the specific repositories you plan to benchmark.

**Where it goes.** The token you type into the Add-model dialog is saved as your organization's Hugging Face credential, and the dialog says so: one token then serves the metadata read now, the checkpoint fetch when a benchmark runs, and the fetch when you deploy the model. You can see and replace it under **Settings**, then **Credentials**, as a HuggingFace credential. There a credential is either **Personal** (only your own runs use it) or **Organization** (anyone in the organization can), and the platform stores it encrypted. When both exist, your personal credential wins over the organization's.

**What happens without one.** A public model behaves exactly as it did above. A gated model registers but the run fails on the device when the fetch is refused, and registering one from the dialog without a token reports that the metadata could not be fetched and to check the URL and, for gated or private models, the token.

## Pick one from the Modelverse

The **Models** page has two views, switched at the left of its toolbar: **My Models**, the project's registered models, and **Modelverse**, the catalog of models CLIKA has confirmed to run well on ClikaRT. A link to the page with `?view=modelverse` opens the catalog directly, and the page remembers the view you left.

Each catalog row is one model: the provider's mark and the `owner/repo` on the first line, and on the second its type, its parameter count, and **From**, the memory its smallest packaging needs to run. Clicking a row registers the model into My Models exactly as **Add Model** does, with the repository's public metadata; a row already registered in this project reads **Added**. Adding needs the same models write permission as Add Model, and a platform whose models come from its model store offers the catalog to browse but not to add from.

The filter panel on the right narrows the rows.

- **Type** lists the categories the catalog carries, each with the count it would leave under the other filters.
- **Parameters** is a range with two handles over five stops (`<1B`, `3B`, `8B`, `14B`, `>30B`). The lower handle is the smallest size kept, the upper handle the largest, so `3B` to `14B` keeps models of 3 to 14 billion parameters; the two handles never share a stop.
- **Fits my devices** lists your organization's devices with the memory the fit rule reads for each, the GPU's memory where the engine would use the card and the device's total memory otherwise. Selecting devices keeps only the models whose smallest packaging fits every one of them. A device whose memory the platform does not know rules nothing out, and the section is absent for a member who may not list devices.

The name field in the toolbar searches by `owner/repo`; **Clear All** resets the filters and keeps the search. The catalog is curated by a platform administrator in the admin dashboard, on its **Modelverse** page: the entries, their providers and the provider logos the rows show. An empty catalog means nothing has been curated on this platform yet.

[Modelverse](/modelverse) documents the model library itself.

## The other way in

You do not have to register a model first. The benchmark flow accepts a Hugging Face URL directly, and registers it as a model on the way through. Registering up front is worth it when several people run against the same model, because everyone then picks it from a list instead of pasting a URL and hoping they pasted the same one.

## What you have now

A model reference, a device, and a project holding both. The next part runs one against the other.

- Full detail: [Artifact](../../concepts/artifact.mdx).
- Next: [Run a benchmark](05-run-a-benchmark.md).
