[Feature] Route PAL tool model calls through clink via clink/{cli}__{model} syntax

[ramarivera]

Summary

Enable PAL workflow tools (consensus, codereview, thinkdeep, debug, etc.) to route model calls through clink subagents by supporting a model identifier syntax like clink/claude__claude-sonnet-4-5 or clink/codex__gpt-5-2-codex-medium.

This would combine the structured workflows of PAL tools with clink's context isolation and token efficiency benefits, while letting users specify exactly which model the spawned CLI should use.

Motivation

Current State

• PAL tools (consensus, codereview, etc.) call models directly via provider APIs, consuming tokens in the current context
• clink spawns isolated CLI subagents that return only final results, preserving the main session's context budget
• To get both benefits today, users must manually chain: pal_consensus → pal_clink with continuation
• There's no way to tell a PAL tool "use this model, but route it through an isolated CLI"

Proposed Enhancement

Allow PAL tools to accept model identifiers that route through clink with a specific model:

# Current: direct API call, tokens consumed in main context
pal_consensus(models=[{"model": "gemini-pro"}, {"model": "gpt-5"}])

# Proposed: route through clink CLIs, each using specified model
pal_consensus(models=[
    {"model": "clink/gemini__gemini-3-pro"},           # Gemini CLI using Gemini 3 Pro
    {"model": "clink/codex__gpt-5-2-codex-medium"}    # Codex CLI using GPT-5.2 Codex Medium
])

Benefits

1. Token efficiency - Each model consultation runs in an isolated CLI context; only final responses return to the host session
2. Extended capabilities - CLI subagents can use their native tools (web search, file access, MCP servers) during PAL workflows
3. Model flexibility - Specify exactly which model each CLI should use, not just the CLI itself
4. Unified interface - Users get PAL's structured workflows without choosing between "PAL tools" vs "clink delegation"
5. Context preservation - Main session stays focused while complex analysis happens in subagent contexts

Proposed Syntax

clink/{cli_name}__{model_identifier}

Components:
- clink/          → Prefix indicating clink routing
- {cli_name}      → Target CLI: gemini, claude, codex, etc.
- __              → Double underscore delimiter
- {model_id}      → Model the CLI should use (CLI-specific format)

Examples:
- clink/claude__claude-sonnet-4-5         → Claude Code with Sonnet 4.5
- clink/claude__claude-opus-4             → Claude Code with Opus 4
- clink/codex__gpt-5-2-codex-medium       → Codex CLI with GPT-5.2 Codex Medium
- clink/codex__gpt-5-2-pro                → Codex CLI with GPT-5.2 Pro
- clink/gemini__gemini-3-pro              → Gemini CLI with Gemini 3 Pro
- clink/gemini__gemini-2-5-flash          → Gemini CLI with Gemini 2.5 Flash

The double underscore (__) disambiguates from model names that might contain single underscores or hyphens.

Example Use Cases

Multi-CLI Consensus with Specific Models

Use consensus with clink/claude__claude-sonnet-4-5 and clink/codex__gpt-5-2-pro 
to evaluate whether we should use Redis or PostgreSQL for session storage

Each CLI runs in isolation with its specified model, performs analysis with access to its native tools, returns only the final verdict.

Code Review via Isolated CLI

pal_codereview(
    model="clink/gemini__gemini-3-pro",
    relevant_files=["/path/to/auth/"]
)

Gemini CLI spawns with Gemini 3 Pro, can use web search for current security advisories, returns structured review without consuming host context.

Thinkdeep with Extended Context Window

pal_thinkdeep(
    model="clink/gemini__gemini-3-pro",  # 1M context window
    problem_context="Analyze cross-cutting concerns in this monorepo..."
)

Leverage Gemini's massive context window via CLI isolation.

Precommit with Different Models

pal_precommit(
    model="clink/codex__gpt-5-2-codex-medium",
    path="/repo/root"
)

Codex CLI validates changes using its native git diff capabilities.

Implementation Considerations

1. Model string parsing - Detect clink/ prefix, split on __ to extract CLI name and model
2. CLI model flags - Map to CLI-specific model arguments:
   • Claude: --model claude-sonnet-4-5
   • Codex: Model specified in config or env
   • Gemini: --model gemini-3-pro
3. Role handling - Could extend syntax to clink/{cli}__{model}__{role} or default to default role
4. Existing clink infrastructure - Leverage conf/cli_clients/ configs and role prompts
5. Error handling - Graceful failures when CLI not installed or model not available
6. Response parsing - Ensure CLI output formats work with PAL tool expectations

Open Questions

1. Should role be part of the syntax (clink/gemini__gemini-3-pro__codereviewer) or a separate parameter?
2. How to handle CLI-specific model naming conventions?
3. Should there be validation that the specified model is available for that CLI?

Alternatives Considered

1. Manual chaining - Current approach; works but requires user orchestration and loses structured workflow benefits
2. Separate parameter - e.g., route_via_clink="gemini", clink_model="gemini-3-pro"; more verbose
3. Only CLI, no model - e.g., clink/gemini; less control over which model the CLI uses

---

Note: Similar issues were searched before filing. This report was created with AI assistance.

[ramarivera]

cc @guidedways :) (also merry xmas if you celebrate!)