opentryon: one interface over a hundred and sixty fashion AI models

The registry is the product, not the models

opentryon is described as an open-source AI toolkit for fashion technology, covering virtual try-on, image and video generation and editing, multimodal understanding, background removal, preprocessing, datasets and TryOnDiffusion research code. The current release, v0.0.8, carries the count that matters, 163 models and 13 services. That number is the actual design goal, because the point of the project is not any particular model but a single surface in front of all of them, so that swapping a vendor does not mean rewriting an application. The catalogue table shows how wide it is. The virtual try-on row includes FLUX VTO, Google Vertex VTO, OutfitAnyone-Plus, Photoroom, Nova Canvas, Kling AI, Segmind, FASHN, Qwen-Image and the locally weighted Leffa and CatVTON. Generation and editing cover the Nano Banana family, FLUX.2, GPT Image, Luma Photon, Seedream, Ideogram, Grok Imagine and Pruna variants. Understanding includes Claude Haiku, several Kimi models, Kimi-VL and LLaVA-NeXT locally, Qwen3.8, NVIDIA Nemotron and Cosmos. Video lists Veo, Sora, Luma Ray, Seedance, Kling, Runway, Wan, LTX and MiniMax among others. A few entries are marked deprecated, notably Sora, which tells you the catalogue tracks vendor changes.

Four ways in, and they share one registry

There are four ways to use the toolkit, and the important point is that they are four doors into the same model registry rather than four separate products. The CLI form is opentryon <service> --model <model> with parameters after it. The MCP server exposes every registry model as tools for Claude, Cursor or TryOn Studio, which is what makes the toolkit usable from an agent rather than only from a script. TryOn Studio is a Next.js interface, with Agent, Connect, Image, VTON, Understand, Video and BG Remove panels, sitting on top of MCP over HTTP. The fourth is Python, where you import from tryon.api, with the CLI runner also reachable through tryon.cli.runner.invoke_model. The service list is what a user actually navigates, and it is more varied than a try-on tool would suggest, with vton for virtual try-on, generate, edit, understand, video-generate, audio-to-video for lip-sync and dubbing, generate-3d for image or text to a mesh, bg-remove, tts, decide for calibrated yes/no, choice and score decisions, classify for try-on safety gating, embed for multimodal embeddings in .npz format, measure for ISO 8559-1 body measurements, and detect for open-vocabulary boxes, points and SVG masks. The classify and decide services are the ones with a business logic purpose rather than a media one, and they are what turn a model catalogue into something an application can gate on.

Installing it, and the split between the light and heavy installs

The install path is a conda environment with an editable install, and there is a lighter pip alternative.

git clone https://github.com/tryonlabs/opentryon.git
cd opentryon
conda env create -f environment.yml
conda activate opentryon
pip install -e .
# Optional local/GPU models: pip install -e ".[local]"

Or with pip, the README gives pip install -r requirements.txt and pip install -e ., and then a separate step for the credentials.

cp env.template .env   # add the API keys you need

The split between the two installs is the design decision worth understanding, and the setup.py explains it directly. There is a heavy, GPU-oriented stack needed only for local or on-device inference, covering BEN2 background removal, LLaVA-NEXT understanding, FLUX.2-dev Turbo and Kimi-VL understanding, and for training via tryondiffusion, and it is kept out of the core install so that pip install opentryon, which is the cloud API adapters plus the CLI, stays light. So the default install talks to hosted models and the local extra pulls in torch, torchvision, opencv, scikit-image, transformers, timm, einops, scipy, huggingface-hub, nest-asyncio, decord for video frame sampling in the Kimi-VL video path, and a local THX-01 model. The requirements file reflects the same split, with the core stack including fastapi, uvicorn, several langchain packages, pydantic, boto3 and the vendor clients for luma, openai and google-genai.

The dry run, and the first real call

The quick start shows a dry run first, and the choice is instructive, since it verifies the CLI and the registry wiring without making an API call.

