Publishing Models

A model on ChipAI.dev has three parts:

• Metadata — name, task, license, tags (stored in the catalog, shown on cards and the detail page)
• Code & docs — README, model card, config (in an auto-provisioned git repo)
• Weights & large files — checkpoints, tokenizers (in object storage)

Before you start

• You need to be signed in with at least the contributor role. If you see "You need a contributor role to publish models," request the role from your profile.
• Pick a slug ahead of time — it's permanent, used in the URL (/models/<slug>) and the git repo name.

1. Create the listing

Open Create → Model from the profile menu (top-right), then fill in:

A clear summary and at least one tag make your model far easier to discover.

2. Pending review

New models are created with pending status and reviewed by a moderator before appearing in public listings. You can still see and work on it from your profile while it's pending.

3. Push code & docs (git)

Creating a model auto-provisions a git repository. Open the clone panel on the model page to copy its URL:

git clone <clone-url>
cd <repo>

# add a model card + config
$EDITOR README.md
git add .
git commit -m "Add model card"
git push

Text and code (README, config.json, tokenizer configs) live here. You can also edit files directly in the in-browser code editor on the model page.

4. Upload weights & large files

Large binaries don't go in git — they stream to object storage:

• In the browser: use the file browser on the model page (upload / download / delete). Files over ~100 MiB automatically switch to a presigned direct upload.
• Object keys follow models/<slug>/<path>.

Programmatic upload

# stream a file straight into storage (owner only)
curl -X PUT \
  -H "Authorization: Bearer <token>" \
  --data-binary @model.safetensors \
  "$API/api/v1/models/<slug>/files/model.safetensors"

For very large files, request a presigned URL first (POST /api/v1/models/<slug>/upload-url) and PUT the bytes directly to it.

5. Write a good model card

Put these in your README.md so users can evaluate the model quickly:

• Intended use and out-of-scope uses
• Training data and preprocessing
• Evaluation / benchmarks with numbers
• Limitations & biases
• License and citation

Versioning

Use the git repo's history and tags for code/config versions, and upload new checkpoints under clear paths (e.g. checkpoints/v2/). The model page always serves the current files from storage.

Editing & deleting

Owners (and moderators) can edit the listing metadata and manage files from the model page. Deleting the model removes its listing; clean up the git repo and stored files separately if needed.

Other ways in

• Import an existing GitHub repo instead of starting from scratch — see Import from GitHub.
• Consuming a model (browse, download, clone)? See Using & Downloading Models and Browsing & Discovery.

Next: Using & Downloading Models · Agents & Tools · Quickstart.