Kaggle is not a free AI server: what its quotas and terms allow

Running an LLM API on Kaggle's free GPUs is a popular hack. Kaggle's session limits make it unreliable, and its terms rule out server farming and third-party use.

By the Maborak engineering team · 2026-10-29 · 7 min read

Guides that turn a Kaggle notebook into a free LLM server are common: start a GPU session, load a model, expose it through a tunnel, point an application at the URL. Kaggle’s own documentation and terms answer whether that works and whether it is allowed. The session limits make it unusable as a service, and the Acceptable Use Policy names “server farming” and “activity unrelated to ML data science” as abuse of its resources. This post explains both and does not include a how-to.

Checked 29 October 2026. Limits come from Kaggle’s notebook documentation and GPU usage tips; rules come from the Terms of Use and Acceptable Use Policy, both effective 22 June 2025. Quotations are verbatim and marked [vendor]. Conclusions drawn from them are marked [inferred], with the reasoning shown.

Background

Kaggle, owned by Google, offers free notebooks for machine-learning work: a Docker container with preinstalled libraries, optional internet access, and a free accelerator. The documentation describes the hardware per session: [vendor]

GPU time has a weekly quota that “resets weekly and is 30 hours or sometimes higher depending on demand and resources”. Colab Pro and Pro+ subscribers can link their account for 15 or 30 extra GPU hours a week, an experimental promotion Kaggle may change “at any time without prior notice”. Free GPU and TPU access “is limited: in busy times, you might be placed in a queue”. [vendor]

Mechanics

A notebook session is a container that Kaggle starts and stops. Four documented limits decide how long anything inside it can run:

1. Execution time. A session ends after 12 hours (9 for TPU). A “Save & Run All” batch run must also finish within 12 hours. [vendor]
2. Idle time. An interactive session ends when it is idle. The notebook documentation gives “20 minutes of idle time”; the GPU usage tips say sessions “remain active until they reach the 60 minute idle timeout limit”. The two pages disagree. Either way, an interactive session with nobody working in it does not stay up. [vendor]
3. Weekly GPU quota. Around 30 hours. [vendor]
4. Queueing. Starting a GPU session can wait in a queue when demand is high. [vendor]

Applied to an always-on API: [inferred]

a week                          168 hours
GPU quota                       ~30 hours  → the GPU is off at least ~138 hours a week
one session                     ≤ 12 hours → the endpoint disappears at least every 12 hours
new session                     new container, possibly queued → model reload, new tunnel URL

An endpoint that drops every 12 hours or less, can be offline most of the week and changes address on restart is not a server, whatever it costs.

Impact

The terms matter more than the limits. Three clauses apply to serving a model to an application or to other people:

• Terms of Use: “You will only use the Services for your own internal, personal, non-commercial use, and not on behalf of or for the benefit of any third party.” [vendor]
• Acceptable Use Policy: users agree not “to abuse resources offered as part of the Services, including using such resources to engage in” a list that includes “server farming”, “malicious activity, such as creation or use of malware, hacking tools, or tools for circumvention/obfuscation” and “activity unrelated to ML data science”. [vendor]
• Acceptable Use Policy: not to interfere with the security of the Services, “for example, this may include intentionally jeopardizing the security of the Services by allowing someone else to log into the Services as you”. [vendor]

What follows for the common patterns: [inferred]

• An API for an app, a product or customers is use for third parties and, for a business, commercial use. The Terms exclude both.
• A long-running inference endpoint is the server-farming case the AUP names, regardless of who calls it.
• A public tunnel into the notebook lets traffic that is not the account holder’s reach Kaggle’s compute. The AUP does not name tunnels, but it does name “tools for circumvention/obfuscation” and letting others in as you. A tunnel is at least close to both, and it also exposes whatever runs in the session, including any Kaggle API token stored there.
• Running a model inside a notebook to evaluate it, fine-tune it or generate outputs for your own ML work is the intended use.

The consequence the documents state is account action: a violation “is grounds for termination of your right to use or access the Services”, and “abuse or misuse of GPU resources may result in the suspension or termination of your Kaggle account”. The Terms also allow only one account per person, so a second account to stretch the quota is itself a violation. [vendor]

Probe

There is no local reproduction: the limits are enforced by Kaggle’s platform, and testing them would mean running workloads on a Kaggle account. The procedure below inspects what a session actually gets, inside a notebook you own, without exposing anything.

1. Open a notebook, set Settings → Accelerator to a GPU, and run:

   !nvidia-smi --query-gpu=name,memory.total --format=csv
   !nproc && free -g | head -2
   !df -h /kaggle/working | tail -1

   Compare the GPU model, memory and disk with the table above.

2. Open the quotas in the account settings (Kaggle also shows GPU usage in the notebook editor’s settings menu) to see the remaining weekly GPU hours and when they reset.

3. Leave the interactive session idle and note when it stops. This shows which of the two documented idle timeouts applies to the account.

None of this tests the terms. They are policy, and the account holder accepts them by using the service.

Mitigation

For the work Kaggle is built for, stay inside it:

1. Run inference where the data science happens. Load the model in the notebook, process the inputs, write results to /kaggle/working (20 GB is saved per session) or to a dataset version. No inbound traffic is needed.
2. Use batch runs instead of an open session. “Save & Run All”, or pushing a notebook version with the Kaggle API, runs to completion in a clean container without an idle interactive session holding the GPU. Kaggle’s own tips recommend this to save quota. [vendor]
3. Keep credentials out of shared or long-running notebooks. A Kaggle API token in a notebook gives control of the account to anyone who can run code in it.

For an application, a product or anything other people call:

4. Run the model on infrastructure meant for serving: a GPU instance from a cloud provider, a hosted inference API, or hardware you own. Kaggle’s documentation points users who hit its limits to Google Cloud notebooks, which “run under your project in Google Cloud” without those limits. [vendor]
5. Size before buying. Measure the model’s memory footprint and throughput in a Kaggle notebook first; that is legitimate ML work, and it tells you what instance the service needs.

If a tunnel-based endpoint is already running, stop the session and replace any Kaggle API token that was present in it (tokens are created under Settings > Generate New Token; invalidate the old one from the same settings page), then move the endpoint to one of the options in step 4.

Verification

• No inbound path: in a notebook you are sharing or running long jobs in, !ps aux | grep -Ei 'ngrok|cloudflared|localtunnel|frp|ssh -R' should return only the grep itself.
• Credentials: check that no kaggle.json, KAGGLE_KEY or bearer token is hard-coded in the notebook source, saved outputs or attached datasets.
• Quota use: the quota view in the account settings should show GPU hours tied to notebook runs you started, not to sessions left open.
• Serving moved: the application’s model endpoint resolves to infrastructure you control or pay for, and stays up across a 12-hour window.

Sources

• Kaggle Notebooks documentation: session resources, 12-hour limit, 20-minute idle time, free GPU and TPU, Colab Pro promotion (checked 29 October 2026).
• Kaggle: Efficient GPU Usage Tips: weekly GPU quota and 60-minute idle timeout (checked 29 October 2026).
• Kaggle Terms of Use, effective 22 June 2025.
• Kaggle Acceptable Use Policy, effective 22 June 2025.
• Kaggle MCP server documentation: API tokens (“Settings > Generate New Token”).

Topics: machine-learning, cost