> ## Documentation Index
> Fetch the complete documentation index at: https://client-integrations-api-dev.sequen.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Model support

> What your model code must provide to run on hosted RRI, and the boundaries of the training environment.

RRI is framework-agnostic at the contract level. Your repository is shipped to a GPU machine for each run as a git working tree, an agent edits a configuration file and runs one documented command, and your training code reports metrics to a local endpoint. Anything that fits that contract can run.

## Supported environment

| | |
| - | - |
| **Framework** | PyTorch |
| **GPU image** | Python 3.14, PyTorch 2.14, CUDA 13.2 |
| **Platform** | Linux on x86\_64 |

These are the versions the current image ships, and they change over time. Other frameworks and libraries are possible when they install from prebuilt wheels for that Python. See [Extra packages](#extra-packages).

## What your model code must provide

Four things, plus a README:

1. **A git repository** with a clean tree that can train as it is.
2. **One entry point**, a command you can run from the workspace root, such as `run_train.sh [run_name]`. The first argument is the run name.
3. **One configuration surface.** Every setting worth varying lives in a versioned file: learning rate, epochs, batch size, schedule, architecture sizes, loss weights, dataset paths and the seed. Agents try ideas by editing that file and committing it, so a knob passed as an environment variable or a command-line flag is invisible to them. Validate the file with a typed schema, so a typo fails at the start of a run and not as a quietly worse model.
4. **Metric reporting** to the endpoint described in [Report metrics](#report-metrics).

The **README** is what the agents read first, so it is part of the integration. It should state the entry point and what it does, where the configuration lives and which settings are meant to change, where the datasets are and how to read them, how metrics are defined and what the objective is, and any prerequisites such as GPU or precision assumptions.

Environment variables are fine for things outside the experiment: workspace paths, credentials and `CUDA_VISIBLE_DEVICES`.

### Where output goes

Everything a run produces goes in `$SEQUEN_OUTPUT_DIR`, which is `/local/output/<experiment_id>/`. Finalizing an experiment publishes that directory to durable storage, and anything written elsewhere is lost when the machine is released. Sequen sets and creates the directory, so your code only reads the variable.

### Size limits

The model code is limited to 500 MiB in total, 20,000 files, and 100 MiB per file. See [Connecting repositories](https://client-integrations-api-dev.sequen.ai/rri/connecting-repositories.md#size-limits).

## The training environment

* **No internet access.** The GPU machine cannot reach the public internet, so code that downloads at run time fails. Datasets are placed on the machine before your entry point runs.
* **A fixed Python environment.** The environment is read-only at run time, so `pip install` into it fails.
* **No downloads from model hubs.** Load pretrained weights from the approved store described below.

### Extra packages

Packages the image does not provide come from an approved package store: a set of prebuilt wheels for the image's Python, checked against the image's own package versions. An agent installs from it during a session. A package the image already provides cannot be replaced or downgraded.

To add a package to the store, ask your Sequen contact. A package that conflicts with the image or has no prebuilt wheel for its Python cannot be added. A dependency your class needs every time belongs in the image.

### Pretrained checkpoints

A model that starts from a public pretrained checkpoint gets it from an approved store of vetted Hugging Face repositories. The agent lists the store and fetches a checkpoint by its repository id, and your `from_pretrained("<repo id>")` call works unchanged, offline. Fetch the checkpoint in every session. Do not pass `cache_dir` and do not set the Hugging Face cache variables in your launcher, or the load looks in the wrong place.

To add a checkpoint, ask your Sequen contact. A repository whose configuration names custom code, or that ships only pickled weights, is refused unless Sequen decides to allow it.

## Report metrics

Your training code sends metric snapshots to a local HTTP endpoint on the GPU machine. There is no experiment-tracker account, key or SDK. Reporting is fire-and-forget: a missing or unhealthy endpoint must never block or crash training.

```
POST http://127.0.0.1:9090/results
Content-Type: application/json

{"experiment_name": "<run name>", "step": 1234,
 "metrics": {"train/loss": 0.23, "eval/auc": 0.87}}
```

Read the URL from `SEQUEN_RESULTS_URL`. Set it to an empty string to turn reporting off, which is what you want for a local run with no Sequen.

| Rule | |
| - | - |
| `experiment_name` | Required. Use the run name your entry point was given. A post without it is rejected with a 400. |
| `step` | A whole number, the training step. Optional and read as `0` when left out, so send it on every post. |
| `metrics` | A flat map of name to number, with at least one entry. |
| Numbers only | Drop NaN and infinity before sending, since neither is valid JSON. |
| No extra fields | Any top-level field other than these three is rejected with a 400. |
| Unknown experiment | A name that matches no existing experiment is still answered with `202`, and Sequen then drops the post. A typo in the run name shows up as empty curves, not as an error. |
| Responses | `202` when accepted, `400` for a bad payload: no `experiment_name`, no metrics, a non-numeric value, a `step` that is not a whole number, or an extra field. `202` means the post was received, not that it was recorded. |

### Name metrics by split

| Prefix | Use for |
| - | - |
| `train/` | The training data |
| `eval/` | A later-period holdout, such as `eval/auc` |
| `test/` | A sample of the training range, where your model has one |
| `perf/` | Timing, throughput and resource use. This is not a split. |

The interface and the agents key off these prefixes. The final `eval/` value is the comparison point for the objective.

**Report your objective as a single key.** The results table shows one primary metric per session and derives its value from the series you report, so whatever the objective optimizes must be one key. If the objective is a composite, such as the mean of two grouped AUCs, compute it in your trainer and report it as one metric. A speed objective needs its own metric under `perf/`, such as `perf/train_seconds`.

The primary metric a session chooses must be one of the Model Class's **optimization targets**, which an administrator sets. If you change the key your trainer reports, change the Model Class's targets with it.

### Training duration

Duration is derived from the span of your reported timestamps. By default it starts at your first metric post, which leaves out startup, data loading and model build. To include that work, send a start marker as the first post:

```
{"experiment_name": "<run name>", "step": 0,
 "metrics": {"__train_start__": <unix start time>}}
```

Metrics whose names begin with `__` are reserved. They are hidden from curves and pickers, and the marker still counts toward the duration. Send the marker at the step training starts from, with the wall-clock start time as its value: step `0` for a fresh run, and the checkpoint's step for a run that resumes. Sequen reads a second marker at or below the existing series as a restart and clears the earlier points.

## Exporting a model

RRI does not convert or package a trained model. The model code you maintain decides what it writes, and the output directory is where it goes. See [Export formats](https://client-integrations-api-dev.sequen.ai/rri/artifacts-and-serving.md#export-formats).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.