Tasks

A task runs a Python script once, to completion, on a node matched to the hardware you pick. You submit the code, an image, and the hardware — Meshive schedules it, streams the logs live, uploads whatever the script writes to /outputs, and charges your prepaid credit only for the time the container actually ran.

Script (main.py + optional requirements.txt)
        │  Submit — image + hardware + max run time
        ▼
Runs on a matched node ──▶ logs stream live in the console
        │  script exits (or hits max run time)
        ▼
Files in /outputs uploaded ──▶ download from the console

Everything lives under Serverless › Tasks in your workspace console.

Tasks vs Serving

Serving keeps a model resident behind an always-on endpoint. Tasks run a script and stop.

	Serving	Tasks
What runs	A model behind an OpenAI-compatible endpoint	Your Python script, once
Lifetime	Until you pause or delete it	Until the script exits (or max run time)
You get back	API responses	Live logs + files from /outputs
Billing	GPU-hour × running replicas	Runtime of the container, from prepaid credit

Typical task workloads: batch inference over a dataset, fine-tuning a model, data preprocessing — anything with a start and an end.

Quickstart

1. Open Serverless › Tasks in your workspace console and click New task.

2. Name the task.

3. Add your script — write it in the code editor, or upload main.py plus an optional requirements.txt (see below).

4. Pick an image — an official template, or your own image from a custom registry (see Container images).

5. Pick hardware — a GPU model and count, or a CPU-only preset:

   Preset	vCPU	RAM
   Standard	8	32 GB
   High-mem	16	128 GB

6. Environment variables & secrets (optional) — available to your script as regular env vars.

7. Max run time — 1 to 24 hours. The task is stopped when it hits this ceiling (see Task billing & refunds).

8. Webhook (optional) — get a signed POST when the task finishes (see Webhooks).

9. Submit. The task card shows the live status, streaming logs, and Cost so far.

You can Stop a running task at any time — you’re charged for the time it actually ran, and no webhook event is sent for a manual stop.

requirements.txt

If you attach a requirements.txt, pip install -r requirements.txt runs inside the container, before your script starts.

Install time is billed

Dependency installation happens on your hardware, on your clock. If the install itself fails (typo’d package, version conflict, package that needs system libraries the image doesn’t have), the task fails as a user fault and is charged in full. For heavy or fragile dependency sets, bake them into a custom image instead and keep requirements.txt small — and pin versions.

Container images

Source	Requirements
Official template	None — guaranteed to work with tasks out of the box
Custom registry image	Must have python (with pip, if you use requirements.txt) on the PATH

A custom image without a working python fails at startup — that’s a user fault and is charged like any other user-code failure. Test the image locally first: docker run --rm <image> python --version.

Private registries use the registry credentials already connected to your workspace — the same ones used for custom pod templates.

Writing your script: outputs

Your script starts with /outputs as its working directory. Anything it writes there is uploaded automatically after the container exits and becomes downloadable from the task’s page in the console.

• Relative writes (open("result.csv", "w")) already land in /outputs — no path handling needed.
• _task.log is added automatically: a tail of the run’s log, archived alongside your files.
• Files are kept per the platform’s retention policy — download anything you want to keep long-term.

Output limit	Value
Max size per file	5 GiB
Max number of files	200
Output disk budget	20 GiB

Caution

Exceeding the 20 GiB output disk budget mid-run evicts the task — it ends as a user fault and is charged in full. Stream large intermediates elsewhere or clean up as you go.

Webhooks

Add a webhook to be notified when a task reaches a terminal state:

Event	When
task.succeeded	Script exited with code 0
task.failed	Script failed — non-zero exit, OOM, eviction, install failure, or a platform fault
task.timed_out	Max run time reached

Terminal states only. A manual Stop sends no event.

The payload envelope matches inference webhooks:

{
  "id": "evt_3f9c1a2b4d5e6f70",
  "type": "task.succeeded",
  "created_at": 1780000000,
  "data": {
    "id": "task_abc123",
    "name": "nightly-batch-embed",
    "status": "succeeded",
    "fault_class": "none",
    "exit_code": 0,
    "failure_reason": null,
    "namespace_name": "my-workspace",
    "gpu_model": "RTX 4090",
    "created_at": 1779996400,
    "finished_at": 1779999998,
    "total_cost": "0.42000000"
  }
}

• fault_class — none (succeeded), user, or platform. This is what decides whether anything is refunded.
• total_cost — the final, trued-up charge in credit.

Deliveries carry the same X-Meshive-Signature HMAC header as every other Meshive webhook — verify it exactly as described in Webhooks → Verifying the signature. Retries, idempotency (dedupe on the event id), and security rules are also identical.

Limits

Limit	Value
Max run time	1 – 24 hours
Script + requirements.txt size	~960 KiB combined
Environment variables	Up to 64, ~32 KiB total
GPUs per task	Up to 8
Concurrent tasks	No cap — every task is paid
Output files	5 GiB / file · 200 files · 20 GiB total

Note

Limits are tuned and may change. The submit form validates all of them before anything is charged.

Next

• Task billing & refunds — when the meter starts and stops, the fault table, and what gets refunded.