I don't work on this anymore.

Nyvero was a base I built to learn how a coding agent fits together, and I'm happy with where I stopped. I'm not planning to keep building it. But there's a lot of obvious room to grow, so if any of the ideas below sound fun, please take one and run with it. Open an issue or a pull request on GitHub.

Five ideas

What I'd add next, roughly in order.

Each one is the smallest version that would fit Nyvero without making the core harder to read.

1. An MCP client

What Nyvero could do: today the tools are hardcoded in TOOLS. Add an mcp.py that connects to stdio or HTTP servers, converts MCP tool schemas into the same {"type":"function",...} shape the loop already expects, and registers them into TOOLS. This is the biggest win: you get a whole ecosystem of tools without bloating the readable core.

TOOLS += await load_mcp_servers(config)
schemas = [tool_to_schema(t) for t in mcp_tools]

2. Extensions and custom tools

What Nyvero could do: let people drop in a plain Python module, say ~/.nyvero/tools.py or .nyvero/tools/*.py, that registers entries into TOOLS and new slash commands into commands.COMMANDS. It's a small change that turns Nyvero from a fixed set of tools into something extensible.

# .nyvero/tools.py
def register(tools, commands):
  tools["deploy"] = deploy_schema, deploy_fn

3. Headless and scriptable modes

What Nyvero could do: agent.py only runs the interactive REPL right now. Pull the run loop into a function, then add -p/--print <prompt> for a one-shot run, --json for structured events, --auto to skip the confirm prompts, and --version. This is also what CI needs, and what the installer's existing nyvero --version call expects.

$ nyvero -p "fix the failing test" --json --auto

4. A session tree, with fork and branch

What Nyvero could do: session.py writes a flat append-only list and --resume only opens the newest file. Add a parent_id to each JSONL entry, then add --session <id>, /fork, and /branches. That lets you try a different approach without throwing away the history you already have.

entry = {"id": new_id, "parent_id": prev_id, "role": "assistant", ...}

5. Provider and model management

What Nyvero could do: it currently has a single hardcoded DEEPSEEK_* env config. Add a providers config with named base URLs and keys, a nyvero models / nyvero model switch, and somewhere to store credentials. That also fixes the provider lock-in.

providers = {"deepseek": {...}, "local": {"base_url": "http://localhost:11434"}}

None of this is a roadmap I'm driving. It's just what I'd reach for next if I kept going. Take the smallest slice that's useful to you, keep the core readable, and open a PR when it works. That's the whole ask.