opentryon vton --model flux-vto \
  --person-image data/model-1.jpg --garment-image data/garment.png --dry-run

The real call differs only by dropping the dry-run flag and adding a garment description.

# Real call (needs BFL_API_KEY in .env)
opentryon vton --model flux-vto \
  --person-image data/model-1.jpg --garment-image data/garment.png \
  --garment-description "olive green bomber jacket"

The understanding service follows the same shape, with a model, an image, a prompt and a reasoning effort setting, and it needs a different key.

# Multimodal understanding (needs MOONSHOT_API_KEY)
opentryon understand --model kimi-k3 --image data/model-1.jpg \
  --prompt "Describe this outfit for a product listing." --reasoning-effort high

The comment about which key each call needs is a useful reminder that the registry spans many vendors and therefore many credentials, and the Python path is the same model behind an adapter class.

from tryon.api import KimiUnderstandAdapter

adapter = KimiUnderstandAdapter(model="kimi-k3")
result = adapter.understand_image(
    "data/model-1.jpg",
    prompt="Describe this outfit.",
    reasoning_effort="high",
)
print(result["text"])

Looking up what a service accepts

The CLI is self-describing, which is what makes a catalogue of 163 models usable rather than overwhelming. The pattern is the same for every service.

opentryon <service> --model <model> [params...]
opentryon understand --help                    # list models
opentryon understand --model kimi-k3 --help    # list that model's flags

So the first help call tells you which models a service has, and the second tells you the flags that specific model accepts, which is the right level of detail because two models in the same service rarely take the same parameters. The service table pairs each service with example models, from flux-vto, p-image-tryon and fashn-tryon-max for virtual try-on through nano-banana-pro and gpt-image-2.5 for generation, veo and flux3-video for video, eleven-v4 for speech, jev and d1-3b for decisions, tryon-safety-classifier for classification, gemini-embedding-2 for embeddings, clad-body-photo and clad-body-questionnaire for measurement, and moondream-3.1 for detection. The models marked local need the local extra, and the full table with flags is in the unified CLI documentation. The scale is the point and also the risk, since a catalogue this wide means the useful question for any given project is which two or three models it actually needs.

Where opentryon is the wrong choice

The first limit is the licence, and it is the one to check before anything else. The project is released under CC BY-NC 4.0, and the setup.py repeats it as the package licence, so the toolkit that is described as open source for fashion technology is not open source in the sense a commercial product can rely on, since the non-commercial term forbids commercial use of the code itself. For a company building a paid try-on product, that is a licensing question with a commercial answer, and the site is where to get it. The second is that the toolkit is mostly an abstraction over other people's models, so the value depends entirely on the upstream vendors, several of which are marked deprecated in the table, and a catalogue that is refreshed from vendor announcements is a catalogue that changes under you. The third is the credential sprawl, since a project that touches models from a dozen providers needs a dozen keys in a .env file, and every call is billed to one of them, so the abstraction moves the cost around rather than removing it. The fourth is the release cadence, with three releases in the week before this writing, v0.0.6, v0.0.7 and v0.0.8, each adding a group of services and models, which means the API surface is moving fast and the version number is still 0.0.x. The fifth is the size of the catalogue itself, where 163 models across 13 services is a lot of surface to reason about, and a team that needs one virtual try-on model would be better served by that model's own client and SDK, and the only case where the registry clearly wins is a team that genuinely intends to compare and swap.

Editorial conclusion

Adopt opentryon if you are building a fashion product and want one integration surface across many hosted models rather than a separate client per vendor, or if you want to run some of them locally. Skip it if you only need one model, since the abstraction then costs more than it saves, and read the licence first, since CC BY-NC 4.0 is not a commercial licence. Verify first that the model you need is in the registry with the service and flags you expect, that your API keys are set in the .env file, and that the models marked local will fit your hardware before you install the extra.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tryonlabs/opentryon on GitHub