Response payload shape determines data quality
Coolhand extracts fields from two different Copilot response payload shapes:
| Field | Older payload | Newer payload (copilotUsage.tokenDetails) |
|---|---|---|
| Model name | From response_body.model |
From response_body.model |
| Input token breakdown | Top-level inputTokens (net of cache) |
tokenDetails entry with tokenType: "input" |
| Cached Input Tokens | Top-level cacheReadTokens |
tokenDetails entry with tokenType: "cache_read" |
| Cache Creation Tokens | Top-level cacheWriteTokens |
tokenDetails entry with tokenType: "cache_write" |
| Reasoning Tokens | response_body.reasoningTokens |
response_body.reasoningTokens |
| Thinking Response | response_body.reasoningText |
response_body.reasoningText |
Coolhand prefers the copilotUsage.tokenDetails array when present and falls back to top-level fields automatically. The branching is based on what the Copilot server returns in its response payload, not on a client SDK version.
Note: Token fields for cache reads/writes are inconsistently populated across Copilot environments — if they are blank, this is a known upstream behavior, not a Coolhand issue.
Temperature is always blank
Copilot manages generation parameters server-side. You cannot set or observe temperature — it will always be blank in Coolhand.
Structured outputs
Depends on the underlying model Copilot routes to. Not configurable directly — Copilot controls routing and model parameters.
Caching
Managed entirely by Copilot server-side — there is no caller API for enabling or configuring caching. Coolhand captures what Copilot reports:
- Cached Input Tokens — from
cache_readintokenDetails, orcacheReadTokensas fallback - Cache Creation Tokens — from
cache_writeintokenDetails, orcacheWriteTokensas fallback
TTL and invalidation are opaque — Copilot does not expose cache lifecycle details to callers.
Batch processing
No batch API. GitHub Copilot is designed for interactive, real-time use. There is no mechanism for submitting offline batch jobs.