Update to Symbioza

{
  "description": "Run a containerized batch job — model training, fine-tuning, evaluation, batch inference, preprocessing — on a rented cloud GPU through the Symbioza connector, under a hard dollar budget. Use when the job needs a GPU this machine lacks or more data or scratch space than local disk holds, or when the user asks to run it remotely with a spending cap. Not for local commands, notebooks, SSH sessions or serving live traffic. Covers what to ask, the free estimate, submitting only after the user approves, polling and collecting files.",
  "included_files": [],
  "name": "run-on-symbioza",
  "skill_md_contents": "---\nname: run-on-symbioza\ndescription: Run a containerized batch job — model training, fine-tuning, evaluation, batch inference, preprocessing — on a rented cloud GPU through the Symbioza connector, under a hard dollar budget. Use when the job needs a GPU this machine lacks or more data or scratch space than local disk holds, or when the user asks to run it remotely with a spending cap. Not for local commands, notebooks, SSH sessions or serving live traffic. Covers what to ask, the free estimate, submitting only after the user approves, polling and collecting files.\n---\n\n# Run a job on Symbioza\n\nSymbioza runs a containerized job on a rented cloud GPU machine under a hard dollar ceiling and returns what\nthe run wrote to `/workspace/artifacts/`. This plugin connects its MCP connector at https://symbioza.dev/mcp.\n\n## When to reach for it\n\nReach for Symbioza when the work no longer fits where you are running it:\n\n- it needs a GPU: training or fine-tuning a model, an evaluation suite, batch inference over a large input;\n- it works on a sample here but not at full size — the data or scratch space exceeds local disk;\n- the user wants it run remotely and capped at a dollar amount.\n\nIt is a different shape of work, and not a fit, when the job is interactive (a notebook, a desktop, a\nsession to attach to), needs a long-lived machine administered over SSH, serves live traffic, or produces\nsomething other than files.\n\n## The two gates\n\nTwo gates: an account, and money in it.\n\n1. **An account.** The connector needs signing in once before its tools appear; there is no API key.\n   Creating an account is open. If Symbioza's tools are not available, or a tool answers `unauthorized`, ask\n   the user to connect Symbioza again from their app settings; the browser opens to sign in.\n2. **Money in it.** A new account can connect, estimate for free and read its own job list; only `submitJob`\n   refuses — “prepaid balance: $0.00 available … Add credit on the Symbioza website: https://symbioza.dev/pricing, or lower the budget.” — until the account holds\n   credit. Adding credit is the user's step: they add credit on the Symbioza website,\n   https://symbioza.dev/pricing.\n   `estimateExecution` reports `availableUsd` and `coversThisJob` for the spec, so check before submitting.\n   If it shows `claimableUsd`, the account has free compute credit to claim at https://symbioza.dev/app, with\n   no payment.\n\n## What to ask the user\n\nSupply the workload: the image, the command, its inputs, the expected outputs and budgetUsd. Symbioza sizes the machine — do not ask the user to choose CPU cores, RAM, VRAM, a GPU model, a provider or a region, and do not derive a resource minimum from a thread count, a worker count or a measurement taken somewhere else. gpu.minVramGb, minRamGb and minCpuCores are optional expert floors: declare one only when the workload has evidence for it, and omit it otherwise — an omitted floor is sized by Symbioza, never treated as zero.\n\n- **The image.** It must be one Symbioza has verified: any other is refused with `invalid_spec` and a\n  `supportedImages` list before anything is booked or charged. Pick from that list. A verified image is a\n  stock image and contains none of the user's code: the command must fetch the script and anything else it\n  needs (for example from a URL). Check that before submitting.\n- **The command.** The argv that runs the job. Symbioza runs it as given.\n- **The inputs.** Where the data lives: a URL the rented machine fetches itself (this machine is never on the\n  data path), or nothing if the command downloads its own. To have a file staged and hash-verified, call\n  `describeDataset` with its https URL and paste the `suggestedEntry` it returns into `datasets[]`. Declare\n  `datasetGb` as the total data the machine will ingest.\n- **The outputs.** Every deliverable must be written to `/workspace/artifacts/`. Files written anywhere else\n  are not collected, so a command that saves its model elsewhere finishes with nothing delivered. Check the\n  command before submitting. Keep deliverables small: models, logs, metrics.\n- **The budget.** budgetUsd is what you are willing to spend on the job, and you are never billed more than that. Ask for it\n  explicitly; there is no default, and never choose one for the user. It is a hard ceiling, not an estimate:\n  it is checked before a machine is booked and again before every retry.\n\nDo not ask how long the job will take. The run's time limit comes from `budgetUsd` at the booked machine's\nhourly rate, the 48-hour platform maximum and any `maxRuntimeSeconds` the user sets (a value above 172800 is\nrefused at submit). The estimate's `boundSeconds`, with its `note`, is the longest the run can go on that\nbudget and cap; the machine it books can end it sooner, and a `maxRuntimeSeconds` that machine cannot hold is\nrefused before anything is booked. Show the user that figure and never promise a longer run.\nPut a `gpu` block in the spec for CUDA work — it may be empty. A spec with no `gpu` block is refused with\n`no_compute`.\n\n## The loop\n\n1. **`estimateExecution`** with the spec — free, books nothing, needs no balance. It returns the price,\n   `specDigest`, the account's `availableUsd` and `coversThisJob`, and `runtime`. Show the user the price,\n   the time limit and the budget. **Then stop.** Call `submitJob` only after the user has seen them and told\n   you to submit, in this conversation.\n2. **`submitJob`** with the spec, that `specDigest` and a `clientRequestId` of your own — the one call that\n   spends. It returns an `executionId` and the job runs asynchronously under `budgetUsd`. A spec changed\n   since the estimate is refused; the same `clientRequestId` returns the same job.\n3. **`getStatus`** with the `executionId` — every few minutes, not in a tight loop, and read `nextAction`\n   before touching the spec. If the user is not waiting, stop polling and give them the `executionId`. When\n   the job has finished, call `getArtifact` even if `artifactsReady` is false. For a failed job, `getStatus`\n   says \"nothing of yours ran\" when every attempt died before the command started, and \"fix and resubmit\"\n   only when the user's own code ran and failed.\n4. **`getArtifact`** with the `executionId` — the exit code, the artifact manifest and the price. Read\n   `deliveryComplete` and `deliveryDetail`: a finished run does not by itself mean every file arrived, and\n   each manifest entry carries its own status. The charge shown after completion may change while billing is reconciled. Your total charge for the job, including retries, will not exceed your approved budget.\n\nLost the `executionId` — a new session, the next morning? `listJobs` returns this account's own jobs, newest\nfirst, and is free. Call `cancelJob` only when the user asks: it cannot be undone. It stops a running job and\nends its spend, releasing the machine or only this job's share of a shared machine, which may keep serving\nother work. What the job has used so far is still billed, never more than `budgetUsd`. Status, artifacts,\ncancel and the job list are scoped to the account that submitted the job.\n\n## Long runs\n\nIf an attempt fails on the machine's side, the job may be retried or moved to another machine, unless\n`pinHost` is set. That depends on compatible compute being available, on the attempt limit and on what is\nleft of `budgetUsd`: each attempt is booked only if the remainder covers it, and a run can stop without\ncompleting. Files named `ckpt_step<N>.pt` written to `/workspace/artifacts/` are streamed off the machine as\ncheckpoints; on a replacement machine `SYMBIOSA_RESUME` holds the absolute path of the newest one. The\ncommand must read `SYMBIOSA_RESUME` and load that checkpoint to continue — a command that ignores it restarts\nfrom the beginning. It is unset on a first attempt and whenever no checkpoint could be restored; restore is\nbest-effort. Checkpoint recovery needs that save-and-resume logic in the user's own code.\n\nMore, for the agent deciding: https://symbioza.dev/agent\n"
}