> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cortex-labs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Choose a model, tool, or skill for a chat

> Select permitted capabilities for an Arc task and understand unavailable options and turn limits.

<Note>
  This draft describes the intended Arc update. Available models, tools, skills, and interface controls need release-build verification before publication.
</Note>

Choose a model to answer your messages, tools to retrieve information or perform supported actions, and skills to supply a reusable procedure. Each selection remains subject to your current access and the deployment's limits.

## Before you begin

You need access to the chat and permission to change its configuration. Identify the task and the material the model will need, including earlier messages, attachments, and any project context.

This guide covers ordinary Arc chats. An agent chat takes its skills and tools from its agent definition; its chat does not provide an independent skill picker or skill slash-command override.

## Make your selections

1. Choose a permitted model for the task. Its provider security limit must cover the complete request, including chat history, project instructions and memory, attachments, and retrieved tool results.
2. Select the available tools that the task needs. For research, this can include web lookup or authorised file reading. A tool must support plain chats and satisfy the deployment policy, your permissions, and its execution requirements.
3. If you need a repeatable procedure, select a published skill that supports chats. Check its required tools and any unavailable-tool warnings before using it. A skill supplies instructions; it does not grant access or add a missing tool.
4. Submit a focused message, then inspect the response and tool outcomes. For source-based work, check the cited material before relying on the result.

Selecting a Forge definition does not enable it in every context. Tools that need a workspace agent runtime, such as shell execution or specialised graph operations, are unavailable in an ordinary Arc chat.

## What each selection controls

| Selection | Purpose | Boundary |
| - | - | - |
| Model | Produces the response. | The resolved model and provider must be permitted for every part of the outbound request. |
| Tool | Retrieves material or performs a declared operation. | Selection cannot expand your resource access, permitted destinations, or execution limits. |
| Tool group | Simplifies selection of a published set of tools. | Its published membership fixes exact versions; new tools do not appear in that group automatically. |
| Skill | Supplies a reusable procedure and declares required tools. | The skill must be published and compatible with plain chats. Its instructions cannot grant authority or start an autonomous agent. |

A chat turn records the definition versions it uses. Each turn resolves the newest published versions at its start; a publication during the turn does not change it. Earlier messages remain as recorded. An open agent chat retains its selected model even if a later agent-definition version names another model.

## Use a reusable prompt without enabling a skill

A published prompt is message text you were going to type, not a procedure enabled on the chat. Insert it through the composer's **Use a prompt** picker or its prompt slash command, inspect the text, and fill any gaps before sending it.

Gaps such as `{{subject}}` are filled by hand. They are not automatically supplied from project settings or the current date; an unfilled gap can reach the model literally. A prompt does not add tools, supporting files, or authority, and its text does not become a server-side system prompt.

Choose a prompt to reuse the wording of a request. Choose a skill to supply a reusable procedure with declared tool requirements. Inspect which command the slash menu offers rather than assuming that every slash command invokes a skill.

## When a skill needs unavailable tools

Check the reason shown for an unavailable requirement. It can depend on the selected model, the conversation's offered tools, current access, or deployment configuration.

You can enable a skill while its tool requirements are unmet. The skill picker and the chat's Skills tab show warnings, and the context supplied to the model names the missing tools. Enablement does not make those tools available.

Invoking a skill with its `/<slug>` command has a stricter check. If a required tool is unavailable, the command is refused, the message is not stored, and the draft returns to the composer. Review the missing requirements before submitting again.

Use a permitted model and tool configuration that satisfies the task, or choose a procedure that works with the capabilities available to you. If the task depends on a missing capability, leave that part explicitly unfinished. Plain chats cannot fetch a skill's supporting resource files; the skill's written procedure is the context they receive.

## When a provider cannot receive the request

Provider eligibility applies to the complete request, including material introduced by earlier messages and tools. Access to a file does not authorise sending it to every provider.

Arc checks the resolved endpoint and model on each call, including retries and fallbacks. An incompatible provider cannot receive the request. Copying or summarising protected material does not lower its security classification.

Read the displayed restriction and select a compatible permitted model where one is available. If none can handle the required material, that request cannot proceed in the selected configuration.

## When a turn reaches its limits

Each turn has limits on tool calls, elapsed time, tokens, and cost. Reaching a limit stops further calls and leaves unfinished work visible. The response or retained tool results can still be useful, but they do not establish that the whole task completed.

For tool-budget exhaustion, the chat reports a retryable failure. A resend continues from the tool results already held in the transcript. Inspect those results and narrow the remaining request rather than assuming a retry has completed the original task.

For example, ask for a final comparison of three sources already retrieved instead of continuing an open-ended search. A smaller follow-up still runs under the current permissions and configured limits.

## Check the result

Confirm that the necessary tools actually returned usable material and that the response identifies any incomplete work. Verify material findings against their citations.

Try [Research a question in a chat](/arc/chats-and-research/research-a-question) for a worked example. See [Find and verify earlier research](/arc/chats-and-research/find-earlier-research) for the boundaries on retrieving prior work.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.