First-run UX: an interactive local/cloud flow in jarvis init?

[joshazmy]

Problem Statement

First run has friction for less-technical users: choosing between a local model and a cloud provider, and landing on a model that fits their hardware. A lot of the machinery already exists — jarvis init detects hardware, calls recommend_engine() / recommend_model() (core/config.py), writes ~/.openjarvis/config.toml, and seeds memory files, and cli/_bootstrap.py already detects cloud keys including OPENROUTER_API_KEY (with secret redaction). What's missing is a friendly, guided way to choose "100% local" vs "OpenRouter cloud" without reading docs first.

Proposed Solution

Extend jarvis init (no new top-level command, one config writer) with:

• jarvis init --interactive — friendly local-vs-cloud prompts, reusing the existing recommenders and the single write_initial_config() path.
• jarvis init --local — force the local path.
• jarvis init --cloud openrouter — cloud path, only when explicitly chosen or when OPENROUTER_API_KEY is already set.
• No secret storage: if cloud is chosen, point the user to set OPENROUTER_API_KEY (already auto-detected by _bootstrap.py); never write API keys into config.toml.
• Keep jarvis ask strictly non-interactive — if there is no config/engine, fail with a crisp hint ("run jarvis init"), not an interactive launch.
• Lean on jarvis doctor for post-setup diagnostics rather than new wizard branching.

The one question I'd like guidance on before writing code

Should first-run setup live inside jarvis init (my lean: yes — single config writer, no drift), or would you prefer a separate top-level command? I want to avoid creating two config-generation paths that diverge over time.

Explicitly OUT of scope for v1

Voice/STT setup, any third-party dictation app (e.g. Wispr Flow), manual GPU-size / VRAM tier menus, AMD-specific model heuristics, and storing API keys in config — all deferrable to separate discussions if there's appetite.

Alternatives Considered

• A new jarvis setup wizard command — rejected: duplicates and drifts from jarvis init's config writing.
• Auto-launching the flow from jarvis ask — rejected: breaks scripts, CI, --json, quiet / non-TTY runs.
• Prompting for and storing API keys — rejected: new secret-handling surface; environment variables already work.

Primitive Area

Other (CLI first-run / jarvis init).

---

If the direction is agreed, I'm happy to implement it as a small, tested PR that proves non-interactive behavior is unchanged.

[joshazmy]

Quick update, and one decision I'd like your call on before I open a PR.

I prototyped this on a branch. It extends jarvis init rather than adding a new command, reusing the existing pieces (recommend_engine / recommend_model, generate_minimal_toml, _bootstrap.detect_cloud_keys):

• jarvis init --interactive → a friendly "100% local vs OpenRouter cloud" picker; --local / --cloud openrouter / -y/--yes as non-interactive shortcuts.
• Local mode auto-picks a hardware-appropriate model; cloud mode reads OPENROUTER_API_KEY from the environment and never writes the key to config (and defaults to an OpenRouter-routable model so the first jarvis ask actually works).
• After writing config: a verification smoke test (engine reachable → model present → a tiny test query → PASS / NEEDS ATTENTION with exact repair commands; --no-verify to skip), plus printed RAM-optimization tips (commands only — never mutates the environment).
• --force backups are timestamped; default non-interactive jarvis init is unchanged. 18 tests, ruff-clean.

WIP branch for reference: https://github.com/joshazmy/OpenJarvis/tree/feature/init-interactive

The one thing I'd like a steer on before opening a PR: should first-run setup live inside jarvis init (my current approach — single config writer, no drift), or would you prefer a separate top-level command (jarvis setup / jarvis configure)? I want to match your intended command surface rather than guess, and I'm happy to rehome the helpers either way.