Claude Code interactive "hi" ~12s vs Grok ~2.8s; bare -p is not the real path

Environment

• Claude Code CLI: 2.1.205
• OS: Darwin 27.0.0 (macOS)
• Shell: fish
• Session model often: grok-4.5 (when routed through Claude Code harness)
• Comparison CLI: Grok CLI 0.2.93 (grok-4.5)
• Date: 2026-07-10

Summary

Interactive Claude Code is the problem. A simple REPL message hi takes ~12s end-to-end in Claude Code. The same interactive hi in Grok CLI takes ~2.8s on the same machine.

claude -p "hi" --bare is not representative of interactive UX. Bare -p skips most of the interactive stack (REPL session bootstrap, context injection, MCP/skills/hooks wiring, multi-turn UI path, thinking/tool scheduling). Measuring only bare -p under-reports the real pain users feel every turn.

Primary measurements (interactive path — user local observation)

| Path | Prompt | End-to-end |
|---|---|---|
| Claude Code interactive REPL | hi | ~12s |
| Grok CLI interactive | hi | ~2.8s |

This is the comparison that matters for day-to-day use.

Secondary measurements (non-interactive / bare — for contrast only)

| Command | real time |
|---|---|
| claude -p "hi" --bare | ~2.05s |
| grok -p "hi" | ~13.29s |

Caveats on secondary table:

• Single-run, not averaged.
• Bare Claude looks "fast" precisely because --bare / -p is a stripped path.
• Bare Grok -p was slower in this environment; that does not contradict the interactive result above.
• Do not use bare numbers to claim "Claude is fine". Interactive Claude is ~4x slower than interactive Grok on a trivial hi.

Why bare -p is fast while interactive is slow (hypothesis for team to confirm)

Interactive path likely pays for work bare skips:

1. Session / transcript / system prompt assembly (CLAUDE.md, memory, skills list, MCP tool schemas)
2. Hooks (PreToolUse/PostToolUse/UserPromptSubmit/Stop) even when no tool runs
3. Thinking / effort / multi-step agent loop defaults
4. UI/streaming/statusline/permission mode wiring
5. Model route differences between bare one-shot and long-lived REPL session

Users need an official breakdown, not more speculation.

Related open issues

• https://github.com/anthropics/claude-code/issues/70305 — simple -p extreme latency
• https://github.com/anthropics/claude-code/issues/65547 — startup / first response extremely slow
• https://github.com/anthropics/claude-code/issues/68820 — performance regression

Asks

1. Publish interactive TTFB/TTFT breakdown for a trivial prompt (hi): client prep, context load, network, model first token, thinking, UI render.
2. Same breakdown for bare -p --bare side-by-side so users can see what interactive adds.
3. Document when /fast is available/unavailable (model family, plan, channel, env disables). Note: /fast is N/A when session model is not Opus 4.8/4.7 Anthropic path.
4. Ship an official low-latency interactive profile that does not require /fast (effort off/low, thinking off, lazy MCP/skill load, minimal system context).
5. Public benchmark harness: same prompt, multi-run P50/P95, interactive REPL first (not only bare -p).

Why this matters

Closing local features does not fix perceived slowness when every interactive turn still costs ~12s for hi. Competitor interactive path on the same machine answers in ~2.8s. Without interactive metrics and a low-latency profile, users cannot optimize and the product feels unusable for chat-style turns.