Claude Code Single Request Full-Chain Breakdown: Agent Loop, Database, and Cost-Saving Strategies

You type a single line: "Why is the order page so slow? Fix it." What actually happens between that line and the final answer? According to a deep dive from a YouTube tech channel, every Claude Code interaction runs on the same Agent loop — and understanding this loop is both the dividing line between beginner and advanced, and a high-frequency topic in system design interviews.

This article unfolds layer by layer along "the complete lifecycle of a single request": from terminal input to model response, from database queries to multi-Agent orchestration, and finally to cost optimization — each step accompanied by reusable decision rules.

Layer 1: The Request Enters the Agent Loop

You enter a line of instruction in the terminal, editor, or via the SDK. The window changes, but the underlying loop is the same. Before text reaches the model, Claude Code first supplements context: the CLAUDE.md file and memory files in parent directories are loaded at startup, while project source files are not — the Agent only reads them on demand through tool calls.

So the first model call carries: your instruction, the system prompt, the tool list, memory files, and skill descriptions. The model's reply is not yet the answer — it is the first action.

The loop itself has three phases: gathering context, executing actions, and verifying results. Taking "the order page is slow" as an example, the model first requests to read relevant files, then decides the next step; the loop terminates when a reply no longer contains tool calls, and can also be stopped early via a turn limit or budget cap.

Layer 2: Permission Checks Happen Outside the Model

Most flowcharts get one thing wrong here: the model itself never executes any operation — it only "requests." The tool call already exists before approval, but the real gatekeeper is Claude Code itself — the documentation explicitly states that permission rules are enforced by Claude Code, not the model.

Rules are checked in order: first deny, then ask, finally allow. Hooks can intervene earlier — the pre-tool-use hook sees every call and can intercept it. If your rules mark database commands as "ask," the Agent will pop up a confirmation prompt when it wants to run a query plan.

In an interview, you can phrase it this way: rules live outside the model, there are three types, and deny is checked first.

Only after approval does the tool actually run. In a local session it runs on your own machine; Claude Code can also run in the cloud or be driven remotely. A sandbox is available, but the documentation states it is off by default and covers only shell commands — file tools, MCP servers, and hooks all run outside the sandbox. Read-only tools can execute concurrently, while state-changing tools execute serially. Before each file edit, Claude Code snapshots the file so it can be rolled back at any time.

The hooks mechanism is an interception point Claude Code reserves in the tool-call lifecycle. The pre-tool-use hook runs before permission rule checks, can see the tool name and arguments about to be executed, and has the chance to veto or modify the call outright; there are also post-tool-use, session-start, and other hooks. Hooks are typically configured in project- or user-level settings files, pointing to an executable shell command, so they can do things a rule engine cannot — such as path whitelist validation, calling an external audit service, or double-confirming dangerous commands. The value of understanding hooks is this: permission rules are declarative static configuration, while hooks are programmable runtime gates — together they form defense in depth.

The sandbox boundary deserves separate mention. Claude Code's sandbox is typically based on OS-level isolation mechanisms (such as macOS Seatbelt, Linux bubblewrap/namespaces) that impose filesystem and network restrictions on shell commands. The key point is that it is off by default and covers only shell commands executed through the Bash tool; file read/write tools, MCP server processes, and hooks themselves all run outside the sandbox. This means the sandbox is not a security wall covering all side effects — when enabling it, you should know which execution paths remain unprotected.

Layer 3: What Happens Inside the Database

The tool sends a SQL statement to the database, and the database has its own pipeline. Referring to the official PostgreSQL documentation, the chain looks like this:

Parse, Transform, and Rewrite

The client establishes a connection and sends a query; the parser checks syntax and builds a parse tree. One often-overlooked detail: the parser does no lookups. A separate transformation step determines which tables, functions, and operators you mean. So a misspelled keyword fails at the parse stage, while a nonexistent column only errors at the next step.

Next comes the rewrite system, which applies stored rules — most commonly, views are replaced with their underlying tables, which the documentation calls a form of macro expansion.

Planner and Executor

The planner enumerates all execution methods: full table scan, index scan, different join orders, and estimates a cost for each, choosing the cheapest. When there are many joins, the number of possible orders explodes, and Postgres switches to genetic search, accepting a "reasonable" rather than optimal plan — which is exactly why the Agent first requests the query plan.

