# How the `recovery_model` Enables Automatic Error Recovery in DeepSeek‑Reasonix

> Discover how DeepSeek‑Reasonix's `recovery_model` auto‑recovers from errors independently of the guardian model, streamlining execution plans without human intervention.

- Repository: [YHH/DeepSeek-Reasonix](https://github.com/esengine/DeepSeek-Reasonix)
- Tags: deep-dive
- Published: 2026-08-06

---

**The `recovery_model` is a lightweight, stateless reviewer that evaluates failed execution plans and decides whether DeepSeek‑Reasonix can auto‑recover without human approval, operating independently from the guardian model which only validates tool‑call safety.**

DeepSeek‑Reasonix uses a controller‑based architecture where specialized sub‑agents handle different safety and recovery tasks. While the **guardian model** acts as a safety gate for individual tool calls, the **recovery model** specifically targets plan‑level failures, enabling the system to self‑heal after errors like compilation failures or syntax mistakes. Understanding the distinction between these two reviewers is essential for configuring autonomous operation versus human‑in‑the‑loop safety.

## Configuration and Boot‑Time Selection

The recovery reviewer is optional and configured via the `Agent` struct in [`internal/config/config.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/config/config.go).

```go
// internal/config/config.go
type Agent struct {
    // …
    RecoveryModel string `toml:"recovery_model"` // optional independent reviewer
}

```

You enable it by setting `recovery_model` in your TOML configuration (e.g., [`reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml)):

```toml
[agent]
recovery_model = "deepseek-pro"   # independent reviewer for automatic recovery

guardian_model = "deepseek-pro"   # optional safety reviewer for tool calls

```

During startup, [`internal/boot/boot.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/boot/boot.go) (lines 1950‑1990) constructs a fallback chain. If `recovery_model` is empty, the system falls back to the `guardian_model`, and finally to the main model:

```go
// internal/boot/boot.go
recoveryModel := strings.TrimSpace(cfg.Agent.RecoveryModel)
if recoveryModel == "" {
    recoveryModel = strings.TrimSpace(cfg.Agent.GuardianModel)
}
if recoveryModel != "" {
    // Resolve provider → construct a Recovery reviewer session.
    if rProv, err := NewProviderWithProxy(re, proxySpec); err == nil {
        ctrlOpts.RecoveryReviewer = recovery.NewSessionWithSink(
            rProv, re.Price, modelRefFromEntry(re), sink,
        )
    }
}

```

This ensures that a recovery mechanism always exists, but prioritizes the dedicated recovery reviewer when available.

## How the Recovery Reviewer Works

### Stateless, Lightweight Architecture

Unlike the guardian model, the recovery reviewer maintains no conversation history. In [`internal/recovery/reviewer.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/recovery/reviewer.go) (lines 70‑84), the `Session` struct is stripped of any `agent.Agent` dependency:

```go
// internal/recovery/reviewer.go
type Session struct {
    prov     provider.Provider
    pricing  *provider.Pricing
    modelRef string
    sink     UsageSink
    timeout  time.Duration
}

// NewSession creates an Auto‑Guard reviewer with temperature 0 and MaxTokens 256.
func NewSessionWithSink(prov provider.Provider, pricing *provider.Pricing,
                        modelRef string, sink UsageSink) *Session { … }

```

The reviewer uses **temperature 0** and a **hard token limit of 256** to ensure deterministic, low‑cost decisions. The system prompt defined in `PolicyPrompt` (lines 21‑48 of the same file) instructs the LLM to act as an "Auto plan‑decision reviewer" and enforce a strict JSON output format.

### The Automatic Recovery Flow

When a plan step fails, the controller invokes `ctrlOpts.RecoveryReviewer.Review(...)` with a compact evidence blob containing:

- Task summary
- Failure details
- Diagnosis
- Proposed fix

The reviewer calls `boundedllm.Call` with a **30‑second timeout** and the 256‑token limit. The LLM must return a JSON object indicating an outcome such as `continue` or `confirm`. If the verdict is `continue`, the controller automatically applies the suggested plan without human intervention:

```go
// Conceptual flow in the controller
verdict, err := ctrl.RecoveryReviewer.Review(ctx, failureEvt, diagnosis, proposal, taskSummary)
if err == nil && verdict.Outcome == "continue" {
    // Apply the plan automatically
    applyPlan(verdict)
} else {
    // Fallback to guardian or human approval
    requestHumanApproval()
}

```

If the reviewer returns malformed JSON or times out, the recovery is **not** applied, and the system falls back to the guardian model or prompts for manual approval.

## Recovery Model vs Guardian Model

