# Performance Implications of Running the *i‑have‑adhd* Skill on Every Response

> Discover the performance impact of the i-have-adhd skill on every response. Learn how it affects latency, costs, and CPU usage, and understand session hook overhead.

- Repository: [Ayoub Ghriss/i-have-adhd](https://github.com/ayghri/i-have-adhd)
- Tags: performance
- Published: 2026-08-05

---

**Running the *i‑have‑adhd* skill on every response adds ~200–300 tokens of overhead per generation, increasing latency, API costs, and CPU usage, while the always‑on session hook incurs only a one‑time load with negligible impact.**

The *i‑have‑adhd* skill in the `ayghri/i-have-adhd` repository shapes model outputs to improve readability for users with ADHD. Understanding the performance trade‑offs between its two activation modes is critical for production deployments where token budgets and response latency matter.

## Two Activation Modes: Always‑On vs. Per‑Response

The repository provides distinct mechanisms for applying the skill, each with dramatically different performance characteristics according to the source code in [`hooks/always-on.sh`](https://github.com/ayghri/i-have-adhd/blob/main/hooks/always-on.sh) and the evaluation harness documented in [`evals/README.md`](https://github.com/ayghri/i-have-adhd/blob/main/evals/README.md).

### Always‑On Mode: Single Load at Session Start

When you create the flag file `~/.claude/.i-have-adhd-always`, the [`hooks/always-on.sh`](https://github.com/ayghri/i-have-adhd/blob/main/hooks/always-on.sh) script executes **once at session initialization**. This script reads [`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md) and prints the ruleset to stdout, after which the skill remains active without further I/O or processing.

The cost breakdown:
- **One file read** of ~1 KB from disk
- **Minimal string processing** to output the content
- **Zero recurring overhead** on subsequent responses

This approach is ideal for interactive sessions where the same shaping rules should persist throughout.

```bash

# Enable always-on mode (one-time setup)

mkdir -p ~/.claude
touch ~/.claude/.i-have-adhd-always

```

To disable:

```bash
rm ~/.claude/.i-have-adhd-always

```

### Per‑Response Condition Skill: Recurring Token Overhead

The evaluation harness supports a `--condition-skill` flag that prepends [`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md) to the system prompt **on every generation**. This mode, shown in [`evals/README.md`](https://github.com/ayghri/i-have-adhd/blob/main/evals/README.md) and orchestrated by [`scripts/run_evals.py`](https://github.com/ayghri/i-have-adhd/blob/main/scripts/run_evals.py), carries measurable penalties:

```bash

# Run evaluation with skill applied to every response

poetry run python -m evals.run \
    --condition-skill skills/i-have-adhd/SKILL.md \
    --setting-sources "" \
    --ignore-user-config \
    --ephemeral

```

## Quantifying the Per‑Response Performance Hit

### Token Overhead

The ruleset in [`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md) contains approximately **200–300 tokens** of instructional text. When prepended to every request, this inflates the prompt size proportionally.

For a conversation with *n* turns, total input tokens increase by roughly **200–300 × n**, directly impacting:

- **API costs** — Most LLM providers bill per input token; recurring overhead compounds quickly
- **Latency** — Larger prompts extend time‑to‑first‑token and overall generation time
- **Context window pressure** — Repeated instructions consume space that could hold user data or prior context

### Parsing and CPU Impact

The model must re‑interpret identical instructions on every turn. While modern serving stacks optimize for this, the repeated parsing still consumes:

- **Additional CPU cycles** on the inference server
- **Attention computation** over the same static prefix tokens

### Cache Inefficiency

Inference‑level caching (KV‑cache reuse between turns) becomes less effective when prompts vary or grow unpredictably. The per‑response skill injection pattern can:

- Reduce prefix‑matching opportunities
- Force more full‑forward passes through the model
- Increase memory pressure from truncated cache entries

## Estimating Real‑World Cost

Consider a production deployment handling 10,000 conversations with 20 turns each:

| Activation Mode | Extra Tokens per Conversation | Total Extra Tokens | Estimated Cost* |
|-----------------|-------------------------------|--------------------|-----------------|
| Always‑on | ~250 (one-time) | 2.5 million | ~$0.50 |
| Per‑response | ~250 × 20 turns | 50 million | ~$10.00 |

*Assuming $0.20 per million input tokens (GPT‑4o‑mini pricing, illustrative)

The per‑response mode costs **20× more** in this scenario, with proportionally higher latency.

## When to Use Each Mode

**Always‑on mode (`~/.claude/.i-have‑adhd‑always`)** suits:
- Long‑running interactive sessions
- Production deployments with consistent shaping needs
- Cost‑sensitive applications

**Per‑response condition skill (`--condition-skill`)** suits:
- A/B testing or evaluation runs comparing shaped vs. unshaped outputs
- Scenarios requiring turn‑by‑turn customization
- Short‑lived ephemeral contexts where setup overhead matters more than per‑turn cost

## Summary

- The **always‑on hook** loads [`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md) once via [`hooks/always-on.sh`](https://github.com/ayghri/i-have-adhd/blob/main/hooks/always-on.sh) with negligible performance impact
- The **per‑response condition skill** adds ~200–300 tokens of overhead on every generation, increasing latency, cost, and CPU usage
- Token overhead scales linearly with conversation length when using `--condition-skill`
- Cache efficiency degrades with repetitive prompt injection
- Production deployments should prefer always‑on mode unless evaluation or customization requirements dictate per‑response application

## Frequently Asked Questions

### How much latency does the per‑response skill add?

Latency increases proportionally with prompt size. The ~200–300 token ruleset adds roughly 5–15 milliseconds per turn on fast inference endpoints, though this varies by model size and serving infrastructure. The dominant factor is typically time‑to‑first‑token scaling with input length.

### Can I switch modes mid‑session?

Always‑on mode is evaluated at session start; removing `~/.claude/.i-have-adhd-always` requires restarting the session to take effect. Per‑response mode via `--condition-skill` is controlled by the evaluation harness on each invocation, allowing dynamic toggling between runs but not within a single harness execution.

### Does the skill affect output token generation speed?

No direct impact. The ruleset shapes *how* the model responds but does not constrain output length or add post‑processing steps. Any perceived slowdown stems entirely from input‑side token overhead and cache effects, not from generation‑time computation.

### Is there a middle ground between always‑on and per‑response?

Not in the current implementation. The repository offers these two distinct paths: [`hooks/always-on.sh`](https://github.com/ayghri/i-have-adhd/blob/main/hooks/always-on.sh) for persistent session‑wide application and [`evals/run_evals.py`](https://github.com/ayghri/i-have-adhd/blob/main/evals/run_evals.py) with `--condition-skill` for evaluation‑time injection. Custom implementations could cache the ruleset client‑side and manage prompt assembly manually to reduce overhead.