PAL-BUG-1: `pal__planner` is orchestration-only — no upstream model call is made

Author: primovera12Created May 25, 2026Updated May 25, 2026

Reporter: [email protected] (via Claude Code multi-week /eval-models routing review) First observed: 2026-W22 (2026-05-25, reported in private routing review 2026-W22.md F2) Reproduced with definitive log evidence: 2026-W23 (2026-05-25 15:38:07Z) Repo: BeehiveInnovations/pal-mcp-server @ branch main

TL;DR

pal__planner accepts a model parameter, signals success, returns a "plan," but never calls an upstream OpenRouter model. The returned step_content is the user's own input prompt echoed back. provider_used is hardcoded to "unknown".

This is silent failure — the caller has no way to know the model was never invoked unless they inspect PAL's log file directly.

Reproduction

python
mcp_call(
  tool="pal__planner",
  step="Break the attached spec into a numbered implementation plan...",
  step_number=1,
  total_steps=1,
  next_step_required=False,
  model="google/gemini-2.5-pro",
)

Response (truncated to relevant fields)

json
{
  "status": "planning_complete",
  "metadata": {
    "tool_name": "planner",
    "model_used": "google/gemini-2.5-pro",
    "provider_used": "unknown"
  },
  "step_content": "<verbatim echo of user's input prompt>",
  ...
}

PAL server log evidence (logs/mcp_server.log)

2026-05-25 15:38:07,993 - __main__ - INFO - MCP tool call: planner
2026-05-25 15:38:07,994 - mcp_activity - INFO - TOOL_CALL: planner with 5 arguments
2026-05-25 15:38:07,994 - __main__ - INFO - Executing tool 'planner' with 5 parameter(s)
2026-05-25 15:38:07,994 - __main__ - DEBUG - Initial model for planner: google/gemini-2.5-pro
2026-05-25 15:38:07,995 - __main__ - DEBUG - Tool planner doesn't require model resolution - skipping model validation
2026-05-25 15:38:07,997 - tools.workflow.workflow_mixin - DEBUG - [WORKFLOW_FILES] planner: Embedding files for final step/expert analysis
2026-05-25 15:38:07,997 - tools.workflow.workflow_mixin - DEBUG - [WORKFLOW_FILES] planner: No relevant_files to embed
2026-05-25 15:38:07,998 - tools.workflow.workflow_mixin - DEBUG - [WORKFLOW_METADATA] planner: Added fallback metadata - model: google/gemini-2.5-pro, provider: unknown

Key signals:

  • Tool planner doesn't require model resolution - skipping model validation — confirms the planner code path explicitly opts out of model resolution.
  • Added fallback metadata - model: google/gemini-2.5-pro, provider: unknown — the model name is preserved in metadata for telemetry, but no upstream provider call follows.
  • Zero OpenRouter X-Generation-Id headers in the post-tool-call log window — no HTTP request was made to OpenRouter.

Suspected cause

Looking at tools/workflow/workflow_mixin.py flow: planner's requires_model returns False (or equivalent), which causes the workflow to skip both model validation and the upstream call, but still return a synthetic completion.

The intent may have been for planner to act as an orchestrator that breaks complex plans across multiple steps via continuation_id. However, the public API contract (the model parameter) misleadingly suggests a model IS invoked per step.

Impact

For users running PAL via the /eval-models or /router-weekly cadence:

  • Costs are silently zero for planner (which can mislead "free tool" assumptions)
  • Quality measurements via planner are meaningless (the model is never invoked)
  • Bills don't match expected per-tool cost projections

Workaround: re-route planner prompts via pal__chat with the same model argument + the planner system-prompt-modifier prepended. This actually invokes the model.

Suggested fixes (pick one)

  1. Make planner actually call the model. Use the same provider-resolution + HTTP-call path that pal__chat uses, with the planner system-prompt as the user prompt. The orchestration / continuation_id semantics stay; only the upstream call is added.
  2. OR remove the model parameter from pal__planner and document the tool as "orchestration only — caller is responsible for invoking models via other tools per planning step." This is honest about current behavior.

Option 1 is what users expect from the parameter signature.

Cross-references

  • W22 routing review: ~/.claude/openrouter-models/results/2026-W22.md F2 table row
  • W23 routing review: ~/.claude/openrouter-models/results/2026-W23.md Section B (PAL-BUG-1)
  • Reproduction gen-id sequence: no gen-id produced (the bug IS the absence of a gen-id)

Source: BeehiveInnovations/pal-mcp-server