---
title: "A thousand sessions, one person’s attention · Frazer"
description: "How one person runs a thousand agent sessions: one prompt with variables, a dry run on three items, waves under hard budgets and lane caps, and results reviewed by cluster. Defaults, limits and how a run is measured."
url: https://frazer.ai/ade/sessions
index: https://frazer.ai/llms.txt
tokens: 2443
---

> For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt.

# A thousand sessions, one person’s attention · Frazer

**ADE**  A thousand sessions

# A thousand sessions.  
One person’s attention.

You never watch a thousand sessions. You write one prompt with variables, prove it on three items, let Frazer run the rest under hard budgets and lane caps, and review clusters of similar results. Your attention goes to the dry run, to questions asked once for many sessions, and to the results that differ.

[Start building](https://frazer.ai/start?product=app) [See it step by step](https://frazer.ai/ade/how-it-works)

00 · A run of 1,000 items Fig. 1 · product UI, demo organization

*A fan-out run in the Frazer app, demo organization Acme: pgx v5.7 across 1,000 modules, running, wave 3 of 3; 412 of 1,000 finished, an ETA of about 2 hours 10 minutes, $163.20 of a $400 budget, 31 of 214 draft pull requests open. A: seven buckets: 64 done, 318 need review in 5 clusters, 212 wait on lena in 3 batched asks, 96 running of 100 slots, 280 queued, 19 failed, 11 skipped. B: results grouped by outcome, with the verifier’s passes and the Reviewer’s findings per cluster. C: waiting on you: 174 sessions ask the same question about the pgxpool tracer, answered once for all of them. D: limits: concurrency 96 of 100, the gateway run key at $163 of $400, the Agent PR lane with 1,140 runner-minutes left; the waves, the item rate and the armed kill switch.*

Fig. 1: a fan-out run of 1,000 items, product UI with a demo organization.

A

**Seven buckets, not 1,000 rows** Queued, running, waiting on you, needs review, done, failed and skipped, with cost against the cap and an ETA.

B

**Clusters by the shape of the change** Results grouped by diff, tests and the verifier’s verdict; outliers stand apart.

C

**Asked once, answered once** Questions with the same meaning merge into one; your answer goes to all of them and becomes a standing answer.

D

**Limits you can see** Concurrency, the run’s model key and the Agent PR lane, with the kill switch armed.

01 · How a fan-out works Fig. 2

## One prompt, in waves.  
Each wave earns the next.

A fan-out is a personal campaign: your prompt, your items, your budget. Being wrong costs three items, not a thousand, because nothing else starts until you accept the dry run.

**Fig. 2** A run: items, waves with their gates, admission, model access, CI, and the budget under all of it defaults

### The defaults

Items

**Up to 5,000 per run**, from a catalog query, repositories, tickets, a dataset or a list

Concurrency

**100 sessions at a time per person** by default; an org admin may raise it to 1,000. Project quota still applies

Waves

A dry run on 3, then 10 %, then the rest. The next wave starts when you accept the dry run, then while guardrails hold

Budget

Per item and per run, reserved before each model call; an alert at 80 %, a hard stop at 100 %

Pull requests

Drafts only, one per repository, 40 an hour by default, on the Agent PR lane

Kill switch

For the run, a wave or an item. Trips above 25 % failed after 20 items, on a guardrail breach, at the budget, or after 30 minutes without progress

Who works

The Frazer agent, one headless session per item; or a squad, whose manager hands items to up to 12 workers

```
apiVersion: frazer.ai/v1
kind: Campaign
metadata: {name: pgx-v57, project: acme-staging}
spec:
  owner: user:lena                      # a person, or a squad
  items:
    from: catalog
    query: kind=module AND language=go AND deps.pgx<5.7
  prompt:
    template: |
      Upgrade {{module}} to pgx v5.7 and keep its public API.
      Run {{test_cmd}} in {{path}}; commit on {{branch}}.
  run:
    harness: frazer-agent
    image: {tier: standard, class: std-2}
    route: balanced                     # priority class: batch
    concurrency: 100
    perItem: {budgetUsd: 1.50, timeout: 45m}
    budgetUsd: 400                      # alert 80 %, stop 100 %
    lane: agent-pr
  waves:
    - {name: dry-run, items: 3, gate: person}
    - {name: wave-1, percent: 10, gate: auto}
    - {name: rest, percent: 100, gate: auto, prRate: 40/h}
  outcomes: {cluster: true, verifier: frazer-reviewer}
  notify: digest
```

**Fig. 3** The same run as a resource: what the fan-out sheet creates

02 · Where sessions run Fig. 4

## Real machines for every session.  
None of them your laptop.

Your own sessions run on your devbox. A fan-out’s sessions run headless, each in its own microVM started from a warm pool, so a thousand of them never touch your box, and never slow the session in front of you.

**Fig. 4** Three places a session can run, on the same images and the same cache

### Agent images

Tier What is inside Default class

**Lite** No browser; Python, Node, git and the frazer CLI lite-1 · 0.5 vCPU · 1 GiB

**Standard** Lite plus a headless browser and document tools std-2 · 2 vCPU · 4 GiB

**Full** The devbox toolchain, Docker inside the VM, coding agents full-4 · 4 vCPU · 16 GiB

**GPU** Full plus CUDA; weights on volumes, never in the image gpu-l4 · 1 × L4

Fan-out items run on Lite or Standard; Full and GPU need a plan. Skills, tools, Knowledge and models are an overlay applied when a session starts, so changing them needs no rebuild.

03 · How results come back

## Results come back as decisions.  
Not as a thousand pings.

Before anything reaches you, the Frazer Reviewer checks each result at its exact commit and a verifier from another model family passes or rejects it. What is left is grouped, so the effort follows the number of different changes, not the number of items.

-   *One run of work in a Frazer app session, collapsed to a single row and opened: worked 9 minutes, 4 commands, 6 edits and 1 knowledge lookup, one line per step, then the diff the Reviewer asked for.*
    
    ### One row per run of work
    
    Agent activity collapses into a single row, “Worked 9 min · 4 commands, 6 edits”, that opens to one-line steps. Never paragraphs of agent chatter.
    
-   *The Frazer app’s notification rules: six events may interrupt you, each with its channels (app, Slack, email, phone): a dry run ready for review, a batched ask, a tripped kill switch or 80 % of the run budget, a finished run, a high security finding on something you deployed, and production approvals that need you.*
    
    ### A few interrupts, then a digest
    
    Item events never notify. You hear about the dry run, a batched question, a tripped kill switch or 80 % of budget, and the end of the run; the rest waits for the digest.
    
-   *One outcome cluster in triage: “Import bump only, tests pass”, 196 items in 58 repositories; the representative diff bumps pgx from v5.5.0 to v5.7.4, with tests, the verifier and the Reviewer passing; three random members drawn for a spot check, all the same change.*
    
    ### Review by cluster
    
    A representative, the median diff, and three random spot checks, then accept or reject the whole cluster. A member that differs leaves as an outlier, reviewed one by one.
    
-   *Waiting on you in a fan-out run: 174 sessions ask the same question about the pgxpool tracer, merged into one card with suggested answers; one answer goes to all 174 and can become a standing answer. Two smaller batched asks below it.*
    
    ### Questions asked once
    
    When 174 sessions ask the same thing, it is one card. Your answer goes to all of them, and “make it a standing answer” covers the sessions that have not asked yet.
    

04 · What “1,000” means

## Designed for 1,000.  
Here is what stands behind it.

Frazer is designed for 1,000+ concurrent sessions per organization. That is design capacity, not a measurement. What stands behind it is below: the default quotas that keep a thousand sessions manageable, and what every run reports.

Concurrent fan-out sessions

100 per person by default · an org admin may raise it to 1,000

Items in one run

up to 5,000

Agents per person

25 by default · the organization may raise it to 1,000

Workers per squad manager

up to 12

Sub-agents

two levels deep, four children per run

Pull requests from a run

drafts, one per repository, 40 an hour by default

Agent PR lane

below people’s pull requests · 4-runner floor · 40 % cap · a daily budget that holds jobs

Kill switch

above 25 % failed after 20 items · a guardrail breach · the budget · 30 minutes without progress

### How a run is measured

In every run’s report, from the run’s own records.

-   Person-minutes per 100 accepted results, the measure that matters
-   Accept rate by cluster, and cost per accepted result
-   Item time p50 and p90, queue wait, items per hour
-   Rate-limit backoff and Agent PR lane hold time
-   Reviewer findings per accepted PR, reverts within 7 days

### How your team measures the impact

On your own records: your repositories, CI, deploys and incidents.

-   Cycle time and pull requests merged, split by agent and human
-   Time to merge, from the pull request to main
-   Deployment frequency and change lead time, from Frazer deploys
-   Change fail rate and recovery time, from incidents and rollbacks

We publish no percentages for these until we have measured them, and then with the method.

The ADE

## Keep going.

-   ### [How it works](https://frazer.ai/ade/how-it-works)
    
    One piece of work, from a prompt to production, in eight steps on the real screens.
    
-   ### [Stay in charge](https://frazer.ai/ade/control)
    
    Approvals, budgets, guardrails, grants and Secrets, audit and the kill switch.
    
-   ### [Tour](https://frazer.ai/ade/tour)
    
    Twelve screens of the Frazer app, and every way into the ADE.
    

## Prove it on three.  
Then let the other 997 run.

[Start building](https://frazer.ai/start?product=app) [How you stay in charge](https://frazer.ai/ade/control)