omm

omm contribute

Repeatedly install, benchmark, and upload telemetry for hardware-fit models — deleting each one afterward — to grow the training data behind omm recommend.

01 / 06

Overview

contribute is the one command in omm that is meant to run unattended for a while: it downloads a candidate, benchmarks it, uploads the result under your current upload policy, deletes the model to keep disk usage bounded, and repeats until you press Esc or it runs out of candidates this hardware hasn't already covered. It refuses to start unless every model volume has real free space, and prints the exact consent notice below before it downloads anything.

02 / 06

Options

Every flag this command accepts, and what it defaults to when you leave it out.

  • --report-errorsDefault: off

    Send scrubbed error reports from this run only. Doesn't change the saved policy, and is ignored if error reports are explicitly turned off.

  • --yesDefault: off

    Skip the 'Start contributing compute now?' confirmation and every per-model prompt — required for an unattended run.

03 / 06

Examples

From a plain search to something you'd put in a script.

Interactive — prints the consent notice, then asks before starting.

$ omm contribute

Unattended — no confirmation prompt, runs until Esc or the candidates run out.

$ omm contribute --yes

Also send scrubbed error reports from this run.

$ omm contribute --report-errors

Store models under a roomier volume than the default ~/.omm, straight from the README.

$ OMM_HOME=/mnt/data/omm omm contribute --yes

04 / 06

A real run

Real omm contribute --yes run, 2026-08-25, against a throwaway OMM_HOME with upload policy set to 'ask' (not 'always', since contribute refuses to start at all under 'never') — it actually downloaded a real candidate (maziyarpanahi/Qwen3-0.6B-GGUF), benchmarked it through a real running Ollama, deleted it, and moved on to a second one, exactly as the loop is meant to. Interrupted here deliberately, after discovering something worth disclosing rather than hiding: contribute's own upload call passes force=True, so it uploaded this one real (anonymized) benchmark result even under the 'ask' policy the notice above describes — README and the UI both read as though 'ask' defers per-item, but the code doesn't gate contribute's own upload that way. The evidence itself is the same CPU/GPU-chip-score-only telemetry design/FACTS.md's setting section already documents, nothing more.

06 / 06

If something goes wrong

Every message below is one this command actually prints. Find yours, read why it happened, then do the last line.

  1. omm contribute requires benchmark uploads to be enabled. Run `omm setting upload --enable` or `--ask` first.
    why
    contribute always uploads its benchmark results — that's the point of the command — so it refuses to start while uploads are turned off entirely.
    what to do
    Run omm setting upload --enable or --ask, then retry.
    source
    src/omm/cli.py:9273-9276
  2. Neither Ollama nor LM Studio is installed or available. Install one of them, start it once, then retry `omm contribute`.
    why
    Benchmarking needs a running engine to load the model into, and contribute only knows how to drive Ollama or LM Studio for this.
    what to do
    Install and start Ollama or LM Studio at least once, then retry.
    source
    src/omm/cli.py:8456-8459
  3. omm contribute will not start with low disk space. Keep at least 10 GiB free on every model volume before an unattended run. /Users/you/.omm/models: 3.2 GiB free.
    why
    Every candidate needs headroom for the central download plus a worst-case engine copy — contribute checks this before starting an unattended run, not partway through one.
    what to do
    Free up space on the reported volume (the message names exactly how much), or point OMM_HOME at a roomier drive.
    source
    src/omm/cli.py:7871-7879

Still stuck? Open an issue with the exact message you saw.

All commands