ai-playground, twelve vendor directories and no manifest at the root

Twelve directories and a readme that is the interface

There is nothing to install here, and the repository's shape makes that obvious from one listing.

The root holds a licence, a readme, and twelve directories. Each directory is named for a vendor or product: a cloud provider, a second cloud provider, a data warehouse, two model providers, an agent framework, a second agent framework, a multi-agent platform, an observability tool, a vector database, a vector index framework, a natural language toolkit, and a retrieval framework.

So the unit of the repository is a tutorial, not a library. Each one has its own subdirectory inside its vendor folder, numbered in the order the channel taught them, and the readme's job is to index them.

What is absent is as informative as what is present. There is no continuous integration directory, no contributing guide, no changelog, no license file beyond the standard one, and no issue template. There is no dependency manifest at the root either, so nothing tells you what to install before opening the first notebook.

The homepage is the channel itself rather than a documentation site, which is consistent: the readme is a table of contents and the videos are the documentation.

The OpenAI sequence splits across two beta versions

The provider with the most tutorials also carries the clearest warning sign, and it is in the directory names.

The first tutorial gets a JSON response through the chat completions interface and needs no special handling. From tutorial two through six, five consecutive entries are labelled as using the first beta version of the assistants interface. Tutorial seven is labelled with the second beta version instead.

Only the last one spells the version out in its path, and it spells out the whole phrase. The first six say nothing about which API they target.

That sequence tells a story. Tutorial seven exists to show the difference between polling for a response and streaming one, which is a change in how you talk to the service rather than in what you build. Building the maths tutor, then a browser interface for it, then a customer support chatbot, then two terminal interfaces for that chatbot, and then a comparison of transport models, is a progression that assumes the earlier code still works.

The readme does not add a note saying which API is current. A reader arriving from search will find a table of tutorials that all look equally current, and the version information is only discoverable by reading a directory name.

Five consecutive tutorials on one beta interface

The concentration is the detail that matters more than any single tutorial.

Five of the seven OpenAI tutorials use the earlier beta version of the assistants interface: the personal maths tutor, a graphical interface for that tutor, the customer support chatbot, a terminal interface for that chatbot, and a streaming terminal interface for the same chatbot. Only the polling-versus-streaming tutorial uses the later one.

That is a majority of the provider's examples on an interface the provider has since revised. The tutorials are not wrong; they are a record of an API as it was, which is exactly what tutorial archives are for.

The two tools used are named in the readme and they tell you what each tutorial demonstrates. The maths tutor uses the code interpreter tool, so the lesson is about running code rather than about the interface. The support chatbot uses the knowledge retrieval tool, so the lesson is about giving the model a document source.

What no tutorial in the visible sequence covers is how to delete an assistant or a thread when you are finished with them. That is the first question anyone asks after building a demo on an interface that creates server-side objects.

The tech stack column exists and is empty

Every provider table in the readme has the same five columns, and one of them is never filled in.

The columns are a number, the tutorial title, a description, a tech stack, and then two links. The links are always the same: a link into the repository subdirectory and a link to the video. The number is the position in the sequence.

The tech stack column is empty in every row shown. For a repository whose entire value is code you might run, that column is where the answer to what to install would normally live, and it is the one column left blank.

The consequence is that you cannot work out the dependency surface from the readme at all. A tutorial that uses a vector database needs a running vector database; a tutorial that uses a warehouse needs credentials and a connection; a tutorial that uses an observability platform needs an account and a key. None of that is in the index.

The two agents rows are the same shape, and one of them links onward to a separate directory for a streaming web application. So even within a vendor section, the index sometimes points at another artefact rather than at code you can open in place.

A browser interface, two terminal interfaces, one repository

The tutorials are paired by medium more often than by topic, and the pairing is the clearest sign of how the channel teaches.

Tutorial two builds a maths tutor. Tutorial three is a graphical interface for it, and it is a web framework project rather than Python. Tutorial four builds a customer support chatbot. Tutorial five is a terminal interface for that chatbot, in two languages. Tutorial six is the same terminal interface with streaming, again in two languages.

So four of the seven OpenAI tutorials are interfaces onto one of two underlying examples. That is a teaching pattern: build the thing, then show three ways to talk to it, because the difference between a browser client and a terminal client is where most of the practical decisions live.

It also means the repository is not seven independent samples. Tutorials three, five, and six depend on the code in two, four, and four respectively, and the readme links each interface tutorial back to the tutorial it wraps.

The one lesson that escapes the pattern is the last, which builds nothing and compares two transport models. Everything before it is a progression.

The header states a star target in the first paragraph

The readme opens by asking for stars, with a specific number attached, before it says anything about what the repository contains.

That is a small thing and a common one for tutorial repositories, since the visibility of a channel is measured by the same numbers as the code. It is worth noting mainly because it establishes the register of the document: this is a working creator's repository rather than a foundation's.

The rest of the structure is consistent with that. There is a table of contents hidden behind a click-to-expand element, which keeps a long index off the visible page. Each entry links to a section further down the same document. Near the bottom there are sections for the author's story, for supporting the work, for a star history chart, for contributions, and for the licence.

The contributions section is a sentence rather than a process, which matches the absence of a contributing guide in the repository root. There is no statement about how to report a problem in a tutorial, no test suite, and no way to tell from the repository whether any of these examples still run against the services they call.

Twelve directories, twelve vendors, and one repeated problem

The twelve directories map onto a specific set of vendors, and the mapping is the repository's real content.

Two model providers, one of them with its own cloud platform tutorials and the other with its own. Two agent frameworks plus a multi-agent platform built on its own. A retrieval framework. An observability tool. Two vector stores, one a database and one an index. A cloud provider and a data warehouse. A natural language toolkit.

Each is a vendor tour with numbered entries, and each entry is a video plus a directory. Nothing is shared between them: no common virtual environment, no common dependency file, no common configuration.

That is the honest characterisation of the repetition. The same shape recurs in every vendor section: one tutorial that is a bare API call, then a series that adds a framework, a tool, and an interface, then an evaluation or monitoring entry at the end. Watching two sections side by side teaches you more about the shape of a vendor tutorial than reading either description will.

The maintenance signal is quiet. The last push to the main branch is 23 April 2026, a little over five months before this was checked, the repository is not archived, and there are no releases at all.

Editorial conclusion

Use this repository if you are following the channel and want the code next to the video, because the pairing is the whole point and it is maintained per vendor rather than as one project. Check four things first. Which tutorial you need and how old it is, since the OpenAI examples split across two beta API versions and the directory names record which. Whether you can run the example without a manifest, because there is nothing at the root to install and every tutorial brings its own dependencies. Whether the assistant API examples match what you are building on, since half of that sequence targets an earlier beta. And whether you want a framework comparison or a single stack, because the repository is organised as vendor tours rather than as a project that composes them.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. rokbenko/ai-playground on GitHub