Remove Gemini-specific focus: stop prompting for Gemini API key, stop defaulting subagents to Gemini; move model recommendations to docs

[lowlorenz]

Summary

Chronos is currently built around Gemini as a first-class assumption — it prompts for a Gemini API key on setup and hardcodes a Gemini model as the default expert/subagent. pi already supports any provider/model-id the user has auth for, so this Gemini focus should be removed. Model choice should be the user's, and any model recommendations belong in educational material (docs), not baked into the software.

What to change

a) Stop prompting specifically for the Gemini API key

Chronos: Init Workspace asks the user to enter a Gemini API key and writes GEMINI_API_KEY into .chronos/.env:

• chronos-vscode/src/extension.ts:244 — "Ask for Gemini API key"
• :254 / :261 — input prompts: "Enter your Gemini API key", "...(required for agent to work)"
• :208, :239 — onboarding text describing GEMINI_API_KEY as the key

This frames Gemini as required. Auth should instead go through pi's normal mechanism (/login / auth.json / provider env vars), provider-agnostic. The setup step shouldn't single out Gemini or imply the agent won't work without a Gemini key.

b) Stop using a Gemini model as the standard subagent

The default expert/subagent model is hardcoded to Gemini, and a Gemini Pro model is woven through the tool docs and system prompt as the recommended choice:

• chronos/tools/expert-turn.ts:13 — DEFAULT_EXPERT_MODEL = "google/gemini-3-flash-preview"
• chronos/prompts/system-prompt.md:83 — recommends google/gemini-3-flash-preview, "pick a stronger model (e.g. google/gemini-3.1-pro-preview)"
• chronos/prompts/task.md, chronos/prompts/task-batch.md, chronos/tools/task-batch.ts:32, chronos/tools/view-page.ts:32, chronos/utils/resolve-model.ts:47 — Gemini Pro/Flash used as the example/default everywhere

The task/task_batch/view_page tools already accept any provider/model-id pi has auth for, so there's no technical reason to default to (or recommend) a specific Gemini model in code.

Model recommendations → educational material, not code

Which model is "good for hard pages" is guidance that changes as models change. It should live in docs (README/DOCS.md) as a recommendation the user can follow, not be hardcoded as a default model id or embedded as advice inside prompts/tool descriptions. Concretely:

• Remove the hardcoded Gemini default (require an explicit model, or fall back to whatever the user has configured in pi).
• Strip provider-specific "pick model X" advice out of the system prompt and tool descriptions.
• Document recommended models (and why) in the user-facing docs instead.

Why

• Locks users into one provider and implies the agent is broken without a Gemini key.
• Hardcoded model ids and in-prompt recommendations go stale every model release and require code/prompt edits to update.
• pi is already provider-agnostic; the software should stay neutral and let the user choose, with recommendations as documentation.