FM-Agent tackles a hard problem: extending Hoare-style reasoning from small programs to whole systems — generating per-function specs, reasoning against them without human input, and reporting bugs with reproduction probes, demonstrated on codebases the size of Claude's C Compiler (143K LoC). Six stages run over a git repo and write a browsable report.html, which makes system-scale correctness checking feel routine rather than a research exercise.
That work leans hard on the model behind it — your README states that weaker models hallucinate and skew verdicts, and recommends strong reasoning models. Model choice decides whether a specification is trustworthy. FM-Agent already treats providers as pluggable (fm-agent.toml [llm] with provider/base_url/api_style, plus the OpenCode provider block the wizard generates), which is where OrcaRouter could add a concrete option for your users.
I'm an engineer on the OrcaRouter team. I'd like to propose OrcaRouter as an additional, optional provider for FM-Agent. It would not replace or change any existing provider — OpenRouter, the CLI backends, and the direct reasoner client would all keep working exactly as they do today.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it maps onto the abstractions FM-Agent already has: a base_url plus LLM_API_KEY for the direct reasoner client, and an OpenCode provider entry using the @ai-sdk/openai-compatible adapter via api_style = "openai". I have not written or tested any code for this; this is a proposal only.
Four capabilities seem genuinely relevant here:
- One endpoint for many reasoning models. FM-Agent's output quality depends on picking a strong reasoner per stage; a single endpoint turns that into a config change in
fm-agent.toml.
- Automatic routing and provider failover. FM-Agent runs LLMs concurrently (
max_workers = 10) and your docs already note rate-limit pressure; failover keeps long runs from dying on a single upstream 429 or 5xx.
- Prompt caching. Your dashboard already reports prompt-cache hit rate and
llm_client.py uses cache_control/ephemeral markers, so cache-friendly routing has a measurable payoff.
- Usage tracking and budgets. This pairs with
--estimate and history.jsonl, letting users cap token and cost spend across large codebases.
OrcaRouter has already appeared in the open-source ecosystem alongside projects such as OpenCode / models.dev, Dify, and RAGFlow.
For transparency: OrcaRouter runs an optional open-source partner program where approved projects can receive a 5% revenue share from usage attributed to their integration. Joining is not a prerequisite for integrating — I'm raising it as a disclosure, and I'm glad to follow whatever disclosure or governance rules this project has.
More detail: https://www.orcarouter.ai/built-with
Would you be open to OrcaRouter as an optional provider? If the direction sounds reasonable, I'd be happy to prepare an implementation PR covering fm-agent.toml, the config wizard, and the docs, and to match your existing provider conventions.
FM-Agent tackles a hard problem: extending Hoare-style reasoning from small programs to whole systems — generating per-function specs, reasoning against them without human input, and reporting bugs with reproduction probes, demonstrated on codebases the size of Claude's C Compiler (143K LoC). Six stages run over a git repo and write a browsable
report.html, which makes system-scale correctness checking feel routine rather than a research exercise.That work leans hard on the model behind it — your README states that weaker models hallucinate and skew verdicts, and recommends strong reasoning models. Model choice decides whether a specification is trustworthy. FM-Agent already treats providers as pluggable (
fm-agent.toml[llm]withprovider/base_url/api_style, plus the OpenCode provider block the wizard generates), which is where OrcaRouter could add a concrete option for your users.I'm an engineer on the OrcaRouter team. I'd like to propose OrcaRouter as an additional, optional provider for FM-Agent. It would not replace or change any existing provider — OpenRouter, the CLI backends, and the direct reasoner client would all keep working exactly as they do today.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it maps onto the abstractions FM-Agent already has: a
base_urlplusLLM_API_KEYfor the direct reasoner client, and an OpenCode provider entry using the@ai-sdk/openai-compatibleadapter viaapi_style = "openai". I have not written or tested any code for this; this is a proposal only.Four capabilities seem genuinely relevant here:
fm-agent.toml.max_workers = 10) and your docs already note rate-limit pressure; failover keeps long runs from dying on a single upstream 429 or 5xx.llm_client.pyusescache_control/ephemeral markers, so cache-friendly routing has a measurable payoff.--estimateandhistory.jsonl, letting users cap token and cost spend across large codebases.OrcaRouter has already appeared in the open-source ecosystem alongside projects such as OpenCode / models.dev, Dify, and RAGFlow.
For transparency: OrcaRouter runs an optional open-source partner program where approved projects can receive a 5% revenue share from usage attributed to their integration. Joining is not a prerequisite for integrating — I'm raising it as a disclosure, and I'm glad to follow whatever disclosure or governance rules this project has.
More detail: https://www.orcarouter.ai/built-with
Would you be open to OrcaRouter as an optional provider? If the direction sounds reasonable, I'd be happy to prepare an implementation PR covering
fm-agent.toml, the config wizard, and the docs, and to match your existing provider conventions.