Agents and models

Each workspace has one coding agent at a time, picked from a roster of ten. The agent is how you get access, not the thing doing the thinking.

It decides which models you can reach through your subscription for that agent. The model is what actually runs. You pick both from the prompt input.

Models and reasoning effort

Switch agent and Cohalen re-lists its models, landing on that agent's flagship default. Each model brings its own capabilities.

• Reasoning effort is how much thinking you're paying for on this model, set from a small gauge in the prompt input. The steps are the model's own. The gauge hides for a model that has no such setting.
• Fast mode is faster output at the same level of thinking. It shows up only on models that support it.

Some agents give you no model choice at all. There the control is missing, not empty.

Turns

One prompt, the agent's work, and the reply that streams back make a turn. The workspace is busy from the moment you send until the reply finishes. You can cancel a turn that's running.

Turns carry on from each other. Each one picks the workspace's session back up, so the agent keeps its context across turns and across app restarts.

The reply arrives in parts, in the order the agent produced them. Prose, a collapsible Thinking trace, and each tool call inline with its status and what it returned.

Everything the agent does shows up in the chat. Nothing about a running agent hides in the Terminal.

Skills

A skill is a reusable SKILL.md playbook each agent loads from its own directories. Cohalen keeps its hands off what's in them. It never stores or injects one, because re-injecting a skill the agent already loads would put it in the context twice.

What Cohalen adds is the / picker in the prompt input. It autocompletes skill names from the active agent's own roots, and the agent takes it from there.

Skills aside, a custom instruction in Settings is text Cohalen owns and carries into every turn. Use it for preferences every agent on this machine should follow.

Prompting for a clean changeset

Keep the prompt to one task, and say in it what done looks like: what to build, what to test. The changeset you read afterwards is everything that workspace changed, so a prompt that wandered gives you a diff that wandered.

When the reply needs fixing, leave a note on the diff line rather than writing a fresh prose prompt.