Prompting, Models & Customization — assessment

• Through the model picker, same as paid plans.
• By asking for it in the prompt text.
• You cannot pin one — on those plans models are reached through auto model selection only.
• By setting the model in a prompt file.

• It costs more, because routing is charged separately.
• It makes usage free.
• It has no billing effect; it only picks a model.
• It applies a 10% discount on model costs, which makes it the sensible default for work with no specific model requirement.

• It routes to the blocked model anyway, since auto selection overrides policy.
• It excludes the blocked model, and also respects data-residency and FedRAMP restrictions.
• It fails with an error until the policy is changed.
• It asks the user to approve an exception.

• It always routes to the newest available model.
• GitHub does not publish the routing list, so the site records it as not published rather than naming models.
• It routes based on your plan tier only.
• It routes to the cheapest model.

Select all that apply.

• Which frameworks and versions the project actually uses.
• The project's testing conventions, so generated code arrives with tests in the expected shape.
• A request to skip error handling to keep examples short.
• API tokens for the services the project talks to.

• Custom instructions work only in the CLI.
• Custom instructions apply standing context to work in that repository; a prompt file is an invocable, reusable task you run deliberately.
• Prompt files apply automatically to every request.
• They are the same thing with different file extensions.

• Instructions compete for the same context budget as your code, so an over-long file crowds out the thing being asked about.
• Long instruction files are ignored entirely.
• There is a hard line limit and you have exceeded it.
• The model caches instructions and serves stale ones.

• "Rewrite `parse_duration` to accept ISO-8601 durations, keeping the current return type and raising `ValueError` on malformed input." — it names the target, the constraint and the failure behaviour.
• "Fix all the bugs in this file." — it covers more ground in one request.
• "You are an expert Python developer with 20 years of experience." — role framing raises quality.
• "Make the duration parsing better." — shorter prompts leave the model free to apply best practice.

• Smaller models are more accurate.
• For mechanical work where correctness is easy to verify, the larger model's advantage does not justify the extra allowance and latency.
• Smaller models do not consume any allowance.
• Larger models are unavailable on paid plans.

• Ask each developer to set personal custom instructions.
• Standardise on one model across the team.
• Rely on the linter to fix it afterwards.
• A repository-level instructions file committed to the project, so every contributor's Copilot reads the same conventions.