v0.6.0

What's Changed

• Add ToolCallUsage.Iteration for per-tool prompt-cost attribution; bump to 0.6.0 by @RorroRojas3 in #11

The usage report learns which model turn issued each tool call: ToolCallUsage.Iteration (#10) correlates the ToolCalls tree with the per-turn Turns breakdown, closing the gap that made exact per-tool prompt-cost attribution impossible — the cost of a tool's arguments and result is billed in the next iteration's prompt, and until now nothing said which calls sat between two turns. Dependency floors move to Microsoft.Extensions.AI 10.9.0 and ModelContextProtocol.Core 2.2.0.

Added

• ToolCallUsage.Iteration (Andes.Extensions.AI/Usage/ToolCallUsage.cs, #10): the zero-based model iteration of the function-invocation loop that issued the call, corresponding to AssistantTurnUsage.Iteration. When streaming, the value is stamped the moment the tool's scope opens, so it always names the issuing turn — including when one turn issues several calls, which timing alone could never disambiguate (with the default serial invocation, N calls from one turn are indistinguishable from N single-call turns). Nested calls (the Children of another call — an agent's own tools, or a nested agent/MCP child card) report the iteration of the outer request's model turn that issued the enclosing root call. On the non-streaming path the value is always 0, consistent with ChatUsageReport.Turns being populated only when streaming.
  • Why (from the issue): per-tool prompt-cost attribution. A tool — an MCP tool especially — consumes no tokens directly, but its arguments and result enter the next iteration's prompt and are billed there. With the per-turn breakdown that cost is recoverable exactly, from provider-reported integers rather than a tokenizer estimate — input(N+1) − input(N) − output(N) — and Iteration is the missing piece that tells you which calls sit between turn N and turn N+1. The library reports the facts; the delta arithmetic stays with the consumer (reasoning tokens bill as output but are usually not replayed into the next prompt, and cached input bills at a discount, so the subtraction is an attribution model, not an invoice).
  • The property is required with an init setter. Impact is compile-time only, and only for code constructing ToolCallUsage directly via an object initializer — the library's sole construction site is the internal RequestTracker, and code that reads reports is unaffected.

Changed

• Dependency pins (Directory.Packages.props) — the consumer-visible floors: Microsoft.Extensions.AI (the core package's dependency) and Microsoft.Extensions.AI.Abstractions (the UI package's dependency) 10.8.3 → 10.9.0, and ModelContextProtocol.Core (the MCP satellite's dependency) 2.1.0 → 2.2.0. The Agent satellite's floor is unchanged (Microsoft.Agents.AI stays 1.17.0). OpenAI deliberately stays 2.12.0: Microsoft.Extensions.AI.OpenAI 10.9.0 constrains it to >= 2.12.0 && < 2.13.0. Test- and sample-only bumps ride along, none of them shipped to NuGet: Microsoft.Extensions.AI.OpenAI 10.8.3 → 10.9.0, ModelContextProtocol (the full package) 2.1.0 → 2.2.0, Microsoft.Extensions.Configuration.Binder/.Json and Microsoft.Extensions.Hosting 10.0.10 → 10.0.11, Microsoft.NET.Test.Sdk 18.8.1 → 18.9.0, and xunit.runner.visualstudio 3.1.5 → 4.0.0.
• Docs updated for the new member: Getting started adds Iteration to the usage-report member notes; Architecture adds it to the report shape and gains a correlation paragraph under Usage attribution explaining the delta formula and its caveats; MCP tool tracking and Agent tool tracking note the nested-child semantics where the child ToolCallUsage is discussed; and the satellite prerequisites reflect the new floors.
• All four packages version in lockstep at 0.6.0; the satellites depend on core >= 0.6.0.

Full Changelog: v0.5.0...v0.6.0