If you’ve started building agents with the GitHub Copilot harness in Microsoft Copilot Studio, you’ve probably asked yourself: what does one turn actually cost? The answer depends on a distinction that most cost models have not caught up with. A user turn and a reasoning turn are not the same thing — and confusing the two leads to budgets that don’t hold and architectures that don’t scale.
This article defines both boundaries precisely, explains how they nest inside each other, and shows what the difference means in practice when you trace a real agent running a procurement document review.
What the GitHub Copilot Harness Is
Three harnesses, one Studio
Every agent or workflow built in Microsoft Copilot Studio runs on one of three harnesses. The GitHub Copilot harness is designed for reasoning-heavy, multi-step work requiring autonomous decision-making. The standard harness handles rule-based, predictable conversations following explicit topic flows. The Copilot chat harness extends Microsoft 365 Copilot Chat with organizational knowledge.
The harness is the runtime layer sitting between the model and the agent design. It determines when to call the model, what to include in each call, how to interpret the response, and which tools to execute next.
What makes the GitHub Copilot harness different
The standard harness follows the topics and branches a maker authors explicitly. When a tool call finishes, the harness waits for the next user message. Conversation flow is deterministic and configured in advance.
The GitHub Copilot harness does something fundamentally different. Instead of following authored topics, it runs an autonomous reasoning loop. Given a goal, the harness breaks that goal into steps, calls the right tools, observes what comes back, and decides on its own whether to continue iterating or deliver a final response. It operates with frontier reasoning models — the same orchestration engine behind experiences such as Copilot Cowork and the GitHub Copilot coding agent.
⚡ The architectural consequence
Because the harness decides its own step count at runtime, the cost model changes completely. You cannot predict the cost of a user turn before it runs. The loop length is determined by what the tools return and what the model decides to do next.
The User Turn: A Configuration Boundary
Microsoft’s technical definition
The most precise definition Microsoft provides for a user turn comes from the documentation on mid-conversation agent editing:
The turn in progress continues to use the agent’s previous configuration until it finishes. The next turn picks up your changes automatically.
— Microsoft Copilot Studio documentation
The definition says nothing about tokens, credits, or step counts. It describes a configuration isolation boundary.
What a user turn is — and is not
A user turn opens when an inbound user message arrives and closes when the agent has finished everything it decided to do in response. For its entire duration, the agent’s configuration is frozen — instructions, skills, tools, knowledge sources, and model selection all remain locked. It contains a variable number of reasoning iterations inside it, not one. And it is countable in advance: exactly one per user message, predictable before execution.
A user turn is not a cost unit. It is not a step. It does not map to a fixed number of LLM calls. You can count user turns before your agent runs. You cannot count reasoning turns the same way.
The configuration freeze in practice
When a maker edits the Build tab — updating instructions, modifying skill definitions, adjusting knowledge sources, changing the model — those changes do not apply to any turn currently in progress. The configuration snapshot that existed when the turn opened remains in effect until that turn closes. Only the next inbound message picks up the updated configuration.
Consent gates: turns that stay open
A user turn can remain open across a human approval gate — a point in the reasoning loop where the agent pauses and waits for a user decision before continuing. The reasoning loop suspends at the consent gate, preserving all intermediate context. The turn boundary is not a latency boundary: a single user turn can span human decision latency — seconds, minutes, or longer — and still close as a single turn.
The Reasoning Turn: An Iteration Boundary
What a reasoning turn is
A reasoning turn is one iteration of the agentic reasoning loop — one LLM API call and its direct consequences: tool invocations, knowledge queries, skill activations, and connector calls that the model chose to execute in that iteration.
A turn is a single LLM API call and its consequences. A single user message typically results in multiple turns.
— GitHub Copilot SDK documentation
Inside one user turn, the harness executes this cycle repeatedly: think → act → observe → think again. Each pass through this cycle is one reasoning turn.
The diagram below shows the reasoning loop in action — already animated and interactive. Click to expand it fullscreen.
The agentic loop mechanics
On each reasoning turn, the harness assembles the full prompt — system instructions, conversation history, tool definitions, and all tool results accumulated so far — and sends it to the model. If the response contains tool calls, the harness executes those tools, captures their results, and loops back. If the response contains no tool calls, the loop terminates and the text response is delivered to the user.
The loop terminates when the model decides there is nothing left to do. Not when a timer expires. Not on a fixed iteration ceiling, unless a tool-call limit is explicitly configured.
Why context accumulates
The prompt is rebuilt from scratch on every reasoning turn, always including every tool result the loop has produced up to that point. Reasoning turn 1 sends the initial prompt. Reasoning turn 2 sends the initial prompt plus the tool results from turn 1. Reasoning turn n sends the initial prompt plus all accumulated results from turns 1 through n−1.
Token consumption does not grow linearly. A user turn that resolves in 3 reasoning turns and one that resolves in 20 do not scale proportionally in credit cost. Every additional iteration carries the full accumulated payload of all prior steps — and that payload grows with each pass.
What triggers additional reasoning turns
- Tool failures — the harness retries automatically. Each retry is an additional reasoning turn.
- Ambiguous or overlapping skill descriptions — the orchestrator may try a skill, determine it is not the right match, and attempt another. Each attempt is a reasoning turn.
- Multi-step data dependencies — when one tool result is required before the next query can be formed, each data-fetching step adds a reasoning turn.
- Context compaction — when accumulated context approaches the model's limit, the harness triggers compaction. Compaction itself requires an additional LLM call.
Nesting the Two Boundaries
The relationship between the two boundaries is one of containment: the user turn is the outer boundary, the reasoning turns are the iterations running inside it.
USER TURN
│ The outer boundary. Opened by one user message, closed when the
│ agent finishes all decided work. Counts as one per message.
│ Configuration is frozen for its entire duration.
│
└── REASONING TURN (1..n)
One iteration of the agentic loop. One LLM API call plus
any tools it invokes. Context grows with each iteration.
Count is not known until the loop has finished running.The user sees two events: the message they sent and the response they received. Between those two events, the harness may have executed dozens of reasoning turns invisibly.
The diagram below maps the two boundaries across a complete five-turn example. Click to view it full size.
Tracing an Example: Procurement Document Review
To make this concrete, consider an agent configured to help a procurement team review incoming supplier documentation. The agent has access to a SharePoint knowledge base of approved vendor policies, a connector to a document management system, and three skills: one for document classification, one for policy compliance checking, and one for drafting reviewer summaries.
A user sends: "Check this supplier's delivery terms document and tell me whether it complies with our standard procurement policy."
What happens inside one user turn:
User message (user turn opens)
├── Skill: document-classifier
│ └ Classifies input as "delivery terms contract"
├── Connector: document-management-system
│ └ Retrieves the referenced document
├── Knowledge search: vendor-policy-kb
│ └ Retrieves relevant sections of the procurement policy
├── Skill: policy-compliance-checker
│ └ Compares document clauses against retrieved policy sections
├── Skill: summary-drafter
│ └ Drafts the reviewer summary
└── Response delivered (user turn closes)Five reasoning turns. One message and one reply on the chat surface.
If the document management connector returns a timeout on the first attempt, the harness retries automatically. That retry is an additional reasoning turn with additional accumulated context. A single transient tool failure turns five reasoning turns into seven or more, with compounding context weight on each.
⚠️ Watch out: optimizing the connector's response time in milliseconds is largely irrelevant to credit consumption. What matters is how many times the loop calls it, not how fast each individual call returns. The credit meter tracks iterations and tokens, not wall-clock time.
The animated diagram below shows how context accumulates across the five reasoning turns and why the last turn is the most expensive. Click to expand.
Skills: Description Quality as a Cost Surface
What skills are
A skill is a reusable agent capability defined by three elements: a name, a description, and a set of Markdown instructions that guide the agent's behavior when the skill is active. The description is what the orchestration runtime reads to decide whether a skill is relevant to a given user request. It is not documentation for human readers — it is input to the model's routing decision.
How the orchestrator selects skills
The orchestration runtime performs semantic matching: it evaluates which registered skills' descriptions best fit the user's request. When it finds a match, it activates the skill and passes control to its instructions.
When descriptions are vague or overlap with other skills, the orchestrator cannot confidently route on the first attempt. It may activate a skill, observe that it does not match, and loop back to try another. Each attempt is a reasoning turn with accumulated context. This disambiguation cost recurs on every affected user turn, indefinitely, until the descriptions are improved.
The engineering implication
Skill description quality is not a documentation practice. It is a performance optimization that directly reduces reasoning turn count. Precise, non-overlapping descriptions reduce disambiguation turns, retry iterations from misrouted activations, and accumulated context from failed attempts.
The diagram below shows side-by-side what happens when descriptions are vague versus precise — and the reasoning turn cost difference that results. Click to expand.
Skill format
Skills in the GitHub Copilot harness follow a standard format: YAML front matter containing the skill name and description, followed by Markdown instructions. This makes them portable — they can be authored directly in Copilot Studio, written in any text editor and uploaded, or exported and shared across agents.
The Activity Trace: Observing the Loop
What the activity trace shows
The activity trace in Copilot Studio shows exactly how the agent processed each message: the chain-of-thought reasoning, which knowledge sources were consulted, which tools were invoked, and at what points errors occurred.
| Node type | What it represents |
|---|---|
| Knowledge | Knowledge source retrieval |
| Tool | Tool invocation |
| Connector | Power Automate flow or API call |
| Flow | Power Platform flow integration |
| Skill | Skill activation |
| Ran action | An action that was executed |
| Error | A failure point in the chain |
| Complete | Terminal state: all tool calls finished |
How to access the trace
Open the agent in Copilot Studio and navigate to the Preview tab. Verify that the End User Preview toggle is off — the default maker view. The activity trace renders alongside the chat pane, updating in real time as the agent processes each message.
Using the trace for cost analysis
The activity trace is the primary instrument for understanding loop depth. Before estimating costs or setting budget limits, send five to ten representative messages that reflect your production workload, count the reasoning nodes in each trace, and record the distribution — minimum, median, 95th percentile. Also note tool-call completions versus tool-call starts: a high ratio of starts to completions indicates retry behavior.
Cost Estimation: A Measurement-First Approach
Why per-turn pricing does not exist
The question "how much does one user turn cost?" presupposes a step-shaped runtime. The GitHub Copilot harness does not have one. Loop length is a runtime variable, not a configuration parameter. There is no documented function from user turn count to credit consumption. The correct approach is measurement before estimation.
A practical estimation framework
Step 1 — Characterize the loop. Using the activity trace, measure reasoning turns across a representative sample of user turns and record the full distribution. An agent with a median of 4 reasoning turns and a 95th percentile of 30 has a cost profile no single average describes. Budget from the tail.
Step 2 — Correlate trace counts to PPAC reporting. There is no documented formula converting reasoning turn counts to credits. Run your traced sample, observe the corresponding consumption in the Power Platform Admin Center (PPAC — the administrative hub for Power Platform environments and resource allocation), and derive your own cost function for your specific agent and tool composition.
Step 3 — Budget build and runtime separately. Build-time credit consumption starts the moment authoring begins. For agents in active development, the authoring loop can dominate credit consumption before a single real user interacts with the agent.
Governance: Containing Unbounded Loops
The structural risk
The GitHub Copilot harness is designed to keep going until the task is done. That is its strength. It is also a structural risk: a loop that encounters repeated tool failures, ambiguous intent, or an unusually complex request can run far longer than typical usage, consuming credits from the shared tenant pool. Credits pool at the tenant level — an unbounded loop on one agent affects capacity available to all agents and all environments in the organization.
The PPAC governance model
In the Power Platform Admin Center, under Licensing → Copilot Studio → Manage Agents, administrators can set a monthly Copilot Credit limit per agent, configure alert thresholds as consumption approaches the limit, and enable automatic shutoff when the limit is reached.
Cost reduction without reducing capability
| Lever | Effect |
|---|---|
| Sharpen skill descriptions | Reduces disambiguation iterations |
| Remove overlapping skill definitions | Eliminates ambiguous routing |
| Improve tool reliability | Reduces retry loops |
| Select a lighter model for simpler reasoning steps | Reduces per-token cost on every reasoning turn |
| Improve knowledge source relevance and indexing | Reduces the number of retrieval queries needed |
Summary: What Has Changed
The GitHub Copilot harness replaced a step-shaped runtime with a loop-shaped one. That changes everything about how you reason about cost, capacity, and governance.
- The user turn is a configuration boundary, not a cost unit. It opens on inbound message, closes on agent completion, and freezes configuration for its duration. You can count them in advance.
- The reasoning turn is the iteration boundary — one LLM call, its tools, and the context it accumulates. Reasoning turns are not countable in advance. They are what billing actually scales with.
- Context compounds across reasoning turns. Later iterations in a long loop are more expensive because they carry all prior intermediate state.
- Build costs are real and start immediately. Unlike the standard harness, credit consumption begins when authoring begins — not when the agent is published.
- Skill descriptions are a cost engineering surface. Imprecise or overlapping descriptions generate disambiguation reasoning turns on every affected user message, permanently, until corrected.
- There is no published per-user-turn rate. Measurement — using the activity trace and PPAC reporting — is the only way to establish your cost function. Use the distribution, not the average.
The loop decides its own length. Your job is to understand it before you price it.
References
- Use the activity trace to debug your agent — Microsoft Learn
- Skills overview for agents — Microsoft Learn
- Overview of usage-based billing — Microsoft Learn
- Manage costs for agents powered by the GitHub Copilot harness — Microsoft Learn
- Adopting the GitHub Copilot Harness: Cost Control and Governance — The Custom Engine
