OrcaRouter provider support for Simply (Amplio and simply/agent)

Simply's framing — a minimal JAX codebase where humans and AI agents iterate together on frontier LLM research — is backed by concrete choices: minimal abstractions and dependencies, and Amplio, a vendored Go agent harness with DB-first persistence so a long-horizon run resumes after a crash instead of restarting. That resume property is what makes the README's unattended multi-round experiment loops practical to trust.

Model access is already pluggable: Amplio resolves a provider spec string and its `openai:` provider reaches any OpenAI-compatible `/v1/chat/completions` endpoint via `base_url`, with `api_key_env` naming the key so several endpoints coexist without secrets in `config.toml`; `simply/agent/` does the same through LiteLLM. OrcaRouter is a natural extra endpoint for researchers who want one key across many models.

## What I'm proposing

I'm an engineer on the OrcaRouter team. I'd like to propose [OrcaRouter](https://www.orcarouter.ai) as an *optional, additive* provider for Simply — one more spec/endpoint choice alongside the existing ones, not a replacement for any provider, default, or code path. Current Vertex, Claude, Gemini, OpenAI, and LiteLLM configurations would not change.

OrcaRouter exposes an OpenAI-compatible API at `https://api.orcarouter.ai/v1` and uses standard API-key authentication. Since Amplio's `openai:` provider already accepts `base_url` plus `api_key_env`, the expected integration point is just a spec of this shape:

```
openai{base_url=https://api.orcarouter.ai/v1&api_key_env=ORCAROUTER_API_KEY}:
```

with an equivalent route from `simply/agent/` through LiteLLM. I haven't written or tested any of this — it's a proposal, and I'd want your read on the right shape first.

## Capabilities that seem relevant here

Three items line up with long unattended runs rather than a generic feature list:

- **Automatic model routing and provider failover** — if an upstream rate-limits or errors mid-run, the request can fail over instead of killing a run Amplio was built to resume.
- **Usage tracking and budgets** — per-run spend visibility and caps matter when an agent works through many experiments unattended.
- **Multiple chat/reasoning models behind one endpoint** — a spec can pick among models without a separate key and config block per vendor.

(Prompt caching is also available; I note it only because Amplio already surfaces `cache_ttl`.)

## Ecosystem and disclosure

OrcaRouter already appears in open-source agent and eval tooling such as goose, promptfoo, and CAMEL. Details: https://www.orcarouter.ai/built-with

For transparency: we run an **optional** open-source partner program in which approved projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participating is not a prerequisite, and I'm glad to follow whatever disclosure or governance requirements Simply has.

Would you be open to this as an optional provider? If useful, I'm happy to prepare an implementation PR once you've weighed in.

Start by reading the provider-spec handling in Amplio and the integration path under simply/agent/, including the existing OpenAI-compatible configuration described in the issue. Done means maintainer agreement on the optional OrcaRouter provider shape, an implementation covering both routes if approved, and confirmation that existing provider configurations remain unchanged.

Written by the indexing model from the issue text.