agentleFS
MicrosoftKnown publishermicrosoft/PilotSwarm/packages/sdk/plugins/mgmt/skills/cost-latency-analysis/SKILL.md

cost-latency-analysis

Skill14 starsChanged 8 months agoMITView on GitHub

How to compute model latency and estimated $ cost from PilotSwarm data. Read this before calling a model "slow" or "expensive": most slowness is orchestration overhead, and a cost is a guess unless it cites a published price card.

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 4 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read the model name from the metric summary (or from the assistant event's model field for per-turn cost).

    line 56
  2. Distinctive:

    Look up the per-million-token input + output price from the provider's published page (links below).

    line 58
  3. Very specific:

    If the model offers prompt caching (Claude, GPT-5.4 family), apply the discounted cache-read rate to tokens_cache_read.

    line 63
  4. Very specific:

    Do not report per-token dollar cost for github-copilot:* sessions.

    line 89
  5. Distinctive:

    Never quote a per-token dollar cost without naming the price source and the date you fetched it.

    line 109
  6. Very specific:

    Never compare model latency using runTurn spans alone.

    line 111
  7. Distinctive:

    Never claim Copilot per-token cost in dollars — Copilot pricing is not per token.

    line 112
  8. Distinctive:

    Never average across mixed providers without tagging each row by model and provider — you will average $30/M-token Opus calls with …

    line 114

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Cost & Latency Analysis

You are the agent-manager. When investigating reliability, cost, or performance, follow this skill.

Latency: prefer assistant.usage.duration

PilotSwarm records two different "durations" per turn. Do not confuse them:

SourceWhat it measuresWhen to use
runTurn activity span (execution history)Total wall-clock time the activity ran, including dehydrate, hydrate, snapshot, blob I/O, scheduling.Operator-facing "how long did this turn take end-to-end". Useful for orchestration-overhead investigations.
assistant.usage.duration (assistant event)Time spent inside the model call itself as reported by the LLM provider.Model-latency comparisons. The only fair number to use when comparing models, providers, or context sizes.

runTurn spans can materially overstate model latency — sometimes 2–5× — because they include dehydrate/hydrate, snapshot serialization, blob storage round-trips, retry backoff, and tool-execution time.

Rule of thumb:

  • Comparing "is gpt-5.4 slower than gpt-5.4-mini?" → use assistant.usage.duration.
  • Investigating "why does this turn take 30 seconds?" when the model number is small → look at the runTurn span and compare to the assistant span. The delta is the orchestration overhead.

Where to read it from

  • Per-turn: read_agent_events filtered to event_types: ["assistant"], then read usage.duration (often in milliseconds — confirm units in the actual payload, do not assume).
  • For roll-ups, request a derived field on the management surface and expose it as a tool (see the Observability Surface for the Agent Tuner rule in .github/copilot-instructions.md). Do not summarize latency by averaging runTurn spans — it will mislead.

Cost: estimate, do not guess

Token counts come from read_session_metric_summary / read_fleet_stats and are reliable. Per-token prices change constantly and do not live in PilotSwarm. Always derive cost from a linked, dated snapshot of each provider's price card.

Default approach:

  1. Read the model name from the metric summary (or from the assistant event's model field for per-turn cost).
  2. Look up the per-million-token input + output price from the provider's published page (links below). Note the date you looked it up.
  3. Cost = (tokens_input × $/M-input + tokens_output × $/M-output) ÷ 1,000,000.
  4. If the model offers prompt caching (Claude, GPT-5.4 family), apply the discounted cache-read rate to tokens_cache_read. Cache writes are often billed at standard input rate.
  5. Report the price source and date alongside the dollar figure.

Stable price-card sources

These are the canonical pages to consult. Do not invent or memoize numbers — re-fetch on each report.

Example

session: 22013ffb
model:   azure-openai:gpt-5.4
tokens:  input 28,634   output 4,224   cache_read 16,700
report:
  - input cost:       28634 × $X/M = $...
  - output cost:      4224  × $Y/M = $...
  - cache-read cost:  16700 × $Z/M = $...
  total ≈ $0.0XX  (price source: openai.com/api/pricing, fetched <date>)

What to never do

  • Never quote a per-token dollar cost without naming the price source and the date you fetched it.
  • Never compare model latency using runTurn spans alone.
  • Never claim Copilot per-token cost in dollars — Copilot pricing is not per token.
  • Never average across mixed providers without tagging each row by model and provider — you will average $30/M-token Opus calls with $0.10/M-token nano calls and report a number that is meaningless.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.