iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Set model: inherit in an APC agent file unless your project genuinely requires one specific model. With that value, the file describes the agent’s role, instructions, and metadata, and the runtime that executes the agent chooses which model to use. The same agent definition can then move between contributors and tools without carrying one developer’s model choice along with it. Pin a named model only when that model is part of what the project has agreed to deliver, and write down what happens when it is unavailable.
What model: inherit means
The Agent Project Context (APC) specification recommends three frontmatter fields for an agent definition: name, model, and description. Skills and presentation fields such as color, emoji, and vibe may also appear. The specification’s guidance on model is to use inherit unless the project truly requires a specific model, and it says APC should not make one vendor’s model the default. The APC “Agents” specification sets out these rules.
A minimal agent file using the recommended value looks like this. The name and description are illustrative:
---
name: reviewer
model: inherit
description: Reviews pull requests for correctness and missing tests.
---The file says what the agent is for and how it should behave. It does not say which model answers, so the role stays the same whether the agent runs in one editor, a terminal CLI, or a background daemon.
#1 Best Overall
Where APC agent files live
APC splits project context into two surfaces. AGENTS.md at the repository root is the broader project contract for repository-wide rules and context. Each structured agent definition lives in .apc/agents/<slug>.md. Compatible tools read the root file for project rules and the structured file for agent-specific metadata.
The APC guide’s repository layout places AGENTS.md, the .apc/ metadata directory, rules, skills, plans, and structured agents side by side. It also draws a boundary that matters for portability: sessions and raw runtime history belong to the IDE, CLI, or daemon that created them, not to the portable project context. See the APC guide for adding APC to a project and the minimal APC example.
This split is why the model setting belongs in the agent file only when it is a real project requirement. Project context is meant to travel with the repository. Runtime state and personal configuration are not.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →When a team should pin a specific model
A concrete model value is justified when the model is part of the project’s contract. Typical cases include:
- A workflow designed to evaluate a named model, where swapping the model would change what the workflow measures.
- A capability the team has agreed to as part of the project’s deliverables, where a substitute model would not meet that agreement.
Some values do not qualify. A personal preference, or a value copied from one developer’s current setup, is not by itself a durable project requirement. If a pinned model is justified, state the reason next to the agent definition and document what users should do if the model cannot be used. A fallback that the team has chosen is far more useful to the next contributor than an agent that simply fails.
Inherit versus a pinned model
The two choices differ mainly in who makes the model decision and what breaks when the environment changes.
Rank #3
| Consideration | model: inherit |
Pinned model ID in the agent file |
|---|---|---|
| Who chooses the model | The configured runtime | The agent file, with the runtime expected to honor it |
| Portability across contributor environments | High: the same role definition works wherever a runtime is configured | Lower: depends on the named model being available to each contributor |
| Fit when a task requires a particular model | Poor: the requirement is not expressed in the file | Good: the requirement is version-controlled |
| Maintenance burden | Low: nothing to update in the file | Ongoing: the provider and model identifier must be revisited as models change |
| Behavior if the model is unavailable | Depends on the runtime’s configuration; not stated by the specification | Depends on the documented fallback; the specification requires one to be documented |
The table shows the trade-off rather than a winner. For most agents, inheritance is the better default because the project rarely depends on a specific model. For the minority that do, the pinned value is the honest way to record that dependency.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Auditing existing agent files
Many repositories picked up concrete model values before anyone asked whether they were needed. The APC guidance points to a simple audit:
- List the structured agent files:
ls .apc/agents/*.md. - Find every concrete model value:
grep -n "^model:" .apc/agents/*.md. - For each value, ask why it must be version-controlled. Check whether a written project requirement, workflow, or agreement depends on that exact model.
- Keep values backed by a requirement, and record the reason and fallback next to the agent definition.
- Change incidental values to
model: inherit. - Set the actual model in each runtime’s own configuration. The sources reviewed for this article do not name one setting that works across every runtime, so check the documentation for the tool you use.
After the audit, a diff should show a small number of pinned values, each with a stated reason, and a larger number of inherit values that no longer carry one developer’s environment.
What inheritance does not guarantee
inherit moves the model decision to the runtime. It does not solve every portability problem, and it is easy to overstate what it does.
- It does not guarantee that a given model is installed, healthy, available, or affordable on a contributor’s machine.
- It does not guarantee that different runtimes ship the same default model or give access to the same models.
- The indexed article on this topic describes the runtime as resolving the model choice rather than sending the literal word
inheritas a model ID. That is the article’s description of how it works. It is not a guarantee about every third-party tool that reads APC files.
Runtimes named in the specification
The APC documentation names Codex, Claude Code, Cursor, and APX as examples of compatible consumers. The mention identifies examples in the specification. It is not an endorsement of any tool, and it does not establish that every feature behaves the same way in every version. Check each runtime’s documentation before relying on a particular configuration path.
Recommended Free Tools
How firm the evidence is
The APC specification is normative guidance for how agent files should be written. It supports the default-to-inherit rule and the requirement to document any pinned model, but it does not report measured outcomes. No published statistic was identified that quantifies how much portability improves when teams use inheritance, so the case for the default rests on design reasoning, not on a measured result.
The specification’s recommendation, in its own words, is: “Use inherit unless the project truly requires a specific model.”
A companion article by Manuel Bruña for Agent Project Context, indexed as published September 18, 2026, makes the same case for inheritance as the better default. The full text could not be verified when this article was written, so its wording is not quoted here. The specification is the authoritative reference.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
