# Model targeting
### One pack, many models

Different models have different capabilities. Claude has extended thinking. GPT has function calling nuances. Ollama models vary wildly in instruction-following. Without model targeting, you're stuck maintaining separate prompt forks—or accepting suboptimal behavior.

Valdr's model targeting lets you ship a single pack that adapts its instructions based on which model is running.

> [!TIP]
> **The migration story:** Start with Ollama locally for cost-effective development. Scale to Claude in production for capability. Same pack, different behavior—no prompt rewrites.

**Who this is for:** Pack authors and operators running the same workflows across multiple models or providers.

**What model targeting does not change:** Charter identity, capability IDs, and scoring rules remain constant across models. Only behavioral content adapts—governance stays intact.

## How it works

Behavioral tags can include model-specific content that's selected at runtime based on which model is active.

### Option 1: Attribute on the tag

Target an entire tag to specific models:

```markdown
<!--<instructions model="claude-*">-->
You have access to extended thinking. Use it for complex multi-step reasoning
before producing your final answer.
<!--</instructions>-->

<!--<instructions model="ollama-*">-->
Break complex tasks into explicit numbered steps. Show your reasoning
at each step before producing your final answer.
<!--</instructions>-->
```

### Option 2: Nested model blocks

Include model-specific variations within a single tag:

```markdown
<!--<instructions>-->
You are a code reviewer. Analyze the provided code for correctness,
performance, and maintainability.

<model type="claude-*">
Use extended thinking to explore edge cases before finalizing your review.
</model>

<model type="ollama-*">
List potential issues one by one, then summarize your findings.
</model>

<model type="gpt-*">
Structure your response using the provided function schema.
</model>
<!--</instructions>-->
```

## Selector syntax

Model selectors can be exact matches or glob patterns.

| Pattern | Matches | Use case |
| --- | --- | --- |
| `claude-opus-4` | Exact match only | Target specific model version |
| `claude-*` | Any Claude model | All Claude variants |
| `claude-*-sonnet` | Claude sonnet variants | Sonnet-specific behavior |
| `gpt-*` | Any GPT model | All OpenAI models |
| `gpt-4*` | GPT-4 and variants | GPT-4 specific features |
| `ollama-*` | Any Ollama model | Local model behavior |
| `gemini-*-flash` | Gemini flash variants | Fast/cheap model tier |

### Wildcard rules

- `*` matches any substring (including empty)
- Patterns are matched against the full model ID
- Multiple selectors can be comma-separated: `model="claude-*,gpt-4*"`

## Precedence rules

When multiple model blocks could match, Valdr uses these rules:

1. **Exact match** wins over wildcards
2. **More specific wildcard** (longest literal portion) wins over less specific
3. **File order** breaks ties between equally specific patterns
4. **Default content** (no model targeting) is required and used as fallback

### Example precedence

For model ID `claude-opus-4-20251101`:

```markdown
<!--<instructions>-->
Default behavior.                           <!-- Fallback -->

<model type="claude-opus-4-20251101">
Exact match — highest priority.             <!-- Wins -->
</model>

<model type="claude-opus-*">
Opus-specific — more specific wildcard.     <!-- Second -->
</model>

<model type="claude-*">
Any Claude — less specific wildcard.        <!-- Third -->
</model>
<!--</instructions>-->
```

## Supported tags

Model targeting works on behavioral tags:

| Tag | Model targeting |
| --- | --- |
| `instructions` | Supported |
| `communication_guidelines` | Supported |
| `execution_loop` | Supported |
| `tool_usage_policy` | Supported |
| `safety_and_data` | Supported |
| `status_update_spec` | Supported |
| `summary_spec` | Supported |
| `prompt_fragment` | Supported (via `model` attribute) |

## Why this matters

### Cost optimization

Route simple tasks to smaller, cheaper models:

```markdown
<model type="claude-haiku-*">
This is a simple extraction task. Return only the requested fields.
</model>

<model type="claude-opus-*">
This task may require nuanced judgment. Consider edge cases and
explain your reasoning.
</model>
```

### Capability differences

Handle models with different tool support:

```markdown
<model type="claude-*">
Use the provided MCP tools to interact with the codebase.
</model>

<model type="ollama-llama-*">
You don't have direct tool access. Describe what actions you would
take, and the orchestrator will execute them.
</model>
```

### Migration paths

Enable gradual migration between providers:

```markdown
<!--<instructions>-->
Core behavior that works everywhere.

<model type="ollama-*">
<!-- Local development behavior -->
Keep responses concise to minimize latency.
</model>

<model type="claude-*">
<!-- Production behavior -->
Leverage extended context and thinking for thorough analysis.
</model>
<!--</instructions>-->
```

### Testing and validation

Run the same pack against multiple models to compare behavior:

- Validate that core functionality works across providers
- Identify model-specific edge cases
- Benchmark quality/cost tradeoffs

## Model ID allowlist

Model selectors must come from a canonical allowlist to prevent typos and ensure consistency. The allowlist is stored with prompts (e.g., `agents/prompts/MODEL_IDS.json`).

Common model patterns:

| Provider | Pattern examples |
| --- | --- |
| Anthropic | `claude-opus-*`, `claude-sonnet-*`, `claude-haiku-*` |
| OpenAI | `gpt-4*`, `gpt-3.5*`, `o1-*` |
| Google | `gemini-*-pro`, `gemini-*-flash` |
| Ollama | `ollama-llama-*`, `ollama-mistral-*`, `ollama-codellama-*` |
| AWS Bedrock | `bedrock-claude-*`, `bedrock-titan-*` |

## Best practices

1. **Always include default content** — model-specific blocks are optional; default is required
2. **Start broad, refine as needed** — use `claude-*` before `claude-opus-4-20251101`
3. **Document model assumptions** — if a block assumes tool support, say so
4. **Test across models** — validate that defaults work before shipping model-specific overrides
5. **Keep overrides minimal** — only diverge where model capabilities genuinely differ