What happened
When a workflow sets max-ai-credits and takes its engine.model from an
imported file, the compiler silently discards the pin. The generated lock falls
back to repository variables:
COPILOT_MODEL: ${{ vars.GH_AW_MODEL_AGENT_COPILOT || vars.GH_AW_DEFAULT_MODEL_COPILOT || 'claude-sonnet-4.6' }}
Compilation reports 0 error(s), 0 warning(s), so nothing signals that the
workflow is no longer pinned. In a consumer repo that has not set those
variables, the run quietly executes on claude-sonnet-4.6 instead of the model
the author selected.
Either combination on its own is fine — the pin only disappears when both are
present.
Reproduction (v0.82.13)
.github/workflows/shared/model.md:
---
engine:
id: copilot
model: gpt-5.6-sol
---
.github/workflows/probe.md:
---
name: Probe
on:
workflow_dispatch:
permissions: read-all
max-ai-credits: 1500
imports:
- shared/model.md
safe-outputs:
add-comment:
max: 1
---
# Probe
Say hello.
$ gh aw compile probe
✓ probe.md
✓ Compiled 1 workflow(s): 0 error(s), 0 warning(s)
$ grep 'GH_AW_INFO_MODEL:' probe.lock.yml
GH_AW_INFO_MODEL: ${{ vars.GH_AW_MODEL_AGENT_COPILOT || vars.GH_AW_DEFAULT_MODEL_COPILOT || 'claude-sonnet-4.6' }}
max-ai-credits |
engine.model from |
Resolved model in lock |
| absent |
import |
gpt-5.6-sol ✅ |
| absent |
inline |
gpt-5.6-sol ✅ |
1500 |
inline |
gpt-5.6-sol ✅ |
1500 |
import |
repository-variable fallback ❌ |
Expected
An imported engine.model should resolve identically to an inline one. If some
combination genuinely cannot be supported, the compiler should fail rather than
emit a workflow whose model pin has silently disappeared.
Why this matters
Sharing engine: through an import is the only way to define a model default in
one place: gh-aw permits exactly one engine: across a workflow and all of its
imports, so an importing workflow cannot restate the pin as a safety net. A
catalogue of workflows that centralises its model pin this way loses the pin on
exactly the workflows that also cap their spend — and finds out at runtime.
Environment
- gh-aw
v0.82.13
- engine
copilot, CLI 1.0.70
What happened
When a workflow sets
max-ai-creditsand takes itsengine.modelfrom animported file, the compiler silently discards the pin. The generated lock falls
back to repository variables:
Compilation reports
0 error(s), 0 warning(s), so nothing signals that theworkflow is no longer pinned. In a consumer repo that has not set those
variables, the run quietly executes on
claude-sonnet-4.6instead of the modelthe author selected.
Either combination on its own is fine — the pin only disappears when both are
present.
Reproduction (v0.82.13)
.github/workflows/shared/model.md:.github/workflows/probe.md:max-ai-creditsengine.modelfromgpt-5.6-sol✅gpt-5.6-sol✅1500gpt-5.6-sol✅1500Expected
An imported
engine.modelshould resolve identically to an inline one. If somecombination genuinely cannot be supported, the compiler should fail rather than
emit a workflow whose model pin has silently disappeared.
Why this matters
Sharing
engine:through an import is the only way to define a model default inone place: gh-aw permits exactly one
engine:across a workflow and all of itsimports, so an importing workflow cannot restate the pin as a safety net. A
catalogue of workflows that centralises its model pin this way loses the pin on
exactly the workflows that also cap their spend — and finds out at runtime.
Environment
v0.82.13copilot, CLI1.0.70