Custom droid glm-5.2 pin intermittently falls back to GPT-5.6 Sol

[OliverGeorge8]

Summary

A project custom droid pinned to the native glm-5.2 model intermittently ignored its model pin and ran on the parent session's gpt-5.6-sol model instead.

The failure was session-scoped: three parallel invocations from the same Spec Mode parent all used Sol, while equivalent invocations before and afterward correctly used GLM.

Configuration

.factory/droids/code-sweeper.md:

---
name: code-sweeper
model: glm-5.2
reasoningEffort: high
tools: ["Read", "LS", "Grep", "Glob", "Execute"]
mcpServers: []
---

Parent session:

• Model: gpt-5.6-sol
• Reasoning effort: medium
• Interaction mode: Spec
• Task complexity: medium

Observed behavior

Three Task calls using subagent_type: code-sweeper from one parent session ran with:

• Runtime system context: Model: GPT-5.6 Sol
• Assistant transcript metadata: modelId: gpt-5.6-sol, reasoningEffort: medium

This happened for all three parallel children.

The children therefore inherited the parent model despite the explicit model: glm-5.2 droid pin.

There is also a metadata inconsistency: the child .settings.json files later reported model: gpt-5.2 / reasoningEffort: high, while every assistant message in their transcripts recorded modelId: gpt-5.6-sol / reasoningEffort: medium.

Expected behavior

The explicit custom-droid model pin should take precedence over task complexity routing and the parent model, so every code-sweeper invocation should use glm-5.2 with high reasoning.

If validation rejects the pin, Droid should expose the reason rather than silently falling back.

Reproduction characteristics

The behavior is intermittent or session-scoped:

1. Start a Spec Mode parent on gpt-5.6-sol.
2. Define a project droid pinned to native glm-5.2.
3. Launch several parallel Task calls with that droid and complexity: medium.
4. Inspect each child transcript's runtime model and assistant modelId.

In the affected session, all three children used Sol. In fresh sessions, the same droid with complexity: medium correctly resolves to GLM, so complexity alone is not sufficient to trigger it.

Environment

• Droid CLI: 0.187.0
• OS: macOS Darwin 25.5.0
• Project droid location: .factory/droids/code-sweeper.md
• Pinned model: native Droid Core glm-5.2
• Parent model: gpt-5.6-sol

Impact

This can unexpectedly run broad read-heavy exploration on an expensive parent model. Because the fallback is silent and session metadata can disagree with transcript metadata, cost and model attribution are difficult to trust.

Requested improvements

1. Honor valid native model pins independently of the parent model.
2. Log the resolved custom-droid model and any fallback reason to FACTORY_LOG_FILE.
3. Keep child settings metadata consistent with the model actually used for messages.