While both models provide safety reviewers, they differ fundamentally in scope, state management, and resource usage:

| Aspect | Recovery Model | Guardian Model |
|--------|---------------|----------------|
| **Scope** | Evaluates **plan‑level** recovery decisions after a failure (e.g., retrying a compilation). | Evaluates **tool‑call** safety before execution (e.g., blocking dangerous file deletions). |
| **State** | **Stateless** per review; no conversation history or transcript retention. | **Stateful**; maintains a full transcript of prior turns and compacts after every 50 reviews. |
| **Prompt size** | Small system prompt (≈ 2 KiB) + bounded evidence (≤ 6 KiB). | Larger system prompt ([`guardian_policy.md`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/guardian_policy.md)) + potentially large transcript history. |
| **Token budget** | Fixed at **256 tokens** for fast, low‑cost responses. | Up to **6 steps** (≈ 2 k tokens) for comprehensive safety analysis. |
| **Fail‑closed behavior** | Recovery not applied; falls back to main model or human approval. | Tool call denied; user prompted for manual approval. |
| **Use case** | Automatic error recovery for low‑risk plan changes, enabling "run‑and‑recover" workflows. | Safety gate for any tool usage, preventing dangerous actions before they execute. |

The **recovery model** is optimized for high‑frequency, low‑risk decisions where speed and cost matter, while the **guardian model** provides deeper contextual analysis for security‑critical operations.

## Practical Configuration Examples

### TOML Configuration

```toml
[agent]

# Dedicated model for automatic error recovery

recovery_model = "deepseek-pro"

# Optional: separate safety reviewer for tool calls

guardian_model = "deepseek-pro"

```

### Boot‑Time Session Creation

```go
// internal/boot/boot.go (simplified)
recoveryModel := strings.TrimSpace(cfg.Agent.RecoveryModel)
if recoveryModel == "" {
    recoveryModel = strings.TrimSpace(cfg.Agent.GuardianModel)
}
if recoveryModel != "" {
    if rProv, err := NewProviderWithProxy(re, proxySpec); err == nil {
        ctrlOpts.RecoveryReviewer = recovery.NewSessionWithSink(
            rProv, re.Price, modelRefFromEntry(re), sink,
        )
    }
}

```

### Guardian Fallback (When No Recovery Model)

```go
// internal/boot/boot.go (lines 31‑49)
if guardianModel := cfg.Agent.GuardianModel; guardianModel != "" {
    // Build a Guardian session (stateful, with transcript)
    ctrlOpts.Guardian = guardian.NewSession(
        pProv, guardianReg,
        guardian.PolicyPrompt(),
        modelRefFromEntry(ge),
        cfg.Agent.GuardianTemperature,
        ge.Price,
        sink,
    )
}

```

## Summary

- The **`recovery_model`** is defined in [`internal/config/config.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/config/config.go) and set via `recovery_model` in your TOML config.
- It creates a **stateless, lightweight reviewer** in [`internal/recovery/reviewer.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/recovery/reviewer.go) with a 256‑token limit and 30‑second timeout.
- It evaluates **plan‑level failures** and can auto‑recover without human approval if the LLM returns a `continue` verdict.
- It operates independently from the **guardian model**, which is stateful, transcript‑based, and focused on pre‑execution tool safety.
- The boot sequence in [`internal/boot/boot.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/boot/boot.go) implements a fallback chain: recovery model → guardian model → main model.

## Frequently Asked Questions

### What happens if the recovery model is not configured?

If `recovery_model` is empty, DeepSeek‑Reasonix falls back to using the `guardian_model` for recovery decisions. If neither is configured, the controller uses the main model, potentially requiring human approval for all error conditions.

### Why is the recovery reviewer stateless while the guardian is stateful?

The recovery reviewer handles **plan‑level decisions** that require only the immediate failure context (task summary, diagnosis, and proposal), making stateless operation faster and cheaper. The guardian reviewer must evaluate **tool calls** within the broader conversation context, requiring transcript history to understand intent and potential side effects.

### How does the recovery model handle malformed responses?

If the recovery reviewer returns invalid JSON, times out after 30 seconds, or fails to produce a recognized outcome, the system operates in **fail‑closed mode**: the automatic recovery is rejected, and the controller falls back to the guardian model or requests human approval.

### Can I use the same model for both recovery and guardian roles?

Yes. You can set `recovery_model` and `guardian_model` to the same model reference (e.g., `deepseek-pro`). However, they will still operate as distinct sessions: the recovery reviewer will remain stateless with a 256‑token limit, while the guardian reviewer will maintain its separate transcript and safety policy.