Use the right model without losing the work

Axis uses model access you connect through the installed runtime. Provider catalog, authentication methods, model references, effort levels, limits, and availability come from that live capability state—not from a permanent marketing list.

Choose access around the task

Connect another provider when its available models, modality, latency, context, or reasoning profile better fits the work. Switch within the same session when the outcome is unchanged; start a new session only for a new goal.

Direct proof: Verify a provider in Axis, switch the model from the composer, and continue the exact same session. The transcript, draft, queue, and durable identity should remain attached while the model reference changes.

What changes in practice

1. Choice by task. Use the available model that fits the slice rather than one global default.
2. Session continuity. Provider changes do not require rebuilding the conversation.
3. Explicit failure. Expiry, limits, and outages remain actionable states instead of silent rerouting.

Mission: verify and switch one provider

1. Open the current provider setup offered by Axis.
2. Connect through its supported authorization or credential method.
3. Run the built-in verification rather than trusting a saved credential.
4. Select the exact available model and effort for the next instruction.
5. Confirm the same session continues and handle any provider failure explicitly.

Treat live provider state as authority

A logged-in standalone CLI does not always authorize Axis. Never put keys or tokens in project files, prompts, Routines, screenshots, or documentation. Provider privacy, cost, latency, context, rate limits, and model availability depend on the provider and account. Axis should not present one universal model recommendation as permanent truth.

Related references

• Track AI costs
• Sub-agents
• Configuration
• Troubleshooting

Put this to work: Choose models deliberately for independent sub-agent slices.