The executor runs the plan, and many diagrams draw this as a straight line — it is not. Rows flow upward from the scan nodes at the bottom, but control flow is downward, which the documentation calls a demand-pull pipeline: the top node asks its child for "the next row," and the child asks its own children. Filter conditions are embedded in these nodes, not separate steps. Each scan reads the buffer cache first, and only on a miss requests from the OS (which also has its own cache).

Interview tip: use EXPLAIN ANALYZE, which in version 18 shows buffer hits; note that it actually executes the query. The default cache is typically 128MB, and on a dedicated server the documentation recommends setting it to a quarter of memory.

The executor returns rows as it produces them, and the tool hands the results back to the loop. If the plan shows the orders table doing a full table scan, that becomes the basis for the model's next action: add an index. Meanwhile, every message, tool call, and result is written to a file on your machine — which is why sessions can be resumed later.

The buffer cache (shared buffers) is the page cache PostgreSQL maintains in shared memory, with shared_buffers defaulting to 128MB. A logical read of a data file first checks the cache, and a hit avoids a trap into the OS. EXPLAIN (ANALYZE, BUFFERS) outputs the shared hit (cache hit) and read (must read from disk or OS page cache) counts for each node, which is also the key to determining whether "slow" is slow on disk I/O or slow in the plan itself. Note that ANALYZE actually executes the statement, so write operations should be wrapped in a transaction and rolled back.

Genetic query optimizer is Postgres's fallback strategy when the number of joined tables exceeds a threshold (default geqo_threshold = 12). The number of combinations for exhaustively enumerating all join orders grows factorially with the number of tables, and planning time can exceed execution time, so the planner switches to heuristic search, accepting a "good enough" rather than globally optimal plan. This explains why execution plans may look suboptimal when there are many tables, and reminds the Agent not to assume the plan is optimal when interpreting it.

Layer 4: Six Frameworks for Multi-Agent Orchestration

When one Agent is not enough, all orchestration frameworks answer the same question: who decides what runs next?

The Answer Is "Your Code"

In LangGraph, nodes do work, edges decide what runs next, the checkpoint mechanism saves state, and human pauses are supported. Microsoft's Agent Framework has the same idea, organizing flows with executors and edges; it succeeds Semantic Kernel and AutoGen, can checkpoint after each superstep, and has built-in sequential, concurrent, handoff, and group chat patterns. The benefit of graphs is predictability; the cost is that you have to draw every path yourself.

The Answer Is "A Manager"

CrewAI gives each Agent a role, goal, and backstory. A Crew runs tasks in one of two processes: sequential execution, or hierarchical mode — the latter adds a manager to assign tasks, review output, and decide when work is done. Outside the Crew, a Flow carries steps, state, and branching. By default Agents cannot hand off work to each other; delegation is off, so it reads like a team org chart. The cost is that the manager is itself a model, generating extra calls.

The Answer Is "The Model Itself"

OpenAI's Agents SDK offers two paths: let the model decide, or let code decide. When treating an Agent as a tool, the manager keeps control, calling experts like functions; with handoff, a triage Agent hands the conversation to an expert, who becomes the active Agent. Under the hood, a handoff is nothing more than a tool named something like "transfer to refund Agent." The documentation notes that orchestrating with code is more predictable in speed, cost, and performance — handoffs buy flexibility, code buys determinism.

Handoff vs. "Agent as tool" are two commonly confused delegation approaches, and the difference lies in who holds control. With Agent-as-tool, the manager Agent always holds the main conversation loop; the expert Agent is just a bounded call, and control returns to the manager immediately after it returns results. With handoff, the conversation itself is transferred; the handed-off expert becomes the new active Agent and handles subsequent turns, with the original Agent no longer involved. At the implementation level, handoff appears as a special tool call — the model "calls" it to complete the transfer — so to the model both are tools, differing only in semantics and in the runtime behavior of the call.

Context isolation is the hidden benefit of multi-Agent orchestration. Each sub-Agent has its own context window and receives only explicitly passed information, which both prevents the main conversation from being polluted by large amounts of intermediate results and allows subtasks to run in parallel. The cost is that information must be passed explicitly; cross-Agent state sharing must be handled by the orchestration layer, otherwise sub-Agents will make judgments with missing information.

Two Hybrid Forms

Google's ADK has both: workflow Agents can run sub-Agents sequentially, in parallel, or in loops without model decisions; coordinator Agents delegate through tools generated for each sub-Agent. Version 2 added graphs, replacing these templates in Python and Go.

