Back to index
OtherHundreds of standalone notebooks and guides, dip in as needed·Free and open source, though running the examples costs API credits

OpenAI Cookbook

4.0

The fastest route from an idea to working code against the OpenAI API, and a reference that quietly taught a generation of engineers what an embedding pipeline looks like. Uneven maintenance is the price of it being free and community driven.

What We Liked

  • Genuinely runnable notebooks rather than documentation snippets, which saves hours per task
  • Covers the awkward operational topics like rate limits, retries, batching and token counting
  • The evaluation recipes are unusually good for free material and cover a badly neglected topic
  • Open source on GitHub, so you can see the history and open an issue when something breaks
  • New capabilities usually land here with a working example before the tutorials catch up

What Could Be Better

  • Quality varies sharply between notebooks because authorship is distributed
  • Older recipes go stale and are not always removed, so you can follow a dead pattern in good faith
  • Vendor material by definition, and it will never suggest another provider or an open model
  • No sequence or curriculum, so it teaches nothing to somebody who does not already know what to look for
  • Running the examples costs real money, and a few of the larger ones cost more than you would expect

Detailed review

The Cookbook occupies an odd position. It is not a course, it has no order, and nobody assessed it. It is also, on any given working day, more useful than most of the courses in this catalogue, because when you need to know how to chunk documents for retrieval or count tokens before a request or handle a rate limit properly, there is usually a notebook here that does exactly that and runs. The best material is the operational stuff nobody else wants to write about.

How to retry sensibly with backoff. How to batch requests without tripping limits. How to count tokens before you send, so you find out about a context problem in your own code rather than in an error response. How embeddings actually behave at scale, and what to do about the fact that a naive similarity search over a large corpus is slower and worse than people expect.

This is the unglamorous middle layer between a tutorial and a production system, and it is where most projects actually get stuck. Having runnable answers to it saved me a great deal of time before I ever paid for a course on the subject. The retrieval material deserves specific credit. Long before retrieval augmented generation became a phrase on every consultancy slide, the Cookbook had notebooks working through the real mechanics, including the parts that go wrong.

Chunking strategies and their tradeoffs, when embeddings mislead you, why you probably want a reranking step, how to combine keyword and vector search. A lot of engineers, myself included, learned this pattern here first. The evaluation recipes are the other standout, and they matter more now than they did. Evaluating a system whose outputs are text is genuinely hard, most teams do it by vibes for far too long, and free material on the topic is thin.

The notebooks on building evaluation sets and using models as graders are a reasonable starting point, with the obvious caveat that a grader from the same family as the system under test carries its own bias. Now the problems, and they are structural rather than accidental. Distributed authorship means quality is inconsistent. Some notebooks are meticulous, with clear explanation of why each step exists.

Others are a wall of cells with barely a comment, clearly written by somebody in a hurry to demonstrate a feature. You cannot tell which you have until you are in it. Staleness is the bigger issue. The API surface moves quickly, patterns get superseded, and older notebooks linger.

Somebody arriving to learn the current approach can easily follow a recipe that was correct eighteen months ago and is now the long way round, or that calls something deprecated. There is no reliable visual marker for freshness beyond checking the repository history, which a beginner will not think to do. This is the predictable cost of an open repository that accepts contributions faster than it retires them, and it is worth checking the commit date on anything you are about to build on. The vendor framing needs saying plainly.

This is OpenAI's marketing surface for developers, and a good one. Every recipe assumes their models, their SDK, their pricing and their capabilities. There is no discussion of whether an open weight model would be adequate for your task at a fraction of the cost, no comparison with other providers, no mention of the lock in you accumulate by building against a proprietary interface. That is entirely reasonable for a vendor repository and it means the Cookbook cannot be your only input if you are making architectural decisions.

And it teaches nothing to a newcomer. There is no path, no prerequisites, no explanation of the underlying ideas. To use it well you need to already know what you are looking for, which means it complements a proper course rather than replacing one. Someone who has worked through a solid LLM engineering resource will find the Cookbook doubles their speed.

Someone starting cold will find a pile of notebooks and no way in. My 4.0 is a reference score rather than a course score. It is free, it is often excellent, it covers the operational reality that polished material skips, and I open it most weeks. It loses ground for inconsistency, for stale recipes presented alongside current ones with nothing to distinguish them, and for being a single vendor's view of a field with several credible options.

[ final ]

The verdict.

Bookmark it as a reference and use it constantly. Do not mistake a collection of recipes for an education in building AI systems.