What Is the Separate Critic Model in ADHD? Purpose and Implementation

The separate critic model in ADHD is a distinct LLM instance dedicated to scoring and clustering generated ideas during the convergent phase, operating independently from the generator to ensure unbiased evaluation and error decorrelation.

The ADHD repository implements a tree-of-thought reasoning architecture that strictly separates divergent idea generation from convergent evaluation. Understanding the separate critic model in ADHD is essential for configuring the system effectively, as this component determines which ideas progress through the scoring and clustering workflows.

Why ADHD Uses a Separate Critic Model

The architecture intentionally splits the workload between generation and evaluation for three specific technical advantages.

Decoupling Generation from Evaluation

During the divergent phase, the system operates in "ADHD-mode," producing raw ideas without any evaluation feedback. The critic model runs only during the convergent phase, handling scoring and clustering. This separation prevents the critic's feedback from influencing the generator, ensuring the initial burst of creativity remains pure. According to comments in src/engine.ts, this split between divergent and convergent modes maintains clean architectural boundaries (lines 5-12).

Error Decorrelation Between Models

Using a different LLM—or even a different model family—for the critic helps decorrelate errors from those made by the generator. If the generator produces systematic biases or mistakes, a distinct critic model can still provide reliable scores because it processes the ideas independently. The RunOptions interface in src/types.ts explicitly supports this via the criticModel field, which "override[s] model for the critic passes" (lines 61-64). The engine implementation notes that running the critic on a different model prevents error propagation between phases (lines 27-30).

Cost and Capability Optimization

The generator often requires a large, creative model (such as GPT-4), while scoring and clustering demand less creative horsepower. By specifying a separate criticModel, you can deploy a smaller, faster, and cheaper model for evaluation without sacrificing generation quality. This flexibility allows precise resource allocation based on task requirements rather than using a monolithic model for all operations.

How the Separate Critic Model Works in Code

When the run function executes, the engine determines which model handles evaluation using a fallback pattern:

// Default to the generator model if no separate criticModel is supplied.
const critic = criticModel ?? model;

Source: src/engine.ts (lines 27-30)

This logic ensures that if you do not explicitly provide a criticModel, the system defaults to using the generator model for both roles. However, the architecture remains modular, allowing distinct models when specified.

During the Score + Cluster phase, the selected critic instance is injected into both evaluation functions:

const [scoreMap, clusters] = await Promise.all([
  scoreIdeas(problem, allIdeas, critic),
  clusterIdeas(problem, allIdeas, critic),
]);

Source: src/engine.ts (lines 66-70)

Both scoreIdeas and clusterIdeas receive the critic model explicitly, ensuring all evaluation calls use the designated LLM regardless of the generator configuration.

Configuring the Separate Critic Model

You can specify the critic model either programmatically or via the command line interface.

Programmatic Configuration

When importing the run function from the engine, pass a distinct model identifier via the criticModel option:

import { run } from "./engine";

await run({
  problem: "Design a low‑latency chat UI",
  model: "gpt-4",          // generator model (rich, creative)
  criticModel: "gpt-3.5", // cheaper model for scoring/clustering
  ideasPerFrame: 6,
  topK: 3,
});

This configuration keeps the heavy lifting on GPT-4 for ideation while delegating evaluation to GPT-3.5, reducing API costs.

CLI Configuration

The command line interface exposes the --critic-model flag, parsed in src/cli.ts (lines 65-101):

npx adhd run \
  --problem "Design a low‑latency chat UI" \
  --model gpt-4 \
  --critic-model gpt-3.5 \
  --ideas-per-frame 6 \
  --top-k 3

Both methods ensure the critic model overrides the default behavior, routing all evaluation traffic through your specified LLM.

Summary

• The separate critic model in ADHD handles convergent scoring and clustering independently from divergent generation.
• Decoupling prevents feedback contamination during the pure generation phase ("ADHD-mode").
• Using distinct models for generation and criticism decorrelates errors, improving evaluation reliability.
• Cost optimization allows using smaller models for evaluation while reserving expensive creative models for generation.
• The critic defaults to the generator model (criticModel ?? model) but can be overridden in src/engine.ts or via CLI flags.

Frequently Asked Questions

What happens if I don't specify a criticModel in ADHD?

If you omit the criticModel option, the engine defaults to using the generator model for both tasks. As implemented in src/engine.ts at lines 27-30, the expression const critic = criticModel ?? model ensures the system remains functional without explicit configuration, though you lose the benefits of model separation.

Why does error decorrelation matter for the ADHD critic model?

Error decorrelation ensures that systematic biases or hallucinations from the generator do not automatically contaminate the evaluation scores. Because the critic can run on a different model family, it provides an independent perspective on idea quality, preventing the generator's mistakes from reinforcing themselves during the scoring phase.

Can I use the same model for both generation and criticism in ADHD?

Yes, but it defeats the architectural purpose. While the code in src/engine.ts permits this by defaulting criticModel to the generator model, using the same LLM for both roles eliminates error decorrelation and cost optimization benefits. The system functions correctly, but you sacrifice the key advantages of the tree-of-thought separation.

Which model should I choose for the critic phase?

Select a model with strong analytical capabilities but lower creative requirements than your generator. According to the RunOptions definition in src/types.ts, any valid model string works. Common choices include smaller GPT variants or faster local models that handle classification and clustering efficiently without the high latency of large creative models.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}