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:

<!--<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:

<!--<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:

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

Example precedence

For model ID claude-opus-4-20251101:

<!--<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:

<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:

<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:

<!--<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

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

Scoring