Why this fits altimate-code
altimate-code is the open-source data engineering harness that gives any LLM a deterministic intelligence layer for dbt, SQL, and cloud warehouses. Instead of letting a general coding agent guess at schema, it provides 100+ deterministic tools including SQL anti-pattern detection, column-level lineage, and cross-dialect data parity, so data engineers get answers they can trust across Snowflake, BigQuery, Databricks, and Redshift.
That model-agnostic design is central to how teams run it: altimate supports 35+ providers through a provider/model-name config, and its docs recommend pairing an inexpensive model for the read-only Analyst agent with a stronger one for Builder. Offering another provider gives those teams more control over model availability, cost, and latency without leaving the workflow they use every day.
Proposal
I'm an engineer on the OrcaRouter team. I'd like to propose adding OrcaRouter as an optional provider for altimate-code, sitting alongside existing providers without replacing or changing any of them. It would follow the same shape as the OpenRouter and other OpenAI-compatible entries already in the repo.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, which maps cleanly onto altimate's provider config (provider.<name> with apiKey and baseURL). Since CONTRIBUTING says new providers need little or no code and should first be added to the models.dev catalog altimate already reads, the likely integration point is the shared catalog plus an OpenAI-compatible provider entry pointing at OrcaRouter's base URL. This is a proposal for maintainers to evaluate; nothing is implemented or tested yet.
Capabilities that would matter to data teams:
- Broad model access through one endpoint: chat, reasoning, and image models from many upstreams behind a single API, so Analyst and Builder agents can each pick an appropriate model without juggling multiple API keys.
- Automatic routing and provider failover: keeps long-running SQL analysis and dbt generation jobs from stalling when one upstream provider has an outage.
- Usage tracking and budgets: per-team visibility that fits the FinOps mindset altimate already brings to warehouse cost analysis.
OrcaRouter also supports prompt caching, which suits the repeated schema and lineage context these sessions carry. It is already in use across the open-source ecosystem (for example RAGFlow and Dify, and it fits naturally alongside the models.dev/OpenCode catalog projects).
Full transparency: OrcaRouter runs an optional open-source partner program where approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for integrating, and I would follow any disclosure or governance requirements altimate-code prefers.
Other projects built with OrcaRouter are listed at https://www.orcarouter.ai/built-with. I would welcome maintainers' thoughts, and if useful I am glad to submit an implementation PR once approved.
Why this fits altimate-code
altimate-code is the open-source data engineering harness that gives any LLM a deterministic intelligence layer for dbt, SQL, and cloud warehouses. Instead of letting a general coding agent guess at schema, it provides 100+ deterministic tools including SQL anti-pattern detection, column-level lineage, and cross-dialect data parity, so data engineers get answers they can trust across Snowflake, BigQuery, Databricks, and Redshift.
That model-agnostic design is central to how teams run it: altimate supports 35+ providers through a
provider/model-nameconfig, and its docs recommend pairing an inexpensive model for the read-only Analyst agent with a stronger one for Builder. Offering another provider gives those teams more control over model availability, cost, and latency without leaving the workflow they use every day.Proposal
I'm an engineer on the OrcaRouter team. I'd like to propose adding OrcaRouter as an optional provider for altimate-code, sitting alongside existing providers without replacing or changing any of them. It would follow the same shape as the OpenRouter and other OpenAI-compatible entries already in the repo.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, which maps cleanly onto altimate's provider config (
provider.<name>withapiKeyandbaseURL). Since CONTRIBUTING says new providers need little or no code and should first be added to the models.dev catalog altimate already reads, the likely integration point is the shared catalog plus an OpenAI-compatible provider entry pointing at OrcaRouter's base URL. This is a proposal for maintainers to evaluate; nothing is implemented or tested yet.Capabilities that would matter to data teams:
OrcaRouter also supports prompt caching, which suits the repeated schema and lineage context these sessions carry. It is already in use across the open-source ecosystem (for example RAGFlow and Dify, and it fits naturally alongside the models.dev/OpenCode catalog projects).
Full transparency: OrcaRouter runs an optional open-source partner program where approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for integrating, and I would follow any disclosure or governance requirements altimate-code prefers.
Other projects built with OrcaRouter are listed at https://www.orcarouter.ai/built-with. I would welcome maintainers' thoughts, and if useful I am glad to submit an implementation PR once approved.