optim-agent automates the iterative parameter-tuning work of an algorithm engineer by driving Claude Code, Codex, or OpenCode as the sampler. Instead of treating every search dimension as an anonymous coordinate, the agent reasons over parameter meaning and trial history, then proposes the next configuration - a design aimed at expensive evaluations with small trial budgets, where classical surrogates such as TPE are still data-starved.
That is why model choice matters here: proposal quality rides on the underlying model. Your published runs show context-aware GPT-5.5 proposals cutting cumulative best-so-far error by about 21% over TPE on MNIST, and your roadmap openly tracks token cost and provider variance. More model options, with clearer control over provider cost and uptime, serve the budget-conscious users optim-agent targets.
Problem
optim-agent reaches many models through its three backend CLIs, but each model family still needs its own provider account and key - see the ~/.claude/settings-kimi.json routing in the hard-function benchmark. When a provider is down or rate-limited, that trial's agent call fails and the study falls back to random sampling.
Proposed solution
I'd like to propose OrcaRouter as an optional model provider for an already-supported backend. It would not replace or alter any existing provider. I'm an engineer on the OrcaRouter team.
Capabilities most relevant here:
- Many chat and reasoning models through one endpoint, selectable via the existing
model= argument on AgentSampler, letting users compare proposers across model families without a separate account per provider.
- Automatic model routing and provider failover, so an outage or rate limit retries another provider instead of forcing a random fallback trial.
- Usage tracking and budgets, matching the operating-cost discipline in your examples and roadmap.
Integration point: OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. optim-agent's core abstraction is a backend (an agent CLI such as claude, codex, or opencode) plus a model string passed to that CLI; provider endpoint and auth live in each CLI's own configuration, outside optim_agent. The clean seam is an optional provider endpoint a user configures for one of those backends, making router-hosted models selectable without touching existing providers. This is a proposal only - nothing is implemented or tested - and any package-level change would follow the one-function-per-backend pattern in optim_agent/agent.py.
OrcaRouter is already integrated into open-source tools such as models.dev/OpenCode and RAGFlow, with community integrations listed at https://www.orcarouter.ai/built-with.
Transparency: OrcaRouter offers an optional open-source partner program in which approved OSS projects receive a 5% revenue share from usage attributed to their integration. Participation is not required, and I will respect optim-agent's disclosure and governance expectations either way.
Would the maintainers be open to this direction? If so, I'd be glad to submit an implementation PR once approved.
optim-agent automates the iterative parameter-tuning work of an algorithm engineer by driving Claude Code, Codex, or OpenCode as the sampler. Instead of treating every search dimension as an anonymous coordinate, the agent reasons over parameter meaning and trial history, then proposes the next configuration - a design aimed at expensive evaluations with small trial budgets, where classical surrogates such as TPE are still data-starved.
That is why model choice matters here: proposal quality rides on the underlying model. Your published runs show context-aware GPT-5.5 proposals cutting cumulative best-so-far error by about 21% over TPE on MNIST, and your roadmap openly tracks token cost and provider variance. More model options, with clearer control over provider cost and uptime, serve the budget-conscious users optim-agent targets.
Problem
optim-agent reaches many models through its three backend CLIs, but each model family still needs its own provider account and key - see the
~/.claude/settings-kimi.jsonrouting in the hard-function benchmark. When a provider is down or rate-limited, that trial's agent call fails and the study falls back to random sampling.Proposed solution
I'd like to propose OrcaRouter as an optional model provider for an already-supported backend. It would not replace or alter any existing provider. I'm an engineer on the OrcaRouter team.
Capabilities most relevant here:
model=argument onAgentSampler, letting users compare proposers across model families without a separate account per provider.Integration point: OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. optim-agent's core abstraction is a backend (an agent CLI such as
claude,codex, oropencode) plus amodelstring passed to that CLI; provider endpoint and auth live in each CLI's own configuration, outsideoptim_agent. The clean seam is an optional provider endpoint a user configures for one of those backends, making router-hosted models selectable without touching existing providers. This is a proposal only - nothing is implemented or tested - and any package-level change would follow the one-function-per-backend pattern inoptim_agent/agent.py.OrcaRouter is already integrated into open-source tools such as models.dev/OpenCode and RAGFlow, with community integrations listed at https://www.orcarouter.ai/built-with.
Transparency: OrcaRouter offers an optional open-source partner program in which approved OSS projects receive a 5% revenue share from usage attributed to their integration. Participation is not required, and I will respect optim-agent's disclosure and governance expectations either way.
Would the maintainers be open to this direction? If so, I'd be glad to submit an implementation PR once approved.