Different agents, different models
Use a focused model for a narrow builder and a larger model for a coordinator or difficult repository task.
Add one provider credential, then assign any model identifier available to your OpenRouter account to the configured agents that work inside your Sessions.
Export OPENROUTER_API_KEY and OPENROUTER_MODEL in the process environment that starts Axocoatl, then reference them from axocoatl.yaml. Axocoatl does not load dotenv files automatically; if you keep assignments in a local .env, explicitly source it before starting the workbench.
Set provider: openrouter on the agents that should use it. Model availability, pricing, routing, and account access are controlled by OpenRouter, so use a model identifier currently available to your account.
providers:
openrouter:
api_key: "${OPENROUTER_API_KEY}"
agents:
- id: builder
provider: openrouter
model: "${OPENROUTER_MODEL}"Agents are configuration records. Assign OpenRouter, a direct hosted provider, or Ollama to each role, then select the right Agent from the Session.
Use a focused model for a narrow builder and a larger model for a coordinator or difficult repository task.
Keep one Agent on Ollama and another on OpenRouter. Optional Ways can compare configured agents when the decision merits it.
Within Ways, when remote pricing is not configured, Axocoatl marks the known subtotal as incomplete instead of treating the call as free.
Select OpenRouter when axocoatl onboard asks for a provider. It writes the provider and Agent structure and can place a supplied key in .env.example. Move that populated file out of its template name, restrict it, and explicitly source it before starting Axocoatl; renaming the file alone does not load it.
Calls to the OpenRouter endpoint include HTTP-Referer: https://axocoatl.ai and X-Title: Axocoatl. These headers identify the calling application. They do not imply a directory listing, rank, partnership, or endorsement.
Run axocoatl doctor after setup and start the local workbench with axocoatl dev.