Environment: google-colab-cli==0.6.0, uv tool install, macOS, free Colab account.
Repro:
colab new -s test --gpu T4 # fails (below)
colab new -s test # CPU: "Session READY" immediately
Actual: a full Rich traceback ending in
TooManyAssignmentsError: Failed to issue request POST .../assign?...&accelerator=T4: Precondition Failed
Cause: client.py:241-242 maps any 412 to TooManyAssignmentsError, and it isn't caught at the command layer, so it prints as a stack trace:
if get_status_code(e) == 412:
raise TooManyAssignmentsError(str(e))
Why it's wrong/misleading: On free tier, a 412 for a T4 is a usage-limit/availability refusal, not "too many assignments." CPU allocation succeeds in the same session, so it isn't a concurrent-assignment count — yet the error name implies leftover runtimes, which misdirects debugging.
Suggested fix:
Don't hard-map 412 → TooManyAssignmentsError; surface the server reason, or use a clearer name (e.g. GpuUnavailableError) / structured reason code.
Catch it at the command layer and print a concise message, e.g. "GPU (T4) unavailable right now free tier usage limit or capacity. Retry later or use a paid runtime."
Related to #47 (covers Service Unavailable for scarce GPUs on Pro+); this is the free-tier 412 variant plus the specific mislabel.
Will send a pr soon for this issue, in the mean time need info from other folks on this issue.
Environment: google-colab-cli==0.6.0, uv tool install, macOS, free Colab account.
Repro:
colab new -s test --gpu T4 # fails (below)
colab new -s test # CPU: "Session READY" immediately
Actual: a full Rich traceback ending in
TooManyAssignmentsError: Failed to issue request POST .../assign?...&accelerator=T4: Precondition Failed
Cause: client.py:241-242 maps any 412 to TooManyAssignmentsError, and it isn't caught at the command layer, so it prints as a stack trace:
if get_status_code(e) == 412:
raise TooManyAssignmentsError(str(e))
Why it's wrong/misleading: On free tier, a 412 for a T4 is a usage-limit/availability refusal, not "too many assignments." CPU allocation succeeds in the same session, so it isn't a concurrent-assignment count — yet the error name implies leftover runtimes, which misdirects debugging.
Suggested fix:
Don't hard-map 412 → TooManyAssignmentsError; surface the server reason, or use a clearer name (e.g. GpuUnavailableError) / structured reason code.
Catch it at the command layer and print a concise message, e.g. "GPU (T4) unavailable right now free tier usage limit or capacity. Retry later or use a paid runtime."
Related to #47 (covers Service Unavailable for scarce GPUs on Pro+); this is the free-tier 412 variant plus the specific mislabel.
Will send a pr soon for this issue, in the mean time need info from other folks on this issue.