How Multi-Provider Auto-Routing Distributes Council Members Across LLM Providers in council-of-high-intelligence

The council's auto-routing mechanism automatically detects available LLM providers and distributes the 18 historical personas across them, ensuring polarity-pairs run on different backends to guarantee genuine model diversity.

The 0xNyk/council-of-high-intelligence repository implements an intelligent load-balancing system that eliminates manual provider configuration. By leveraging multi-provider auto-routing, the council ensures that each historical persona executes on a distinct LLM backend, creating genuine cognitive diversity during deliberations. This approach prevents echo chambers by forcing opposing viewpoints onto different model families.

Provider Detection and Supported Backends

When the /council command runs without explicit --models or --no-auto-route flags, the coordinator executes environment detection to discover available providers.

The Detection Script

The system relies on scripts/detect-providers.sh to inspect the host environment for supported provider installations. This script queries the system for CLI tools, API keys, and running services to build a real-time inventory of available backends.

Supported Provider Matrix

The auto-router recognizes six distinct backends, each with specific detection methods and execution strategies:

Provider	Detection Method	Execution Method
Anthropic (Claude)	Native	Sub-agent (always available)
OpenAI	codex CLI	codex exec
Google Gemini	gemini CLI	gemini -p
Ollama	ollama CLI	ollama run
NVIDIA NIM	NVIDIA_API_KEY env	OpenAI-compatible API
Cursor	cursor-agent CLI	cursor-agent -p

According to the source in README.md (lines 196-213), this detection happens automatically unless explicitly disabled.

The Three-Step Routing Algorithm

After provider enumeration, the router applies a deterministic algorithm described in STEP 1 of SKILL.md (lines 79-102). This algorithm balances load while enforcing architectural constraints.

Polarity-Pair Separation (Hard Constraint)

The router treats opposing viewpoints as incompatible with shared infrastructure. Any two members forming a polarity pair—such as Socrates versus Feynman—receive mandatory placement on different providers. This hard constraint prevents similar model biases from neutralizing opposing perspectives (see SKILL.md lines 197-199).

Provider Spread Calculation

With N detected providers and M council members (typically 18), the algorithm distributes members as evenly as possible. Each provider receives either ⌊M/N⌋ or ⌈M/N⌉ members.

Aggregator handling introduces nuance: services like NVIDIA NIM and Cursor count as single providers for spread calculations, while the models within them contribute intra-provider diversity. This design prevents over-concentration on single endpoints while respecting the practical reality of aggregator services (SKILL.md lines 199-200).

Provider Affinity Tie-Breaking

When multiple providers offer equal capacity, the router consults each member's front-matter configuration. The provider_affinity array specifies preferred providers in priority order. The system avoids assigning members to NVIDIA NIM unless no other provider has available capacity, reflecting a soft preference for direct API access over aggregator layers (SKILL.md lines 188-190).

Execution Fallbacks and User Controls

Automatic Fallback to Claude

If a provider fails during council execution, the router automatically migrates the affected member to Anthropic Claude. This guarantees council completion even when secondary providers experience outages (README.md lines 221-223).

Overriding Auto-Routing

Users retain granular control through three explicit flags:

• --no-auto-route: Forces Claude-only execution, bypassing detection entirely
• --dry-route: Prints the computed routing table without launching the council, enabling inspection before execution
• --models <path>: Supplies an explicit YAML mapping via configs/provider-model-slots.example.yaml, completely bypassing auto-routing logic (SKILL.md lines 35-38)

Code Examples and Configuration

Basic invocation automatically applies multi-provider auto-routing:

# Standard execution with auto-routing

/council --triad decision "Should we accept the acquisition offer?"

Inspect the routing plan before execution:

# Preview distribution without running

/council --dry-route --triad decision "Should we accept the acquisition offer?"

Force Claude-only mode:

# Disable multi-provider distribution

/council --no-auto-route --triad decision "Should we accept the acquisition offer?"

For manual configuration, create a YAML file following the structure in configs/provider-model-slots.example.yaml and pass it via --models.

Summary

• Automatic detection via scripts/detect-providers.sh identifies six supported providers without manual configuration
• Polarity-pair separation guarantees opposing viewpoints execute on different LLM backends
• Even distribution ensures balanced load across providers using floor/ceiling mathematics
• Provider affinity respects member preferences defined in front-matter while avoiding NIM aggregation when possible
• Automatic fallback to Claude maintains council resilience against provider outages
• Override flags (--dry-route, --no-auto-route, --models) provide complete user control when needed

Frequently Asked Questions

What happens if no providers are detected?

If scripts/detect-providers.sh finds no alternative providers, the system defaults to Anthropic Claude for all council members. This ensures the council always functions regardless of environment configuration, though without the benefits of multi-provider diversity.

How does the router handle aggregator services like NVIDIA NIM?

Aggregators such as NVIDIA NIM and Cursor count as single providers for spread calculations, but their internal model diversity adds value within that single slot. The router avoids NIM assignment unless no other provider has capacity, preferring direct API connections where available.

Can I force specific council members to use specific providers?

Yes. While multi-provider auto-routing handles distribution automatically, you can bypass it entirely using the --models flag with a custom YAML file. Alternatively, modify each member's front-matter to include a provider_affinity array, which the router consults as a soft tie-breaker when capacity allows.

What is the difference between --dry-route and --no-auto-route?

The --dry-route flag computes and displays the routing table using the normal auto-routing algorithm without executing the council, letting you preview the distribution. The --no-auto-route flag disables auto-routing entirely, forcing all members onto Claude and ignoring detected providers.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}