[ahamsel]

Why

Until now the collaboration was one-way. Jev drove fast mode and handed the whole task to the LLM planner as soon as it hit trouble. From then on the planner did every click itself, at 2–4s per step. A real two-part request on the user's MUN mailbox ("when is my rendez-vous with Horizon TNL, and when is the Dean's List") took 81–108s.

What changed

LLM → Jev (delegate)

• The planner can hand Jev a concrete sub-goal ("open the email from Integration TNL").
• Jev runs it in fast mode (at most 10 steps and 40s, with the overall task as context) and returns its steps plus the page it ended on, elements and text included, so no extra observe() is needed.

Jev → LLM, one step at a time

• When Jev is blocked, stuck, guessing (top option under 0.1), making no progress, or its call fails, fast mode asks the LLM to pick that single step, then keeps driving.
• It hands the task to the planner only if the LLM says the task needs careful work, or after 2 consults (1 inside a delegation).
• LLM-chosen steps show in the LLM lane of the flight log.

Multi-part requests

• A new Jev preflight question, multiple_parts, or multi_part from the LLM router, sends requests like "find X and also Y" planner-first.
• The planner then delegates each part to Jev in turn. Fast mode alone would stop after the first part.

Context windows

• Jev's limit through OpenRouter is 32k tokens for state plus questions.
• Requests are estimated before sending. Over 24k, the element list is trimmed to the most task-relevant elements and the text excerpts are shortened.
• Task, context and history text are capped.
• Real runs peak around 10.7k tokens, so this is a safety net.
• The planner's older page views keep their text but drop their (stale) element lists, via a new compactToolResponse option on ToolChat, so later steps don't re-read tens of thousands of tokens.

Answer quality

• The planner answers only from pages it saw; it no longer fills gaps with general knowledge.
• It navigates known search URLs directly (Gmail #search/<query>, ?q=).

Dev loop

• reload retries until the browser reports the new build (Chrome sometimes ignores self-reloads).
• Bridge shutdown closes keep-alive polls, so benchmark runs exit.

Results

User's real MUN mailbox (Edge, LastPass present), starting in the MUN account: 18.6s, correct, with 6 LLM and 7 Jev calls.

• Horizon TNL: Thu Oct 1, 1:00 PM, with Andrii Oliinyk.
• Dean's List ceremony: Sep 29, 5:15–7:00 PM.

Previous runs took 81–108s. Starting from a blank tab, the task still depends on knowing which Google account holds the MUN mail; that's the proposed follow-up (local "what WebPilot knows about you").

Realistic suite in the user's real browsers, including the new two-part scenarios:

	Chrome	Edge
Overall	11/11	11/11, median 7.6s
mail_two_parts	13.2s (was 31.2s)	10.9s
books_two_parts	5.7s	10.0s

Other checks

• npm test: 62/62. New tests cover: a blocked Jev consulting the LLM and continuing; the LLM advising a handoff; a failed Jev call handled by the LLM; the context budget trimming; the planner delegating each part of a multi-part request; history compaction.
• npm run extension:smoke: 11/11.
• npm run build passes.

Follow-ups

• Local personal memory (e.g. "my MUN email is mail.google.com/mail/u/3"), so personal tasks start in the right place.
• A/B test a stronger planner model (Claude Sonnet 5 vs Gemini 3.8 Flash) now that the planner makes few calls.
• Jev's answer check sometimes scores a correct inbox summary near 0 (when it mentions the ignored injection email), which sends a 2.5s task down the slow path.

🤖 Generated with Claude Code