Sefism LLM APIs Cheat Sheet

What it is

The LLM APIs cheat sheet is a quick-revision book on building product features with large language model APIs. It covers the whole path from a single request to a feature that survives real traffic: tokens and context windows, prompts and roles, streaming, structured output, images as input, tool calling, embeddings and retrieval, caching, batching, cost, evals, tracing and security. It has 8 chapters and 56 concepts in each edition, plus 9 rules of thumb and a glossary.

Written by Tauseef Fayyaz, it is a reference rather than a course: each concept is a short card that says what the idea is, why it matters, and, where it helps, a small code example and the mistake people usually make with it.

Three editions: OpenAI, Anthropic and Gemini

The sheet comes in three editions, chosen with a Provider switch at the top: OpenAI, Anthropic and Gemini. Each edition shows the same ideas with that provider's official Python SDK, so you can learn the concepts once and see how they map onto the API you actually use.

Most cards are shared across all three. Where the providers genuinely differ, the edition shows its own card:

• The main endpoint. The OpenAI edition explains the Responses API (client.responses.create, input, instructions and output_text) and warns against mixing in older Chat Completions examples. The Anthropic edition explains the Messages API and its typed content blocks, including the required max_tokens. The Gemini edition explains generate_content and its config object in the google-genai SDK.
• Embeddings. The OpenAI and Gemini editions use each provider's own embedding models. The Anthropic edition explains that Anthropic does not offer an embeddings endpoint, so Claude apps pair with a separate embedding provider.

Model names in every example come from a MODEL setting rather than being written into the code, so the examples keep working when a model is retired or replaced.

Chapter by chapter

1. How LLM APIs work

The basics that shape every request: tokens (and why you budget in them rather than in words), the context window and what counts against it, the provider's main endpoint, your first request with the key read from an environment variable, reading token usage from every response, and choosing a model tier by testing candidates on your own examples instead of a leaderboard.

2. Prompts, roles and sampling

How a request is structured: messages and roles, system prompts, keeping conversation state (resending history yourself or using provider-side state), clear and structured instructions with data wrapped in tags, few-shot examples, temperature and sampling, reasoning and effort settings, and output limits and stop reasons. One card points out that on reasoning models the thinking counts against the output limit, so a tight cap can leave no room for the answer.

3. Streaming, structured output and images

Getting output into a shape your product can use: streaming, relaying a stream from your backend to the browser, schemas with Pydantic, structured output with schema-constrained decoding, validating and repairing output in code, and sending images (and often PDFs) as input.

4. Tool calling and agents

How the model asks your code to do things: defining a tool with a name, description and JSON Schema, the tool-calling loop, returning tool errors instead of crashing the loop, parallel tool calls, tool choice, the difference between a workflow and an agent, and tools from MCP servers.

5. Embeddings and retrieval (RAG)

Grounding answers in your own data: embeddings, similarity search, chunking, vector stores (with Postgres and pgvector as a simple choice), the RAG pipeline end to end, hybrid search and reranking, and grounding and citations so the model says when the sources do not contain the answer.

6. Cost, caching, batching and reliability

What changes when real traffic arrives: prompt caching and why stable content goes first, batch APIs for bulk and offline work, rate limits and HTTP 429, retries with exponential backoff and jitter, SDK retries and typed errors, cost control per feature and user, model routing to the cheapest model that handles a request well, and what makes up latency.

7. Evals and observability

Turning "it seems better" into a number: eval sets, code-based graders, LLM-as-judge with a clear rubric, evals in CI with a pass threshold, logging and tracing each request, hallucinations, and online metrics and feedback from real users.

8. Security and safety

Designing as if every input and output is untrusted: keeping API keys server-side, prompt injection (including instructions hidden in documents and web pages the model reads), treating model output as untrusted, least privilege and human approval for actions that send, delete, pay or publish, personal data and retention, guardrails and moderation, and per-user quotas against abuse.

Each chapter ends with up to three library resources for going deeper, such as OpenAI Cookbook, Anthropic Prompt Engineering Documentation, Building Effective Agents, pgvector, promptfoo and the OWASP Top 10 for LLM Applications.

Rules of thumb it ends with

The sheet closes with nine rules worth keeping next to your editor, among them:

• Build a small eval set before you tune prompts; without it you cannot tell whether a change helped.
• Put stable content first and volatile content last in every prompt so caching can work.
• Check the stop reason on every response before trusting the output.

Who it suits

It suits backend and full-stack engineers adding AI features to a product, students building a final year project on top of a model API, and anyone who has made a few API calls and now needs to make them reliable, affordable and safe. You should already be comfortable with Python and with calling an HTTP API; the examples assume both.

If you are earlier than that, or want a guided path rather than a reference, start with the AI engineering roadmap. If agents and the Model Context Protocol are your main interest, the AI agents and MCP roadmap builds a framework-free agent loop stage by stage and points back to this sheet for the request shapes across providers.

How to use it

• Alongside a build. Keep the edition for your provider open while you write the first version of a feature, and check the pitfall on each card before you ship that part.
• Before a review or a technical round. Read the chapter titles and try to explain each concept in a sentence before you open it. The ones you cannot explain are the ones to revise.
• After each stage of a roadmap. If you are following the AI engineering or AI agents roadmap, revise the matching chapter when you finish a stage: tool calling after the agent loop, retrieval after a RAG stage, evals before you call anything finished.

How it works on Sefism

The public page at /cheatsheets/llm-apis/ lists all eight chapters with their introductions, and the first chapters are open to read in full, with every code example. Keeping the sheet uses credits and opens every chapter in your member area, in all three editions. Everything on Sefism is free to learn from; a few things, like adding a roadmap, keeping a cheat sheet or asking Tauseef a question, use credits. You get starting credits when you create a free account, your first roadmap is free, and if you are learning seriously and run out, you can ask for more.

If a concept does not make sense for the feature you are building, you can send Tauseef a question from your account.

Related on Sefism

• Model Context Protocol cheat sheet, for the protocol behind the "Tools from MCP servers" card.
• AI engineering cheat sheet and AI agents and MCP cheat sheet, the companions to the two roadmaps above.
• Which AI topics are worth learning: agents, RAG, MCP or LLMs?
• Should I learn an agent framework or build agents from scratch?
• LLM Gateway with Semantic Cache, Model Routing and Per-User Budgets, a project that puts chapter 6 into practice.
• Retrieval Assistant for University Regulations and Prompt Injection Regression Test Harness for RAG Support Chatbots, for chapters 5 and 8.

FAQ

Do I need a framework to build with LLM APIs?

Not to start. The sheet uses each provider's official Python SDK directly, and its advice is to begin with one well-prompted call or a simple workflow before reaching for an agent. Frameworks are easier to judge once you have written the tool-calling loop yourself.

Which provider should I learn first?

Whichever your project or employer uses. The concepts in the sheet are the same across OpenAI, Anthropic and Gemini; the three editions show where request shapes and capabilities differ, such as Anthropic having no embeddings endpoint of its own.

How do I keep LLM API costs under control?

Chapter 6 covers it: log tokens per request and per feature, cap output length, trim context, put stable content first so prompt caching works, send bulk work through batch APIs, route simple requests to a smaller model, and set spending alerts and per-user quotas.