The Claude cookbook's recipe table under-reports its own directories, and its example pins a model from last October

The recipe table lists five areas, and the tree holds a dozen more

The readme organises the cookbook into five headings: capabilities, tool use and integration, third-party integrations, multimodal capabilities and advanced techniques. Under them sit roughly twenty named notebooks, which reads like a complete map. The source tree is not that map. Alongside the directories the table does cover there are separate top-level directories for an agent SDK, coding, evaluations, extended thinking, finetuning, managed agents, observability, reusable patterns, skills and tool evaluation, plus one whose name refers to fallback billing, and none of those appear anywhere in the recipe table. The consequence is that the readme under-reports what is available, and it will keep doing so, because new material lands in the tree and the table is maintained by hand. If you are surveying the repository to find out what exists, read the directory listing rather than the table, and treat the table as a curated starting set rather than an index.

Executing the notebook tests calls the API, so verification costs money

The Makefile draws a line between two kinds of test and is explicit about the cost. There is a target for notebook structure tests, described as fast, and a separate target for notebook execution tests, described as slow and in need of an API key, plus a third that runs the notebook tests inside an isolated tox environment and a fourth for quick validation. Both selection by file and selection by directory are supported through two environment variables, and the help text gives a worked example of each. The example environment reinforces the point by setting a test mode flag and a maximum token count of ten. The consequence is the distinction that matters for anyone treating this repository as a quality signal. The fast tests check that a notebook is well formed, not that it does what the prose says, so a notebook can pass every check in continuous integration and still be wrong against a current API. Verifying behaviour means running it, and running it means billing your key.

Python support stops below 3.13, which is one minor version behind

The project manifest declares a narrow interpreter range, written as at least 3.11 and below 3.13. That is two supported minor versions, which is tighter than most projects allow themselves and tighter than the runtime you are likely to have installed. The rest of the manifest is unremarkable and sensible: a floor on the Anthropic client, a floor on the agent SDK, then the notebook stack, an array library, a dataframe library, plotting, requests, a document store client and a JSON web token library. The build backend is a single modern one, and the wheel target packages a directory the manifest itself describes as a dummy package for the build system, which tells you the cookbook is not a distributable library. The consequence is that on a current interpreter you need a version manager to run the notebooks at all, and the ceiling is already behind, so it will need raising before the next Python release rather than after.

The example environment pins a model the project dated in its own comment

Copy the example environment file and you get a working key placeholder, a test mode flag, a low token ceiling, a debug flag, and one model identifier. That identifier is the interesting part, because the file annotates it. The comment next to it notes which model it is and states that it was the latest of its family as of October 2025, with a note that the setting is recommended for cost savings. The last push to the main branch was on 2026-09-28. So the file the project tells you to copy carries a model reference that the project itself flagged as time-bound roughly eleven months ago, and it is the default every notebook will use if you do not override it. The consequence is quiet and cumulative: you run a whole teaching session against a superseded model, you pay for it, and nothing errors. Override the model deliberately rather than inheriting the example, and treat the comment as the reminder it was written to be.

Four lint rules are switched off, and three of them are security relevant

The lint configuration is worth reading closely, because the ignored rules come with reasons and the reasons are the point. Line length is ignored. Asserts are ignored as fine in tests. And then three more, each with a comment: pickle usage is allowed for local data in cookbooks, pseudo-random generators are allowed for non-crypto use, and SQL string construction is allowed for demo and educational code. Each of those is a rule that exists because following it matters in production. The comments are honest and the judgement is defensible for material whose purpose is to be read, where a dense example beats a safe one. The consequence is entirely about what happens next. These notebooks are written to be copied, and the configuration has been tuned so that the copy compiles cleanly, which means a reader inherits the waiver along with the code. Before any of this reaches a service, re-enable the three rules and deal with what they find.

There is nothing to install, and the version number is a placeholder

The manifest gives the project a name and a version of 0.1.0, and there are no GitHub releases at all, so the version is not tracking anything. The wheel configuration packages one directory, and the comment beside it calls that directory a dummy package for the build system, which is a candid admission that the wheel exists to satisfy tooling rather than to be installed. The readme's own framing agrees: it offers copy-able snippets you integrate into your own projects, not an installed package. The prerequisite is a single API key, and newcomers are pointed at a separate fundamentals course first, which is the right advice and rare to see in a repository of examples. The consequence is that you clone this and read it. If you were expecting to add it as a dependency and import helpers, there is nothing to import, and the one Python module in the tree is a build artefact placeholder rather than a library surface.

The examples are Python-first, and porting them is left to you

The readme is honest about the scope of its examples. It says the code examples are primarily written in Python, and that the concepts can be adapted to any programming language that supports interaction with the Claude API. That is the right framing for a vendor cookbook, and it is also a real constraint on reuse. There is no second-language implementation to diff against, so a reader working in another language has to reconstruct the request shape, the parameter names and the streaming behaviour from the Python version and the API documentation. The recipe coverage itself is broad and worth noting: classification, retrieval augmented generation, summarisation, tool use with three worked sub-examples including a customer service agent and a calculator, third-party retrieval against a vector database and a encyclopedia and web pages, embeddings from a third-party provider, four vision notebooks covering images, best practices, charts and forms, image generation paired with a separate diffusion model, sub-agents built from a smaller model alongside a larger one, PDF parsing, automated evaluations, JSON mode, a moderation filter, prompt caching and a cost optimisation checklist that measures pass rate against cost per task.

Editorial conclusion

Adopt Claude Cookbooks as a set of worked examples to read rather than a library to install, because the value is in seeing a complete request and its response for a specific technique, and the repository says outright that there is nothing to pip install. Do not lift notebook code into production without reading the lint configuration first, since the project deliberately disables the rules covering pickle use, pseudo-random generators and constructed SQL strings, with comments saying each is fine for teaching material. Three things to know before you run anything. Executing the notebook tests calls the API and costs money, while the fast tests only check structure, so a notebook can pass and still be wrong. The supported Python range stops below 3.13. And copying the example environment verbatim runs every notebook against a model identifier the project itself marked as current in October 2025.

Frequently asked questions

Official sources

1. Official README
2. Project repository