Skip to main content
Glama

Gpu Submit

gpu_submit

Submit and run a script on a free cloud GPU for training, fine-tuning, or evals; it packages the project, installs dependencies remotely, and keeps the job running.

Instructions

Run a script on a free cloud GPU (or this Mac for smoke tests). gpu-router packages the project (git-tracked and untracked-but-not-ignored files, plus include; credential files never ship), installs requirements.txt / pyproject.toml deps remotely, picks the provider and returns at once; the job keeps running when this call returns. bundle.left_out lists git-ignored paths that did not ship (with bundle.hint): add code with include, datasets with data.

Use it for training, fine-tuning, evals or anything that needs a CUDA GPU or would take long on the laptop. Do NOT use it for quick CPU work that runs fine locally in seconds.

gpu.yaml in the project root is read first; these arguments override it. Give hours (an honest wall-clock estimate): an agent job with no hours or over 1 hour waits for the user's approval, as does reading Keychain secrets or using over half a provider's remaining quota, and a job still running well past its hours is stopped for approval. Then the result says guidance.needs_approval=true with guidance.tell_user: relay it to the user word for word and end your turn; do not approve, resubmit or switch providers yourself.

Safe to retry: calling it again with the same arguments while that job is still active returns it (submitted=false) instead of starting a second copy; request_id makes that explicit. Returns {"job": {...}, "guidance": {...}, "submitted": true, "bundle": {files, bytes, left_out?, hint?, warnings?}}. job.short_id is the ref for the other tools. States: queued -> routing -> (awaiting_approval) -> provisioning -> running (<-> checkpointing, -> migrating when a session ends and it resumes elsewhere) -> done | failed | cancelled | denied. Outputs the script writes to gpu.output_dir() land in /runs// (job.outputs_dir). Follow guidance.follow (see gpu_status).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
envNoNon-secret environment variables for the job. Secret-looking names or values are refused: secrets go in the Keychain (`gpu secrets set NAME`) and are listed under `secrets:` in gpu.yaml.
gpuNoGPU type constraint, e.g. T4. Usually omit.
argsNoArguments passed to the script, e.g. ["--epochs", "10"].
dataNoDatasets as [NAME=]PATH (relative to project_dir, or absolute) or hf://datasets/... URIs. Uploaded once, cached by content, readable at gpu.data_dir()/NAME on the GPU.
nameNoShort job name for humans.
hoursNoHonest expected wall-clock runtime in hours (e.g. 0.25 for 15 minutes). Agent jobs with no hours or over 1 hour wait for approval, and a job still running well past its hours is stopped for approval.
smokeNoA quick smoke test: prefers this Mac (MPS) and runs in minutes.
scriptNoScript to run, relative to project_dir (e.g. train.py or scripts/train.py). Omit to use gpu.yaml's `script`. A non-.py value runs as a command line, split like a shell would, e.g. `bash jobs/run.sh`. Paths in it and in args are relative to project_dir and must ship (see bundle.warnings).
wait_sNoSeconds to wait for the job to be placed or to need approval before returning (default 10).
includeNoPaths or globs relative to project_dir that ship even if git ignores them, e.g. ["third_party/", "data/crops/*.png", "experiments/**/out"] (a directory ships whole; nested git repos too). Added to gpu.yaml `include:`. For code and small files; pass datasets as data. Credential files never ship.
verboseNoReturn the full documents (null fields, every event) instead of the trimmed ones.
vram_gbNoGB of GPU memory the job needs (a hard filter).
providerNoPin one provider (kaggle, colab, local, ...). local = this Mac through gpu-router's queue, one job at a time. Usually omit and let gpu-router choose.
request_idNoOptional id of this submission (e.g. train-yolo-3): calling again with the same request_id returns the same job. Without it, an identical job that is still active is returned instead of a duplicate; a new request_id starts another copy on purpose.
project_dirYesAbsolute path of the project directory on this Mac (where the script and gpu.yaml live; inside a git repo the whole repo ships). Example: /Users/me/code/yolo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnly=false, openWorld=true, idempotent=false, destructive=false; the description goes far beyond them. It discloses what ships and what never ships (credential files), bundle.left_out/hint semantics, the approval trigger conditions (no hours, >1h, Keychain secrets, >half quota), the required agent behavior on needs_approval (relay verbatim, end turn, do not resubmit), retry idempotency (submitted=false on identical active job), and the full job state machine including migration/checkpointing. This is unusually rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and the do/don't routing before the operational detail. It is dense but long, and the enumerated state machine and repeated approval/retry discussion add bulk that could be tightened; still, nearly every sentence carries operational weight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter, open-world submission tool, the description covers packaging, approval gating, retry semantics, output locations, and lifecycle states. With an output schema present it need not explain return shapes, and its return-value summary is a bonus rather than a gap-filler.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: the gpu.yaml-override precedence for all arguments, the approval consequences of an inaccurate `hours`, and the request_id-vs-implicit-dedup distinction. These are semantic relationships the schema cannot express, lifting it above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'Run a script on a free cloud GPU (or this Mac for smoke tests).' It immediately distinguishes itself from siblings like gpu_infer (inference) and gpu_status (monitoring) by naming the packaging/routing behavior it owns. An agent can identify the tool's domain without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit positive and negative guidance: 'Use it for training, fine-tuning, evals or anything that needs a CUDA GPU or would take long on the laptop. Do NOT use it for quick CPU work that runs fine locally in seconds.' It also describes the gpu.yaml-vs-arguments precedence and routes follow-up behavior to guidance.follow (gpu_status).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.