> For the complete documentation index, see [llms.txt](https://docs.fritesai.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fritesai.com/concepts/fan-out-scope.md).

# Fan-out scope

`fanOutScope` controls **which turns** of a multi-turn request fan out to the council. Where [`fanOutPolicy`](/concepts/fan-out-policy.md) decides *whether* a turn is worth fanning out, `fanOutScope` decides *which* turns of an agentic task even get asked, and together they bound a long task to a small, predictable number of councils.

The host (Claude Code especially) runs a long tool loop for a single request: one turn to plan, one per tool round-trip, one to conclude. The gateway sees each of these as a separate inbound request. Fanning out a full council on *every* one of them multiplies metered spend by the loop length for near-zero added value on the mechanical steps (run this grep, read that file).

## first-turn (default) vs per-turn

| Value                  | Behavior                                                                                                                                                                                                                                                                |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `first-turn` (default) | Fan out on the substantive **request** turn (the initial reasoning/planning), then drive the mechanical tool-loop continuations with a single agent. A task that takes N tool round-trips pays for **one** council, not N. Fan-out re-engages on each new user request. |
| `per-turn`             | Restore fan-out on every allowed turn, including each tool step. Maximum cross-checking, maximum spend.                                                                                                                                                                 |

## Stateless continuation detection

frites distinguishes a fresh request from a tool-loop continuation **without any server-side session memory**. A turn is a continuation when its request carries a tool result back: an Anthropic `tool_result` in the last user message, or a Responses `function_call_output`. That signal is read from the request *shape* alone, so the decision is correct across server restarts and across concurrent sessions, with no stored state to get out of sync.

Under `first-turn`, a continuation turn runs a single agent; a fresh request turn re-engages the council.

## Background/utility traffic always bypasses the council

The host emits cheap small/fast-model calls (title generation, conversation summarization, topic classification) on a haiku-tier model. These **never** fan out, regardless of `fanOutScope`. frites detects them by model name (matching `haiku`, `small`, or `fast`) and pins them to a *single* child on the model the host actually asked for, tools or not. Fanning a throwaway housekeeping call out to N metered children would be pure waste.

> **Single agent, tool-loop continuation is expected.** With `fanOutScope: first-turn`, only the substantive request turn fans out; the mechanical tool-loop steps that follow run a single agent, and the host's background/utility calls always run a single agent. So seeing `single agent — tool-loop continuation` on follow-up turns is the design working, not a bug.

(Caveat: detection keys on the model name, so running the host itself on a haiku *main* model would read every turn as background and never fan out.)

## Why first-turn is the default

The substantive reasoning (where independent children disagree, surface different approaches, and earn the cost of a council) happens on the request turn. The continuations that follow are mostly mechanical tool execution where a council adds near-zero value but full metered cost. Scoping fan-out to the first turn captures the quality lift where it matters while keeping an entire agentic task to a single council, making spend predictable. `per-turn` is available when you want maximum cross-checking and accept the higher spend.

See [Configuration](/reference/configuration.md) for the `fanOutScope` key alongside `fanOutPolicy`, `defaultN`, and `defaultAgents`.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.fritesai.com/concepts/fan-out-scope.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.