PocketFlow: a 100-line Graph abstraction with no model client in it

The whole framework is pocketflow/__init__.py and its abstraction is Graph

PocketFlow claims 100 lines, and the claim points at one file: pocketflow/__init__.py is the entire core, linked from the README as the source you are free to copy. The stated selling points are zero bloat, zero dependencies and zero vendor lock-in. The licence is MIT, the primary language is Python, and the default branch is main.

The design argument is narrower than the marketing. Those 100 lines are said to capture the core abstraction of LLM frameworks, and the abstraction is named: Graph. Multi-agent systems, Workflow, RAG and the rest are presented as patterns you build above a graph, not features you import from it.

That choice has a cost worth naming on the first day. In the project's own comparison table, PocketFlow's row lists one abstraction, Graph, and two empty columns for App-Specific Wrappers and Vendor-Specific Wrappers, both marked None. Nothing in those 100 lines opens a model endpoint or stores a vector.

Install with pip install pocketflow, or copy the single source file

The documented install path is one command, and the documented alternative is to skip the package manager completely.

pip install pocketflow

The alternative is copying the source of pocketflow/__init__.py into your own tree, which the project offers as a first-class option on the grounds that the file is only 100 lines. There is no build step, no extras group and nothing to resolve.

Package metadata is thinner than the prose suggests. The setup.py at the repository root is a short set of setuptools calls:

from setuptools import setup, find_packages

setup(
    name="pocketflow",
    version="0.0.3",
    packages=find_packages(),
    author="Zachary Huang",
    author_email="[email protected]",
    description="Pocket Flow: 100-line LLM framework. Let Agents build Agents!",
    url="https://github.com/The-Pocket/PocketFlow",
)

It declares no python_requires, no install_requires and no extras, which matches the zero-dependency claim. It also declares no long_description, so whatever a package index shows comes from that one description string.

The size table is the project's own, and the empty wrapper columns are the point

The central argument is a table, and the columns matter more than the totals. It puts LangChain at 405K lines and +166MB, with many app-specific wrappers such as QA and Summarization and many vendor wrappers such as OpenAI and Pinecone. CrewAI is listed at 18K and +173MB with FileReadTool and SerperDevTool on the app side and OpenAI, Anthropic and Pinecone on the vendor side. SmolAgent is 8K and +198MB, LangGraph is 37K and +51MB with PostgresStore and SqliteSaver, and AutoGen is 7K and +26MB with those figures qualified as core-only. The PocketFlow row reads Graph, None, None, 100, +56KB.

Two cautions belong next to those numbers. They are the project's own figures rather than an independent measurement, and the AutoGen row carries its core-only caveat in the same cells as its size.

The more useful reading is the None columns. The wrappers being compared away are the QA chains, summarization pipelines, semantic search helpers and store savers a team would otherwise receive for free. The smaller line count is bought by moving that work into your repository, not by removing it.

Without vendor wrappers, retries, streaming and parsing land in your nodes

Ask what has to be written when there are no vendor wrappers and the list runs longer than the feature list suggests. No model client is bundled, so endpoint choice, request shape and stream parsing are yours. No app-specific wrappers means no retrieval chain, no summarization pipeline and no semantic search helper. The documentation site has pages for the agent, multi_agent, workflow and rag design patterns, and those pages describe shapes to assemble rather than modules to import.

Failure handling is where a thin framework costs the most. Check the documentation for what the core provides on retries and timeouts before assuming you must write them yourself.

The offsetting gain is testability. With no vendor layer in the import graph, a unit test can exercise a node without a network stub, and a provider changing its response shape becomes a change in one of your own files instead of an upstream release note you did not read.

setup.py declares 0.0.3 while the only tag is v0.0.0

Versioning is the weakest signal in the repository. The single GitHub release is v0.0.0, dated 2025-03-25, while the package metadata in setup.py declares version="0.0.3". Nothing in the repository ties those two numbers together, so a pip install and a git checkout are not guaranteed to be the same code.

Commit activity is a separate signal and it looks healthier. The last push was on 2026-07-26 and the repository is not archived, so the source is still being touched. Whether that activity is maintenance or new features is not something the project labels anywhere.

Licence and provenance are simple: an MIT LICENSE at the repository root, an author of Zachary Huang, and a self-description of Pocket Flow: 100-line LLM framework. Let Agents build Agents! People building with it are pointed at a Discord server, which the project links as the place to connect with other developers.

The cookbook is the documentation, and every tutorial is rated Dummy

The API is too small to need a manual, so the tutorials carry the load. The cookbook directory holds separate projects: pocketflow-chat, a basic chat bot with conversation history; pocketflow-structured-output, extracting structured data from resumes by prompting; pocketflow-workflow, a writing workflow that outlines, writes content and applies styling; pocketflow-agent, a research agent that can search the web and answer questions; pocketflow-rag, a simple retrieval-augmented generation process; pocketflow-batch, a batch processor that translates markdown into multiple languages; pocketflow-llm-streaming, a real-time streaming demo with user interrupt capability; and an entry named Chat Guardrail.

Read the difficulty column before booking an afternoon. The README introduces them as basic tutorials, and every row visible in its table is marked ☆☆☆ Dummy, so expect introductory material.

The batch project also carries the translated READMEs, in Chinese, Spanish, Japanese, German, Russian, Portuguese, French and Korean, under its own translations folder rather than in a docs tree.

Six language ports live in separate repositories, so fixes do not travel

PocketFlow is not Python-only, but the ports sit outside this repository. The project links separate projects for Typescript, Java, C++, Go, Rust and PHP. Each is its own codebase with its own history, and no claim is made that any of them track the Python source in step.

For a team standardising on one language that is convenient. For a team that may add a second language later it is a divergence risk, because a graph pattern fixed in pocketflow/__init__.py reaches the other implementations only when somebody ports it by hand.

Documentation is a static site at the-pocket.github.io/PocketFlow with one page per design pattern: agent, multi_agent, workflow and rag. A site that thin is a further reason to read cookbook code, since the working version of each pattern is what runs there. Learning material beyond the site is the linked video tutorial plus the Discord.

.cursor/ and .cursorrules are the basis for the agentic coding claim

A 10x productivity boost is claimed for letting AI agents such as Cursor AI build agents. Two files in the repository root back the practice rather than the number: a .cursor/ directory and a .cursorrules file, alongside utils/ and tests/.

Treat the factor of ten as a marketing figure, not a benchmark. The consequence is asymmetric: if you already drive a coding agent, the rules files are worth reading before delegating work into this repository, and if you do not, they do nothing for you.

Correctness ownership follows the same split. With a 100-line core, the questions that decide whether your agent works live in the nodes you add, and the framework's own suite at tests/ cannot answer them for you.

Editorial conclusion

PocketFlow fits a team that wants a graph-shaped control flow, no vendor coupling and no framework in the dependency tree, and that is willing to write and own every provider call. It does not fit a project expecting retrieval chains, summarization pipelines or store integrations out of the box, since the wrapper columns in its comparison table are marked None. Before you commit, compare the cookbook projects against your own use case, check that the pip version and the git tag you install match, and read .cursorrules if you plan to let a coding agent write the nodes.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. The-Pocket/PocketFlow on GitHub