Skip to main content

Mighty Colab

Google Colab runtimes your coding agent can operate without babysitting.

PyPI Python License

mighty-colab is a compatibility-first fork of Google's official colab CLI, hardened for AI agents that provision runtimes, execute code, wait for long jobs, recover state, and tear everything down without a human watching the terminal.

It installs as a separate binary, so mighty-colab and colab can coexist. The upstream commands and flags remain familiar; this fork adds the machine-readable contracts and failure handling that unattended workflows need.

Watch the demo · Read the agent field notes · Open the operator skill

Why Mighty Colab?

A human has peripheral vision. An agent has exit codes, stdout, and a tool-call deadline.

Mighty Colab was shaped by a multi-month, agent-driven ML research pipeline: real A100 sessions, hour-long jobs, artifacts written to GCS, and real billing. That work exposed failure modes a person at a terminal can often notice and correct, but an unattended agent cannot.

What goes wrong for an agent What Mighty Colab provides
A remote script raises, but the caller cannot reliably tell what happened Schema-validated --json envelopes with separate CLI and remote-job outcomes
Training outlives a shell or MCP tool call exec-async returns immediately; log --tail provides bounded, incremental polling
The agent restarts while the Colab VM keeps running Server-side session discovery, adopt, orphan recovery, and durable result sidecars
Cleanup runs on every path, including partial failure Idempotent stop for already-absent sessions; genuine teardown failures stay loud and retryable
Multiple agent processes touch the same local state Locked history plus --config isolation for parallel runs
Human-friendly output becomes parser-hostile noise JSON-only stdout, chatter on stderr, stable reason codes, and ANSI-stripped tracebacks

This is not a speculative “AI-ready” wrapper. Heavy use led to 16 upstream defect fixes, plus fixes in this fork's own additions. Fourteen were landed as a reproducing test followed by the fix. The full, candid account—including the bugs introduced by this fork—is in AGENT_USABILITY_LEARNINGS.md.

Install

uv tool install mighty-colab

Or, with pip:

pip install mighty-colab

A 60-second agent workflow

Assuming Application Default Credentials are configured. Every response below was captured live against a real CPU runtime — nothing fabricated. Swap in --gpu T4 / --gpu A100 on new for accelerated workloads (add --high-mem for a high-RAM machine shape, Colab Pro/Pro+ required); the envelope shape is identical either way.

SESSION=agent-job
echo 'print("hello from mighty-colab")' > job.py

# Allocate a named runtime.
mighty-colab --auth=adc --json new -s "$SESSION"
{
  "schema_version": "1",
  "cli_version": "<installed version>",
  "command": "new",
  "status": "ok",
  "exit_code": 0,
  "session": "agent-job",
  "endpoint": "m-s-kkb-use1c1-2ol526ollah5r",
  "variant": "DEFAULT",
  "accelerator": "NONE"
}
# Capture the remote verdict as data, not terminal prose.
RESULT="$(mighty-colab --auth=adc --json exec \
  -s "$SESSION" -f job.py --timeout 3600)"
{
  "schema_version": "1",
  "cli_version": "<installed version>",
  "command": "exec",
  "status": "ok",
  "exit_code": 0,
  "blocks": [
    {
      "code": "import sys\nsys.argv = ['job.py']\n__name__ = '__main__'\n__file__ = '<mighty-colab-exec:job.py>'\nprint(\"hello from mighty-colab\")\n",
      "outputs": [
        {
          "output_type": "stream",
          "name": "stdout",
          "text": "hello from mighty-colab\n"
        }
      ],
      "cell_index": null,
      "cell_id": null
    }
  ]
}
# Teardown happens before either verdict is propagated.
CLEANUP="$(mighty-colab --auth=adc --json stop -s "$SESSION")"
{
  "schema_version": "1",
  "cli_version": "<installed version>",
  "command": "stop",
  "status": "ok",
  "exit_code": 0,
  "session": "agent-job"
}
# Fail if either the remote job or cleanup failed.
jq -en --argjson job "$RESULT" --argjson cleanup "$CLEANUP" \
  '$job.status == "ok" and $cleanup.status == "ok"'
# -> true

Global flags such as --auth, --json, and --config belong before the subcommand. For headless use, pass --auth=adc explicitly: the default OAuth2 flow opens a browser and needs a human.

For ADC setup, accelerator availability, recovery procedures, and the commands an agent must never invoke interactively, run:

mighty-colab skill

That manual is bundled with the installed CLI, so the agent's instructions stay versioned with the tool it is operating.

Machine-readable outcomes with --json

Every command commonly used in an agent loop—new, exec, run, exec-async, log --tail, status, sessions, and stop—can return one validated JSON envelope on stdout.

{
  "schema_version": "1",
  "cli_version": "<installed version>",
  "command": "exec",
  "status": "job_raised",
  "exit_code": 1
}

The important distinction is intentional:

  • The CLI transaction answers “did the client complete its work?”
  • The envelope's status and exit_code answer “what happened in the remote job?”

That separation avoids treating valid IPython results such as SystemExit(0) as client failures, while still making remote exceptions explicit. Envelopes also carry version information, stable reason values, backend http_status when available, structured outputs, and parse errors. Human-readable [colab] ... chatter moves to stderr, leaving stdout safe for jq or another programmatic caller.

Desired-state operations stay automation-friendly: stopping an already-absent session returns status: "ok" with reason: "already_stopped". Querying a missing named session is an error. That difference makes unconditional cleanup safe without hiding a real teardown failure.

See the live, end-to-end new → exec → exec-async → log → stop lifecycle for a complete jq-driven example.

Long jobs that fit short tool calls

