zh2408

The 100 lines: https://github.com/The-Pocket/PocketFlow/blob/main/pocketflo... Video: https://www.youtube.com/watch?v=0Zr3NwcvpA0

Could you try to use gemini 2.5 pro? It's free every day for first 25 requests, and can handle 1M input tokens

You can provide GitHub token

This code creates an HTTP session, sets a cookie within that session, makes another request that automatically includes the cookie, and then prints the response showing the cookies that were sent.

I may miss the error, but could you elaborate where it is?

Yeah, RAG is not the best option here. Check out the design doc: https://github.com/The-Pocket/Tutorial-Codebase-Knowledge/bl... I also have a YouTube Dev Tutorial. The link is on the repo.

By default we use both based on regex:

DEFAULT_INCLUDE_PATTERNS = { ".py", ".js", ".jsx", ".ts", ".tsx", ".go", ".java", ".pyi", ".pyx", ".c", ".cc", ".cpp", ".h", ".md", ".rst", "Dockerfile", "Makefile", ".yaml", ".yml", } DEFAULT_EXCLUDE_PATTERNS = { "test", "tests/", "docs/", "examples/", "v1/", "dist/", "build/", "experimental/", "deprecated/", "legacy/", ".git/", ".github/", ".next/", ".vscode/", "obj/", "bin/", "node_modules/", ".log" }

Thank you! And correct, I didn't modify the outputs. For small changes, you can just feed the commit history and ask an LLM to modify the docs. If there are lots of architecture-level changes, it would be easier to just feed the old docs and rewrite - it usually takes <10 minutes.

Thanks—would really appreciate your PR!

Their site seems to be down. I can't find their results.

Haha. The project is fully open-sourced, so you can tune the prompt for the tone/style you prefer: https://github.com/The-Pocket/Tutorial-Codebase-Knowledge/bl...

The Linux repository has ~50M tokens, which goes beyond the 1M token limit for Gemini 2.5 Pro. I think there are two paths forward: (1) decompose the repository into smaller parts (e.g., kernel, shell, file system, etc.), or (2) wait for larger-context models with a 50M+ input limit.

Yeah, I'd recommend trying Gemini 2.5 Pro. I know early Gemini weren't great, but the recent one is really impressive in terms of coding ability. This project is kind of designed around the recent breakthrough.

No, I haven't, but I will check it out!

One thing to note is that the tutorial generation depends largely on Gemini 2.5 Pro. Its code understanding ability is very good, combined with its large 1M context window for a holistic understanding of the code. This leads to very satisfactory tutorial results.

However, Gemini 2.5 Pro was released just late last month. Since Komment.ai launched earlier this year, I don't think models at that time could generate results of that quality.

Yes! This is an initial prototype. Good to see the interest, and I'm considering digging deeper by creating more tailored tutorials for different types of projects. E.g., if we know it's web dev, we could generate tutorials based more on request flows, API endpoints, database interactions, etc. If we know it's a more long-term maintained projects, we can focus on identifying refactoring patterns.

"Workflow can be very dynamic" is a great summary!

No. It's not many agents in the workflow. It's not an agent per node.

The whole workflow and the Runner class is for one agent.

Check out this line: https://github.com/openai/openai-agents-python/blob/48ff99bb...

A single `run_agent` is implemented based on the Runner class and workflow. So usually the workflow is for one agent (unless there is handoff).

I do agree what you said except the first sentence. The design of the Graph is super important. Pocketflow is for those with technical background.

Yes!!

Let me clarify: we are discussing how the Agent is internally implemented, given LLM calls and tools. It can be built using a graph, where one node makes decisions that branch out to tools and can loop back.

The workflow can vary. For example, it can involve multiple LLM calls chained together without branching or looping. It can also be built using a graph.

I know the terms "graph" and "workflow" can be a bit confusing. It’s like we have a low-level 'cache' at the CPU level and then a high-level 'cache' in software.

By low-level, it is with respect to the agent interface.

The original purpose is to help people understand how the inner agent framework is internally implemented, like those:

OpenAI Agents: https://github.com/openai/openai-agents-python/blob/48ff99bb... Pydantic Agents: https://github.com/pydantic/pydantic-ai/blob/4c0f384a0626299... Langchain: https://github.com/langchain-ai/langchain/blob/4d1d726e61ed5... LangGraph: https://github.com/langchain-ai/langgraph/blob/24f7d7c4399e2...

Oh, that’s embarrassing ... pardon my poor English, and thanks so much for pointing that out!

Thank you!

Thank you!

Thank you! I'm not against such hype TBH :)

It's hard for me to comment on something not open sourced

I think you’re referring to function calling: https://platform.openai.com/docs/guides/function-calling

This still returns a string. You need to explicitly program the branch to the right function. For example, check out how OpenAI Agents, released a week ago, rely on a workflow: https://github.com/openai/openai-agents-python/blob/48ff99bb...

It’s kind of like the different levels of abstraction.

For example, for software projects, the algorithmic level is where most people focus because that’s typically where the biggest optimizations happen. But in some critical scenarios, you have to peel back those layers—down to how the hardware or compiler works—to make the best choices (like picking the right CPU/GPU).

Likewise, with agents, you can work with high-level abstractions for most applications. But if you need to optimize or compare different approaches (tool use vs. MCP vs. prompt-based, for instance), you have to dig deeper into how they’re actually implemented.

The current implementations of Agents, e.g., OpenAI agents released last week, are based on graph (workflow): https://github.com/openai/openai-agents-python/blob/48ff99bb...

Not sure about Cursor you mentioned as its agent is not open sourced.

Hey, sorry for the confusion. This tutorial is focusing on the low-level internals of how agents are implemented—much like how intelligent large language models still boil down to matrix multiplications at their core.

Let me clarify: this tutorial focuses on the technical internal implementation of the agent (e.g., OpenAI agent, Pydantic AI, etc.), rather than the UI/UX of the agent-based products that end users interact with.