# How C3 works C3 runs your code on a GPU in a data centre. You point it at a project folder, say what hardware you want, and it provisions the machine, sets up the environment, runs your script, saves the output and shuts the machine down. You pay for the seconds it ran. ## What you deploy[​](#what-you-deploy "Direct link to What you deploy") One of three things, chosen in `.c3`: * **A Python project.** C3 installs your `pyproject.toml` dependencies with `uv` and runs your script in that environment. The environment is cached, so the second job starts faster than the first. * **A container.** C3 pulls a public Docker Hub or GitHub Container Registry image and runs your script inside it. Use this for system packages, other languages or a specific CUDA stack. * **A plain Bash script.** C3 runs it on the machine as is. Whatever it needs, it installs itself. Whichever you choose, the whole project folder goes with it, and the script runs from that folder on the machine. See [Environments](https://docs.cthree.cloud/environments.md). ## Deploy, then walk away[​](#deploy-then-walk-away "Direct link to Deploy, then walk away") `c3 deploy` uploads the folder and returns a job ID within seconds. From then on the job is C3's problem, not your laptop's. Close the lid, lose the wifi, go home. The job queues for a machine, runs to completion, and its output is saved in C3's storage. Come back whenever you like: ``` c3 squeue # what is queued, running and finished c3 logs job_abc123 # what it printed c3 pull job_abc123 # download its results ``` The same jobs show in the [dashboard](https://cthree.cloud/dashboard) and to any coding agent connected through the [MCP server](https://docs.cthree.cloud/mcp.md). If you would rather watch, `c3 deploy -f` streams the logs live, and closing the terminal does not stop the job. If you have used Slurm: `c3 deploy` is `sbatch`, `c3 squeue` is `squeue`, `c3 cancel` is `scancel`, and `.c3` replaces the `#SBATCH` header. The difference is that there is no shared filesystem and no login node. Everything the job needs goes in with it, and everything it produces comes out as artifacts. ## Files in, files out[​](#files-in-files-out "Direct link to Files in, files out") | | Workspace | Dataset | Artifacts | | ----------------- | ------------------------------------------------------ | --------------------------------------------------------- | ------------------------------------------------------------------- | | What | Your code: `.c3`, the script, source, `pyproject.toml` | Inputs: measurements, images, model weights | Outputs: results, plots, checkpoints | | How it gets there | Uploaded automatically by every `c3 deploy` | Uploaded once with `c3 data cp`, mounted with `datasets:` | Written by the job to `$C3_ARTIFACTS_DIR` or an `output:` directory | | On the machine | The working directory | The `mount` path, such as `/data/my-data` | Collected after the script exits | Three rules cover most mistakes: * **The workspace is everything under `.c3`.** It is hashed on every deploy and staged onto every machine. That is fine for code and wrong for data. Anything over a few hundred megabytes, shared between projects, or not written by you belongs in a [dataset](https://docs.cthree.cloud/datasets.md): upload it once, mount it from any job. * **Only artifacts survive.** Files written anywhere else on the machine are gone when the job ends. Write results to `$C3_ARTIFACTS_DIR` or a directory listed under `output:`. See [Artifacts](https://docs.cthree.cloud/artifacts.md). * **Results can feed the next job.** Mount `/jobs/` as a dataset and the next job reads the previous one's output without it ever coming back to your laptop. ## Hardware[​](#hardware "Direct link to Hardware") Ask for a class and C3 picks the cheapest available machine in it: `l40` (48 GB, the default), `a100` (80 GB) or `h100` (80 GB). Or name an exact profile from `c3 list --all`, including CPU-only machines with up to 96 cores and 384 GB of RAM. C3 buys from several providers and routes each job to whichever has the machine. See [Hardware and capacity](https://docs.cthree.cloud/hardware.md). ## Job lifecycle[​](#job-lifecycle "Direct link to Job lifecycle") | State | Meaning | | ------------ | ---------------------------------------------- | | `PENDING` | Accepted, waiting for a machine | | `SCHEDULING` | Machine assigned, environment being prepared | | `RUNNING` | Your script is executing. Billing starts here | | `SUCCEEDED` | Script exited 0 and results were collected | | `FAILED` | Script exited non-zero, or C3 could not run it | | `CANCELED` | Stopped by `c3 cancel` | | `TIMED_OUT` | Hit the `time` limit | `c3 squeue` shows `SUCCEEDED` as `COMPLETED`, and as `SYNCED` once you have run `c3 pull`. ## What it costs[​](#what-it-costs "Direct link to What it costs") Per second while `RUNNING`, at the hourly rate of the machine the job landed on. Queueing, provisioning and result upload are free. Credit is reserved when you submit and refunded if the job never ran. New accounts start with £10. Your plan sets how many machines you can run at once. See [Pricing and plans](https://docs.cthree.cloud/pricing.md). ## Glossary[​](#glossary "Direct link to Glossary") | Term | Meaning | | --------- | --------------------------------------------------------------------- | | Class | A family of GPUs you can request: `l40`, `a100`, `h100` | | Profile | An exact machine type, such as `h100-80gb` or `cpu-d3-96vcpu-384gb` | | Provider | The data centre operator that supplied a machine | | Workspace | The files under `.c3` that `c3 deploy` uploads | | Dataset | Data uploaded once with `c3 data cp`, versioned, mountable in any job | | Artifacts | Files a job wrote to `$C3_ARTIFACTS_DIR` or an `output:` directory | | Chip | One running machine, GPU or CPU. Plans limit chips in use at once | | Walltime | The `time` limit in `.c3`. Default one hour |