Blocking on training for an hour is a poor fit for an agent harness or an MCP request/response cycle. Start the job in the background instead:

mighty-colab --auth=adc --json exec-async \
  -s trainer -f train.py --timeout 3600

The call returns in about a second with the PID and log path. Poll without blocking:

mighty-colab --auth=adc --json log \
  -s trainer --tail --since-offset 0

Use the returned next_offset on the next poll to avoid rereading old output. Only one background job runs per session, and a finished job never blocks the next one. Its terminal JSON result is written beside the log and survives session teardown, so an agent can recover the verdict later.

Recover instead of reallocating

Colab assignments live on the backend, while executable session metadata lives locally. A runtime created by another agent process—or by the Colab web UI—may therefore be visible to sessions but unavailable to exec.

# Bring one server-side runtime under local management.
mighty-colab adopt <ENDPOINT> -n recovered

# Or recover every orphaned assignment.
mighty-colab adopt --orphanage

Re-adopting the same endpoint refreshes its runtime access metadata without throwing away the VM. Add --keep-alive when the original owner is no longer keeping the session alive.

What this fork adds

The official colab README is the command reference for the base CLI. Mighty Colab keeps that surface and adds:

Addition Agent benefit
--json Versioned, validated outcomes instead of scraping prose
exec-async Start long work without holding a caller open
log --tail --since-offset Bounded, incremental polling for agents and MCP clients
adopt [ENDPOINT] / adopt --orphanage Recover runtimes created by another process or UI
reinstall Install packages and restart the kernel so cached imports really update
mcp Expose non-interactive CLI commands as MCP tools
--debug Opt into verbose client and transport diagnostics
sync [--git-aware] Gzip a file tree before transfer; optionally retain sparse Git identity and selected worktree status
usage Compute-unit balance, hourly consumption and eligible accelerators, also as --json; each job envelope records the balance at provision and release
--no-keepalive on new, run, job apply Start no keep-alive daemon. Upstream states that Colab's backend now keeps runtimes alive based on kernel activity and active connections
Chunked uploads Move large files without the single-request failure mode

The fork also tightens failure behavior around remote exceptions, package installation, teardown, kernel and websocket cleanup, concurrent history, stream separation, and large uploads. See the CHANGELOG for the release-by-release detail.

The four rules agents should know

  1. Always name sessions. Random names make recovery and multi-session work ambiguous.
  2. Always pass --auth=adc for headless work. It is a global flag and must precede the subcommand.
  3. Set --timeout deliberately. It limits the gap between outputs, not total wall-clock runtime. Quiet compilation or training often needs 3600 or more.
  4. Always stop what you allocate. A session is a billable VM. Use unconditional teardown, or prefer run for a one-shot job that should clean itself up.

One more execution-model detail matters: exec -f script.py sends the local file's text into a live IPython kernel; it does not copy your repository onto the VM. Mighty Colab supplies sys.argv, __name__, and an honest synthetic __file__, but code that opens __file__ or sibling paths still needs the corresponding files uploaded or cloned remotely.

CLI, embedded MCP, or in-notebook MCP?

You want to… Use…
Drive Colab from shell scripts, CI, Make, or an external coding agent mighty-colab CLI
Expose the same non-interactive workflow to an MCP client mighty-colab mcp
Add interactive agent assistance inside a Colab notebook Google's colab-mcp
Use the supported upstream command surface without this fork's additions Google's colab CLI

Minimal MCP client configuration:

{
  "mcpServers": {
    "mighty-colab": {
      "command": "uvx",
      "args": ["mighty-colab", "--auth", "adc", "mcp"]
    }
  }
}

TTY-bound commands are intentionally excluded, and log --follow is replaced by bounded log --tail polling. MCP results are currently plain text; structured MCP output is a known follow-up to the CLI's new JSON contract. See the MCP server design.

Read more

Contributing

External pull requests are not currently accepted, so contributions do not sit unreviewed. Ideas, bug reports, and agent pain points are very welcome in Discussions.

Mighty Colab is licensed under the Apache License 2.0.

Metadata

Release files for mighty-colab 0.8.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for mighty-colab 0.8.1
File Size Uploaded
mighty_colab-0.8.1.tar.gz 1.7 MB Details

Built distribution (wheel)

Table of built distributions (wheels) for mighty-colab 0.8.1
File Interpreter ABI Platform
mighty_colab-0.8.1-py3-none-any.whl Python 3 none any Details

Total release size: 2.0 MB

Release files / mighty_colab-0.8.1.tar.gz

Download URL mighty_colab-0.8.1.tar.gz
Size 1.7 MB
Tags Source
SHA-256 checksum
How to use checksums
ac462f44b121f53fae79360ef6bc131ab8d173b4456e88a218c3c663c9ad6dfd
BLAKE2b-256 checksum
How to use checksums
795091516c39f20b84829e4ba24494927ca8098234570f7b3da7bff734d8b559
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 6, 2026.

Transparency log

Release files / mighty_colab-0.8.1-py3-none-any.whl

Download URL mighty_colab-0.8.1-py3-none-any.whl
Size 301.8 kB
Tags Python 3
SHA-256 checksum
How to use checksums
9d0c1d01781a05476102af05f7c5bf9c89d28eaccfb6e58049e63f11c83a67e4
BLAKE2b-256 checksum
How to use checksums
8485860450a4090ee8aed1f341e38d065dce55cd733bbdbd792e7cc974863f62
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 6, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.8.1 This release

2 release files

0.8.0

2 release files

0.5.0

2 release files

0.4.1

2 release files

0.4.0

2 release files

0.3.0

2 release files

0.2.2

2 release files

0.2.1

2 release files

0.2.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page