Finally, the Claude Agent SDK — the same loop that runs Claude Code. By default the loop orchestrates itself, spawning sub-Agents each with their own context; in the TypeScript SDK, workflow tools can orchestrate dozens of Agents at once.

Interview tip: articulate clearly "who decides the next step" — code, a manager, or the model — and choose the minimum degree of freedom that gets the job done.

Layer 5: How the Bill Gets Cut

Every turn resends the entire conversation, so first look at what repeats. According to the channel's analysis, on Claude Opus 5.5 output costs five times as much as input, and caching never affects output pricing.

Caching: Stable Prefix First

Prompt caching relies on a prefix that stays exactly identical: system prompt, tools, memory files. Cache reads are far cheaper than uncached input, live 5 minutes by default, and only an exactly identical prefix counts. So put the stable parts first and the variable parts later. Semantic caching goes further, reusing existing answers to similar questions, but on one benchmark the average similarity of correct hits and incorrect hits was nearly identical (0.84 vs. 0.85) — meaning it cannot always tell right from wrong.

Routing, Batching, and Trimming

Not every turn deserves the largest model. A router sends simple requests to small models and hard requests to strong ones; in the RouteLLM paper, routing cut costs by more than twofold on some tests without hurting quality, and on another benchmark it used several times fewer GPT-4 calls than random routing while maintaining about 95% of GPT-4 quality — though those are 2024 models, so test on your own scenarios.

Tasks that can wait go to the batch API: both Anthropic and OpenAI charge half price for batching, and OpenAI promises results within 24 hours; on Anthropic's API, batch and cache discounts stack. Overnight evals and bulk labeling belong here, not in the real-time loop.

History also needs trimming: Anthropic's compaction mechanism replaces earlier turns with summaries, and context editing cleans up old tool results. Note that cleanup changes the prefix, so the next call pays for a new cache write.

Finally, the model itself: switch to smaller models where sufficient, or do distillation and quantization. An 8-billion-parameter model needs about 16GB for weights at 16-bit, and about 4 to 5GB at 4-bit.

Prompt cache prefix matching requires exact identity from the first token; a change anywhere invalidates all cache from that position onward. Therefore stable content like system prompts, tool definitions, and memory files must come first, and variable content like user input and tool results must come later. Cache writes are usually more expensive than normal input, while reads are far cheaper, so the value of caching depends on how many times the same prefix is reused — one-off requests may actually get more expensive due to writes.

Stacking batching with caching requires attention to semantics: the batch API trades asynchrony and non-real-time operation for a discount, while prompt caching requires repeatedly hitting the same prefix within a time window. Batch jobs often submit similar requests in bulk, which in theory favors cache reuse, but because tasks are not executed in order and the time window is uncertain, the actual hit rate is not guaranteed. When estimating costs, treat the two as optimizations that can stack but do not necessarily take effect together.

Four Rules at a Glance

1. The model only makes requests; rules decide outside it.
2. Rows are pulled up the plan tree; read the plan before adding an index.
3. Clarify who decides the next step, and grant the minimum degree of freedom that gets the job done.
4. Cache prefixes, route simple turns, and remember output is the most expensive.

Putting the whole chain together: you type a line, Claude Code supplements memory files and calls the model; the model requests a tool; hooks go first, then checks proceed in deny, ask, allow order, all outside the model; the tool runs and issues SQL; Postgres parses, rewrites, plans, and pulls rows up the plan tree from the buffer cache; results return, the turn is persisted, and the loop runs again until there are no tool calls; when one Agent is not enough, someone decides the next step — your graph, a manager, or the model itself. That is everything that happens between "Enter" and "the answer."

One-line Summary

From a single Enter press to the final answer, a breakdown of Claude Code's Agent loop, permissions, database execution, multi-Agent orchestration, and cost optimization.

Paragraph Summary

The article breaks down Claude Code's internals along "the complete lifecycle of a single request." The request enters a unified Agent loop; the model only issues tool requests, and permission rules are enforced by Claude Code outside the model in deny, ask, allow order, with hooks able to intercept even earlier. When the tool executes, PostgreSQL first parses and rewrites, then the planner estimates costs to choose a plan, and the executor pulls rows up the plan tree on demand — so the Agent should read EXPLAIN ANALYZE before deciding whether to add an index. The core difference among the six multi-Agent orchestration frameworks is "who decides the next step": code graphs, a manager Agent, or the model itself. Cost optimization revolves around repeated content: cache stable prefixes, route by difficulty, batch deferrable tasks, trim history, and remember that output is more expensive than input.