Colab-notebooks: a catalogue of runnable AI notebooks for Colab and Kaggle

A catalogue, and the reason it exists

The repository is a collection of free Google Colab and Kaggle notebooks for various AI tools, and it hosts notebooks you can run directly in your browser or cloud environment.

The project frames itself as a personal collection rather than a product, and the surrounding badges point to a YouTube channel, an X account and a donation page rather than to documentation or a package. That tells you what kind of artefact this is: a set of runnable examples published alongside video tutorials, not a library with a versioned API.

What makes the collection worth browsing is the coverage. The visible entries span video upscaling, expressive text to speech with voice cloning, a 20B foundation model generating synchronized video and stereo audio, image creation and editing, full song music generation, an image upscaler and restoration model, and standalone TTS. Each entry in the table carries a description, a link to open it in Colab or Kaggle, and a link to a video tutorial.

The primary language of the repository is listed as Jupyter Notebook, and the top-level layout follows from how the notebooks are hosted. There is a notebooks/ directory for the Colab entries, a kaggle_notebooks/ directory for the Kaggle ones, an images/ directory for the button graphics used in the table, and the README itself as the index.

The last push was on 2026-10-19, the repository is not archived, and it has no GitHub releases, which is consistent with a set of notebooks that are edited in place rather than versioned as releases.

Every notebook targets a specific free GPU tier

One detail repeats across the table and it is the most useful thing the README tells you about running any of these: the hardware target.

Several entries are described as optimized for Kaggle GPU T4 x2, which is the two-GPU configuration available on Kaggle notebooks. The Colab entries are described as optimized for Colab Free T4 GPU, and the voice cloning notebook is called out as CPU-friendly with no GPU required and a free cloud API. The image generation entry is described as optimized for Colab Free T4 GPU with INT8 Tensor Cores.

That is a meaningful constraint, and it is the one that decides whether a notebook will work for you. A notebook that expects two T4s will not run on the free single-GPU Colab tier, and a 20B parameter model in INT8 is a specific ask rather than a general one. The descriptions are unusually precise about it, which is helpful, and the precision also tells you these were built and tested against the free tiers rather than against a workstation.

The models themselves are described with their size and their specialisms: a 1.3B DiT for the video upscaler, LTX audio DiT with Gemma-3 12B for the expressive TTS, a 1.5B base model for unified audio generation, a 3B model for full song generation, a 22B distilled model for the video generator. The INT8 and distilled wording in several entries points to the same concern, running a large model inside a small free GPU budget through quantisation and step reduction.

So the practical reading of the collection is that these are recipes for getting a large model to run on a consumer GPU, not just demonstrations of what the model can do.

Why a notebook that worked last month breaks today

The most valuable paragraph in the project documentation is the maintenance note, and it is unusually honest about the fragility of what it ships.

All notebooks across this repository have been reviewed, updated, and verified working as of September 28, 2026. And because cloud platforms and dependencies evolve rapidly, issues can occasionally arise over time due to factors such as Google Colab or Kaggle environment and system package updates, upstream changes, moves, or deprecations in model weights and repositories, and Gradio version updates or tunnel and proxy connectivity issues.

That list is a taxonomy of failure, and each item is a different kind of break. An environment update changes a library version out from under the notebook. A model repository gets moved, renamed or deleted, and the download step fails even though nothing in the notebook changed. A Gradio release changes an interface signature. A tunnel or proxy issue breaks the path from a browser to a runtime that lives somewhere else, which is a networking problem wearing a code error's clothes.

The failure mode worth internalising is the third one. A notebook that loads weights from a URL has a dependency on a repository that someone else owns, and the lifetime of the notebook is not under the notebook author's control. That is the structural cost of shipping notebooks rather than packages, and it applies whatever the individual notebook does.

One entry in the table shows what the author does about this in practice: a ScenA Audio expressive speech generator entry carries a check mark and the word Fixed, which suggests a per-notebook status marker for entries that have been repaired after breaking.

How a broken notebook gets reported and repaired

The project documentation asks for something specific when a notebook fails, and the specificity is telling.

If you run into any errors while running a notebook, you are asked to open an issue and submit it directly on the GitHub repository, or to drop a comment on any video on the AIQUEST Academy YouTube channel. And you are asked to be sure to specify the exact notebook name and paste the complete error message.

Three channels are offered and the issue tracker is listed first, which is the right order for a repository whose contents are files. The YouTube route is there because the tutorials are the discovery path for most visitors, and a comment on the video lands with the person most likely to have run that specific notebook.

Asking for the exact notebook name and the complete error message is what makes the repair loop work at all. The notebooks are independent files with independent dependencies, so a report of a failure without naming the file is a report about a sixth of the repository, and a truncated error message usually leaves the interesting part, the actual exception rather than the stack of warnings above it, out of the picture.

The workflow implies something about the maintenance model. Fixing a broken notebook is not a dependency bump in a manifest, it is an edit to a file, which means the author is doing per-notebook work by hand. That is consistent with the collection being reviewed and updated as a batch on a stated date rather than continuously.

What this collection is and is not for

There are three limits, and they all follow from the format.

The first is that a notebook is a demonstration, not a component. There is no importable module here, no versioned dependency set, and no interface other than the notebook cells themselves. If you want to run a video upscaler in a pipeline, you will end up rewriting the notebook's logic into code you own, and at that point the notebook has served its purpose as a reference rather than as a dependency.

The second is the credential problem. Several entries depend on a hosted inference service rather than running the model locally, the voice cloning entry is described as using a free cloud API, and Gradio-based interfaces need a tunnel or proxy to be reachable from a browser. Free hosted services have free hosted service terms, which usually means rate limits, an availability you do not control, and a policy that can change. A notebook whose main dependency is somebody else's public API is a demonstration of their product as much as of the model.

The third is that the hardware assumptions are tied to two specific platforms. A notebook optimised for Kaggle GPU T4 x2 is not going to run in your own container on a workstation, and rewriting it to fit different hardware is real work that the collection does not do for you.

On the alternative, the honest comparison is with the upstream project for each model. Almost every entry in the table is a packaging of a published model, and the model authors publish their own code, weights and reference implementations. The repository's value over that is the setup: a working environment with the right quantisation, the right distillation steps and the right GPU configuration, assembled and verified. That is real and it saves hours, but it is a convenience layer over work that exists elsewhere, and the upstream is where you go when the notebook stops being enough.

There is also the question of what you run the notebook on. A hosted Colab or Kaggle notebook puts your prompts, your inputs and your outputs on somebody else's infrastructure, which for a demo of a public model is usually fine and for anything involving your own data is a decision you should make deliberately.

Editorial conclusion

Adopt this repository if you want a working reference notebook for a specific model or tool and would rather start from one that has been run than write the setup yourself. Do not adopt it as a production pipeline, since these are hosted notebooks whose runtime, model weights and dependencies all change underneath you. Before you build on one, check its review date against the current state of the model it loads, and note the last push was on 2026-10-19 with no GitHub releases to pin against.

Frequently asked questions

Official sources

1. Issues
2. README
3. TeamAIQ/Colab-notebooks on GitHub