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

# How Code Mode works

> A coder model writes the solution, a separate critic reviews it, and the coder repairs against that feedback until it passes — self-correcting, multi-model code generation with a PrysmProof.

A normal completion writes code once and hands it back. **Code Mode** treats code as
something to get *right*, not just to produce: one model writes a solution, a **separate**
critic model reviews it, and the coder repairs against that feedback — looping until the
review passes or a budget/iteration cap is hit. It's the
[Reflexion](https://arxiv.org/abs/2303.11366) pattern (Shinn et al., 2023), applied across
*different* models so the critic's blind spots aren't the coder's.

You set the **objective** with a *policy*. PRYSM picks the coder and the critic, runs the
loop, and returns the files, the final review verdict, and a
[PrysmProof v2](/concepts/prysmproof) that binds the task to the code it produced.

<Warning>
  **PRYSM never executes the generated code.** The default critic is a pure LLM reviewer —
  it reads the code, it doesn't run it. That keeps the endpoint safe to call with any task.
  See [Safety](#safety-prysm-never-runs-your-code) below.
</Warning>

```python theme={null}
from prysm import Prysm

client = Prysm()
r = client.code("Write a thread-safe LRU cache in Python with tests", policy="depth")
for f in r["files"]:
    print(f["path"])
    print(f["content"])
print(r["passed"], r["prysm"]["proof"]["proof_hash"])
```

## The loop

Code Mode runs four kinds of stage. Generate and review alternate until the code passes or
the loop runs out of budget.

<Steps>
  <Step title="plan">
    Detect the target language (or honor the one you pass) and select the coder and critic
    models for the policy.
  </Step>

  <Step title="generate">
    The coder writes the complete solution as one or more fenced files. In `depth`, several
    diverse coders write in parallel and the best candidate is kept.
  </Step>

  <Step title="review">
    A **separate** critic model reads the code and returns an explicit verdict —
    `PASS`/`FAIL`, a score, and a list of concrete issues. If it passes, the loop stops.
  </Step>

  <Step title="repair">
    The coder rewrites the solution against the reviewer's issues. The new draft goes back
    to review. Repeat up to `max_iters` total iterations.
  </Step>
</Steps>

The result reports how many iterations ran, the final `passed` verdict, and the full
per-stage trace (when `include_trace` is on) so it's never a black box.

## Policies: the objective dial

A policy says *what you're optimizing for*. It chooses how many coders run and how strong
the critic is.

<CardGroup cols={3}>
  <Card title="efficiency" icon="feather">
    One cheap, capable coder and a lightweight critic. The fewest tokens that still gets a
    reviewed, repaired solution.
  </Card>

  <Card title="balanced" icon="scale-balanced">
    The default. A solid mid-tier coder paired with a strong reasoning critic — the right
    trade-off for everyday code generation.
  </Card>

  <Card title="depth" icon="layer-group">
    Maximum robustness. Several **diverse** coders (different providers) write in parallel,
    the best candidate is kept, and the strongest available critic reviews it.
  </Card>
</CardGroup>

| Policy       | Coders                     | Critic                 | Default `max_iters` |
| ------------ | -------------------------- | ---------------------- | ------------------- |
| `efficiency` | 1 (cheapest capable)       | lightweight            | 3                   |
| `balanced`   | 1 (mid-tier)               | strong reasoning model | 3                   |
| `depth`      | several, diverse providers | strongest available    | 3                   |

<Tip>
  `depth` is where PRYSM's multi-model edge shows: independent coders from different
  providers rarely share the same failure mode, so crossing them and keeping the best
  candidate beats any single model on hard tasks.
</Tip>

## Single-shot mode

Set `review: false` to skip the critic loop entirely — one coder, one draft, no repair.
It's the fastest, cheapest shape, for when you just want a quick generation and will review
it yourself.

```python theme={null}
r = client.code("Write a Python hello world", review=False)
print(r["iterations"])  # 1
```

## Overriding the models

PRYSM picks sensible coder and critic models for the policy, but you can force either:

```python theme={null}
r = client.code(
    "Implement rate limiting middleware",
    coder_model="claude-sonnet-4.5",   # who writes the code
    reviewer_model="deepseek-v4-pro",      # who critiques it
    max_iters=4,                       # generate + up to 3 repairs
    max_cost_usd=0.10,                 # soft budget; stops the repair loop early
)
```

Unknown model ids are ignored and PRYSM falls back to its own selection, so a typo never
breaks the call.

## Confidence and the verdict

The critic returns an explicit `VERDICT: PASS|FAIL` and a `SCORE` between 0 and 1. PRYSM
blends that score with the running confidence so the final number reflects the whole loop,
not just the last turn. The verdict, score, and the concrete issues the critic raised are
all returned on the response:

```json theme={null}
"review": {
  "passed": true,
  "score": 0.92,
  "issues": [],
  "reviewer": "deepseek-v4-pro"
}
```

## PrysmProof v2

Every run is hashed into a [PrysmProof v2](/concepts/prysmproof): a SHA-256 that binds the
`"prysm-code-v1"` tag, the policy, the language, **the task itself**, and every produced
file (`path` + content hash) together with the execution stages. Because the task and the
files are part of the hash, the proof attests to *this code solving this task* — change
either and the hash changes. It's logged to the same store as v1, so you can verify any run
later:

```bash theme={null}
curl https://api.prysm1.com/v1/proof/{request_id}
```

## Safety: PRYSM never runs your code

Generating code is safe; *executing* untrusted, model-written code on a server is not. So
Code Mode's default critic is a pure LLM reviewer — it reasons about correctness, edge
cases, and style from the source alone. Nothing PRYSM ships runs the generated code.

The reviewer is a pluggable interface: a deployment that owns a real, isolated sandbox can
supply its own runner to execute tests, but that's an explicit, self-hosted choice — never
the hosted default.

## When to use Code Mode

<CardGroup cols={2}>
  <Card title="Use chat / routing" icon="route">
    Quick snippets, explanations, or code you'll review yourself. One model, lowest cost,
    OpenAI drop-in.
  </Card>

  <Card title="Use Code Mode (/v2/code)" icon="code">
    Self-contained tasks where you want a reviewed, repaired solution — and a verifiable
    proof of how it was produced.
  </Card>
</CardGroup>

<Note>
  Code Mode is available in both SDKs (`client.code(...)`), the [CLI](/sdks/cli)
  (`prysm code`), and directly via [`POST /v2/code`](/api-reference/code).
</Note>
