> ## Documentation Index
> Fetch the complete documentation index at: https://docs.praxis-ai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Single Model vs Agent Mode

> Two ways your twin can answer — one model working alone, or a small team it hires and manages. What changes, when to use each, and what it costs.

Most of the time your digital twin answers you the way you'd expect: one AI model reads your question, looks things up if it needs to, and writes back. One mind, start to finish.

**Agent mode** replaces that single mind with a small **team**. One model becomes the manager, and it hires temporary helpers to work on pieces of the job — often several at the same time. It's the difference between asking a colleague a question and asking them to run a small project.

This is separate from [Reasoning & Thinking](/mdx/user-guide/interface/reasoning-and-thinking), which controls how hard a *single* model thinks before answering. The two can be combined.

<Info>
  Agent mode is opt-in per digital twin, and only administrators of a twin can turn it on. If you've never enabled it, everything your twin does is single-model — the rest of this page describes a mode you aren't using yet.
</Info>

***

## The two modes side by side

<CardGroup cols={2}>
  <Card title="Single model" icon="user">
    One model handles everything: reads your question, calls tools, writes the answer. Predictable, fast, and cheap. This is how Pria has always worked and remains the default.
  </Card>

  <Card title="Agent mode" icon="users">
    A manager model plans the work and hires helpers — a writer, a checker, a researcher — who run in parallel. Better for jobs with real steps; slower and more expensive per request.
  </Card>
</CardGroup>

The important thing to understand: **the helpers are separate minds.** They don't share memory with the manager or with each other. Each gets a written brief, does its piece, and reports back. Everything they know about your request is what the manager wrote down for them.

***

## What actually happens in agent mode

<Steps>
  <Step title="Pria decides whether this needs a team">
    Not every request does. A follow-up question, a lookup, a bit of writing — those stay single-model even when agent mode is on. Jobs that look like *building* something are the ones that get a team.
  </Step>

  <Step title="The manager plans">
    Internally this is called the **conductor**. It works in rounds: think, decide, act. In the first round it usually decides who to hire.
  </Step>

  <Step title="It hires helpers by role">
    Each helper gets a role and a written task. Common ones are a **coder** (builds the thing), a **tester** (checks the coder's work), and a **researcher** (gathers material). The manager writes each brief itself.
  </Step>

  <Step title="Helpers work in parallel">
    The manager doesn't watch them. It ends its turn and is woken when they finish. While they work, a live activity panel under the response shows each helper with its role, its tool activity, and elapsed time.
  </Step>

  <Step title="The manager collects and decides">
    It reads what came back, then either hires more help, asks for a revision, or writes your final answer.
  </Step>
</Steps>

***

## Where the files go

If the team produces files, they aren't written straight into your vault.

Each run gets a private **scratch workspace** — think of it as a numbered desk. Helpers build there, so a half-finished draft never appears in your files. When the run completes, the finished work is **moved into your real folder** and the desk is cleared away.

<Note>
  This is why a file can be visible *during* a run and settle into a different place afterwards. The finished version in your vault is the one that lasts.
</Note>

***

## The Mode picker

Agent mode isn't all-or-nothing. Once a twin's administrator has enabled it (the **Enable Subagents** switch in the twin's settings), the administrator also gets a **Mode** section under **\[+] → Subagents** that chooses how much team Pria is allowed to hire. Picking a mode applies to the current conversation and seeds the next new one:

<AccordionGroup>
  <Accordion title="Auto">
    Pria decides per request. Simple questions stay single-model; bigger jobs get a team. The sensible default.
  </Accordion>

  <Accordion title="Basic">
    One model, tools, no helpers. Effectively the classic behavior.
  </Accordion>

  <Accordion title="Advanced">
    A small team for jobs that clearly have steps.
  </Accordion>

  <Accordion title="Expert">
    A larger team, more rounds, more checking.
  </Accordion>

  <Accordion title="Mythical">
    Maximum effort. Use deliberately — this is the most expensive setting.
  </Accordion>
</AccordionGroup>

***

## What it costs

A single-model answer is billed on the tokens that one model used — see [Credits](/mdx/user-guide/credits).

An agent-mode answer can involve **dozens of model calls** — every round the manager thinks, plus every tool call each helper makes. The cost reflects the whole team's work, so the same question can cost noticeably more in agent mode than in single-model mode.

<Tip>
  Leave the mode on **Auto** unless you have a reason not to. It keeps everyday questions cheap and brings in a team only when the job actually warrants one.
</Tip>

***

## When each one is the right choice

<CardGroup cols={2}>
  <Card title="Stay single-model" icon="feather">
    Questions, explanations, drafting, summarizing, follow-ups in a conversation, anything you want back quickly.
  </Card>

  <Card title="Reach for agent mode" icon="diagram-project">
    Multi-step builds, work you want independently checked, or jobs that split naturally into parallel pieces.
  </Card>
</CardGroup>

***

## Known rough edges

Agent mode is newer than the single-model path, and we'd rather tell you where it's thin than have you discover it mid-job.

* **It can misjudge a follow-up.** A short message like *"now update the file"* can occasionally be read as a fresh build request and open a planning interview instead of simply answering.
* **A helper can stall.** A helper that loops without making progress doesn't crash — it just keeps working. A run can therefore stay busy for a long time with little to show.
* **Long jobs can outlive the page.** If your connection drops or your laptop sleeps mid-run, the work continues on the server and the finished result is saved to the conversation — you'll see it the next time you open that chat. Long runs are bounded by a server-side time limit, and an explicit Stop still cancels immediately.

<Note>
  If a run looks stuck, you can stop it. Cancelling ends the run — it doesn't quietly continue in the background.
</Note>