bro first-response latency — 18s with 21.7k token context, 0 MCP tool calls

[ZaxShen]

Observed

During live dogfood, bro's first response took ~18 seconds for a trivial onboarding-trigger message:

@"tmb:bro (agent)" I'm Zax
⏺ tmb:bro(TMB bro entry point)
  ⎿  Done (0 tool uses · 21.7k tokens · 18s)

Two signals in that line matter:

• 21.7k tokens of context loaded per spawn
• 0 MCP tool uses despite "I'm Zax" being a textbook identity_set trigger (separate correctness concern — noted for follow-up, not this issue's scope)

Hypotheses for the 18s latency, ordered by expected impact

H1. Model choice — Opus 4.7 for routing is overkill (highest expected win)

• agents/bro.md frontmatter: model: opus
• Routing, classification, and onboarding flow are not reasoning-heavy — Sonnet handles them just as well.
• Opus first-token latency on 21k tokens is ~5-10x longer than Sonnet. Switching is a one-line change.
• Estimated impact: 60-70% latency reduction. Should drop 18s → ~6s.

H2. Eager skill loading — 7 skills declared in frontmatter, all loaded on spawn

Bro declares all of these in skills: frontmatter:

first-run-onboarding, tmb-reonboard, lazy-regen-check,
project-prescan, branch-id-proposal, refresh-architecture, agent-creator

If CC loads them all on spawn (rather than on-trigger), that's likely 15-18k of the 21.7k tokens. A typical request only needs one of them.

• Research question: does CC 2026 support on-demand skill loading via paths: or trigger: frontmatter? If yes, move 6 of the 7 skills to on-demand. first-run-onboarding is probably the only one that's genuinely eager.
• Estimated impact: 40-60% context reduction; first-token latency scales with context so expect similar perf win.

H3. Chain-of-thought block mandated at response start

Bro's prompt requires a <chain_of_thought> block before any tool call. That's a reasoning preamble every response pays.

• For trivial asks (conversational, onboarding answers), CoT may be more cost than benefit.
• Fix candidate: exempt onboarding mode from CoT requirement ("skip it for one-liner acknowledgements or trivial lookups" is already in the prompt, but may not be honored).

H4. Agent spawn overhead itself

CC has to cold-start the agent on first invocation of a session. Some of the 18s is not bro's fault — it's CC's spawn round-trip. Hard to measure without instrumentation; likely 1-3s.

Suggested action order

1. Switch bro to Sonnet (model: sonnet) — smallest change, largest expected win. Keep Architect on Opus (architectural reasoning actually needs it).
2. Audit skill frontmatter for on-demand triggers — if CC supports it, only first-run-onboarding stays eager. Others load when their trigger condition hits.
3. Measure — add timing to the next dogfood; look for Sonnet bro under 5s on the same trigger.
4. Only if still slow: revisit CoT enforcement, prompt size, agent cold-start.

Acceptance criteria

• bro first-response latency ≤ 6s on "I'm Zax" or equivalent onboarding trigger, measured on cold session.
• Decision recorded on each hypothesis (kept / rejected / deferred) with evidence.
• Sonnet bro produces the same correctness on SCENARIOS.md dogfood scenarios 1-6 (onboarding + routing + classification). If Sonnet fails any, revert and document why Opus is load-bearing.

Related observation (separate follow-up, not this issue's scope)

The 0 tool uses on "I'm Zax" — bro should have called identity_set(human_name='Zax') as part of the onboarding flow. That it didn't suggests first-run-onboarding skill didn't trigger, OR bro's prompt is drowning out the trigger. Worth investigating once the latency fix is in — if H1/H2 reduce context by 60%, this may self-resolve. If it persists at low-latency, file a separate correctness issue.

Surfaced during PR #41 dogfood.

[ZaxShen]

Additional data point from live session

@"tmb:bro (agent)" I'm Zax
⏺ tmb:bro(TMB bro entry point)
  ⎿  Done (0 tool uses · 21.7k tokens · 18s)

⏺ Hey Zax, I'm bro. Trust me bro, it works — that's the plugin's whole pitch.
  I route your work to the right agents and keep things tidy.

  Quick onboarding — two questions, then we're off.

  1. Name. You already told me "Zax" — want me to use that, or something
     different? (Reply with a name, or "anonymous" to skip.)

What this tells us

1. Output shape is correct — bro produced the onboarding welcome using the catchphrase, addressed the user by the name mentioned inline ("Zax"). Text generation is following the prompt.
2. Same 21.7k / 18s profile — confirms the perf story from the first observation isn't noise.
3. 0 tool uses is the interesting signal. Bro's prompt section A.1 First-Run Onboarding explicitly says "at session start, if config_get('branching_model') returns null OR identity_get().created_at is null, enter Onboarding Mode immediately." Neither tool was called. Bro jumped straight to the welcome message from the surface pattern "user said I'm X" without verifying state.

Interpretation

Context bloat is plausibly costing correctness, not just latency. When a prompt competes with ~20k tokens of eagerly-loaded skill content, the model tends to fall back on surface pattern-matching ("this looks like onboarding, generate the welcome") instead of the explicit procedure ("first check MCP state, branch on result").

The 0-tool-uses outcome looked correct THIS time because the session genuinely was new (onboarding was the right move). But if the session had NOT been new — if config was already populated — bro would have wrongly re-triggered onboarding on any "I'm X" message. That's a silent correctness bug waiting for a dogfood scenario where state exists.

Revised fix priority

The earlier action order stands, with one nuance:

1. model: sonnet first — expected latency win AND plausibly a correctness win if sonnet follows explicit-procedure-over-surface-pattern better in smaller context.
2. Audit eager skill loading — the size of the bloat is the same regardless of model. If CC supports on-trigger skill loading, only first-run-onboarding stays eager.
3. Explicit dogfood re-test: with the above changes applied, send I'm Zax to a cold session AND to a warm session (where identity already has a row). Correct behavior is:
   • Cold → onboarding welcome + identity_set.
   • Warm → no onboarding, bro greets and routes based on existing identity.
4. If step 3 still shows 0 tool uses, we have a separate correctness bug beyond perf.

(Original issue body's "related observation" about 0 tool uses is now upgraded to "plausible root cause" — prompt following degrades under context bloat.)

[ZaxShen]

Progress update — NOT resolved by PR #64

PR #64 was mostly about the per-task chain (planning + SWE + push gate), not bro's bare first-response cold-start. CLAUDE.md actually grew by ~30 lines in PR #64 (added ## Direct Mode and ## Push gate sections), so the 21.7k-token first-response context is roughly the same shape (or slightly larger).

The 18s wall-clock for bro's first response with 0 MCP calls is dominated by:

1. CC's session warmup + main-Claude prompt processing of the system instruction set (CLAUDE.md gets baked in here)
2. CC's tool registration (~30+ MCP schemas across the trajectory server)
3. Whatever skills CC eagerly loads at session start (likely none, since plugin's skills frontmatter requires explicit invocation)

PR #64 didn't move the needle on (1) or (2). Direct Mode and the lazy-pr-reviewer-copy save time on subsequent responses, not the first.

Possible next steps (not scoped here)

• Trim CLAUDE.md by extracting some sections to a tmb_bro-deep-doctrine skill that bro loads on-demand. Trade-off: more context-load overhead the first time bro hits a code-touching ask.
• Trim the MCP tool surface — fewer tools = fewer schemas in cold-start context. Some tools (issue_close, issue_get_phase, issue_report_md, task_first_actionable) are rarely used and could be dropped.
• Move skill auto-load discipline — verify no skill is being eagerly loaded by accident.

Keeping open. Would benefit from a focused profiling pass to isolate which sub-component owns the 18s.

[ZaxShen]

Closing as superseded by bro-as-persona doctrine. Filed when bro was a separate subagent (agents/bro.md with model: opus + 7 eager skills, costing ~21.7k tokens + 18s spawn). v0.2.0+ moved bro to a CLAUDE.md persona on main Claude — no spawn cost, no separate context, skills load on-demand via the tmb_* protocol skills (loaded by name only when bro's chain calls for them). The 18s first-response cost simply doesn't apply to the current architecture. Latency tracking moved to #75 with a different methodology.