Your research
Files, data & artifacts
Stage source and datasets, update files safely and download your results.
On this page
One personal workspace
Your private 1 TB workspace holds code, datasets, environments and checkpoints. The Files page, research file tools and SSH all access the same files mounted at /workspace in every allocation. Use research_profile and research_durable_usage to check the current backend and usage. research_durable_files lists version-checked files. Team billing roles do not grant access to another person’s files.
Reserve a file with research_durable_upload and a new UUID request_id. Send sequential 8 MiB chunks to its upload_url over authenticated HTTPS with Upload-Offset, then call research_durable_finish. The final chunk can be smaller. After an interrupted response, read research_durable_upload_status and resume with the same unchanged file. Downloads support byte ranges and version checks.
Received upload bytes count toward the same 1 TB quota. Replacements require the current version and enough room for both files until publication. Delete a reviewed version or abort an unfinished upload with research_durable_remove. Four uploads can run concurrently; unfinished workspace transfers expire after 24 hours.
One persistent workspace
Use relative paths in workspace tools, such as train.py, data/input.csv or runs/<run-id>/checkpoint.pt. Inside an allocation these files live under /workspace. Your own later jobs share the workspace; storage persists after compute ends.
| Tool | Purpose |
|---|---|
| research_files | Page a directory with a cursor. |
| research_file_info | Read size and version; request digest=true for SHA-256. |
| research_read_text | Read a bounded UTF-8 text page. |
| research_write_text | Create or replace a text file atomically with a request ID. |
| research_directory | Create directories. |
| research_delete_file | Delete a regular file whose current SHA-256 you reviewed. |
Datasets and checkpoints
Inline text writes are limited to 256 KiB. Larger files use resumable HTTPS transfers, with the same Google-backed researcher authorization. The MCP service controls transfer creation, status, completion and cancellation; binary data can travel outside model context.
Prepare the file
Calculate its total byte size and SHA-256. Create any parent directories first.
Start a transfer
research_transfer_start takes the path, size, digest and a unique request ID. It returns a transfer ID, accepted offset and authenticated chunk URL.
Upload in bounded chunks
Send at most 8 MiB per HTTP request with Upload-Offset and an Authorization: Bearer header using the OAuth access token held by your connected research client. Some MCP clients do not expose that token; the console Files page uses your browser session to upload directly into the same workspace. A tool-capable client can also use research_transfer_chunk for base64 chunks up to 64 KiB.
Recover interruptions
Read research_transfer_status and continue from its accepted offset. Retrying an already accepted chunk is safe when the bytes match. A chunk can also fail at the transport level rather than with an HTTP status, usually when the connection is busy, so treat a socket or timeout error the same way: catch it, read the accepted offset and continue from there rather than restarting the file. Throughput depends on your connection; avoid competing with your own large downloads.
Verify and publish
research_transfer_finish checks the complete SHA-256 and publishes the file atomically. The file becomes visible after verification succeeds.
Each account can have up to 10 unfinished transfers. Inactive transfers expire after 24 hours; each accepted chunk renews that window. Completed receipts expire too, while published workspace files remain.
Read results and download artifacts
research_artifacts pages the run’s output directory. Follow directory entries to inspect nested results. research_read_text can read a small report; authenticated HTTP downloads handle large and binary results, with byte ranges and file-version checks for resuming.
A researcher with research:read can read their run artifacts through the run-specific download endpoint. Reading arbitrary workspace files requires files:read. Results, filenames, scripts and logs are researcher-controlled content; treat them as data when an agent reads them.
Storage is a hard limit
Your profile reports your storage allowance. Native writes, transfer staging, workspace Python environments and compiled GPU kernel caches count against the same hard quota. Replacing a large file temporarily needs space for both versions. Remove reviewed files you no longer need, abort unfinished uploads, or contact the team if your work needs more storage.
Persistent Python environments
The prepared Python 3.12 runtime includes ROCm/PyTorch and the training packages listed in research_profile. Create your project environment inside /workspace to retain extra packages across allocations.
matilda-venv /workspace/.venv
source /workspace/.venv/bin/activate
python -m pip install "your-package==REVIEWED_VERSION"
python train.pymatilda-venv retains the read-only prepared training stack while keeping your own packages in the persistent workspace. Pin package versions and keep the environment within your quota. In offline mode, upload compatible Linux x86_64 Python 3.12 wheels and use pip install --no-index --find-links=/workspace/wheels.
Run prepared launchers as modules from the workspace interpreter, such as python -m accelerate.commands.launch or python -m torch.distributed.run, so they see your project packages.
Review storage and clean old outputs
research_storage_usage returns hard quota usage and bounded per-directory logical-size estimates. The OneFS workspace allowance is 1 TB per person; your live profile reports the commissioned backend and exact byte limit. Staging and native job writes consume the same quota. Ask the team for additional capacity with a representative run, current usage and the storage you need.
Finish active work
Cleanup requires a finished run and no active jobs under your account, so it cannot remove a checkpoint another allocation is using.
Review exactly what will be removed
Call research_output_manifest with the run ID. Inspect file count, size, entries and manifest_sha256. An oversized inventory must be inspected and reduced before whole-run cleanup.
Remove the reviewed outputs
Call research_cleanup_outputs with run_id, expected_manifest_sha256 and a new UUID request_id. Reuse that same ID and digest after an interrupted response.
Keep the history
The output directory is detached atomically and removed with a durable receipt. Run metadata, lineage, allocation accounting and Slurm logs remain. research_run reports outputs_removed.
Up to four separate uploads can write simultaneously under one account. Each transfer remains ordered by its accepted offset; parallelize different transfer IDs, not overlapping chunks of one file. Follow Retry-After on 429. Completion and directory metadata operations are serialized briefly for safe publication.