How Coolhand captures each LLM provider

What Coolhand records for each provider, which fields it can and cannot capture, and how to send requests so your prompts group cleanly into templates.

• Anthropic API best practices

  Anthropic's Messages API carries the system prompt in a top-level `system` field rather than a message with a system role. Coolhand reads that field first and only then falls back to scanning messages, so sending the top-level field is the reliable way to get your system prompt captured and grouped into a template.

• OpenAI API best practices

  OpenAI renamed the system-instruction role to `developer` for its o-series reasoning models and silently maps `system` to it on newer models. Coolhand captures both. Send a system or developer instruction on every request so your prompts group into templates instead of landing on Unmatched.

• Azure OpenAI best practices

  Azure logs record your deployment name, not the underlying model version, so `my-gpt4o-prod` appears where you might expect `gpt-4o-2024-11-20`. Name deployments after the model they serve, and create a new one rather than re-pointing an existing one on upgrade, so cost and quality history stays attributable.

• AWS Bedrock best practices

  AWS Bedrock exposes two API surfaces and Coolhand records them as separate sources: `bedrock` for the OpenAI-compatible Chat Completions format, and `bedrock_anthropic` for the native Anthropic Messages format. Which one you call changes the field shape Coolhand can capture, so pick one per workload and stay on it.

• Google Gemini best practices

  The Gemini API carries system instructions in a top-level `system_instruction` field rather than a system-role message. Coolhand reads that field first and falls back to the contents array, so using `system_instruction` is the dependable path to having your prompt captured and matched to a template.

• Google Vertex AI best practices

  Vertex AI's preferred request format puts system instructions in a top-level `system_instruction` field, outside the `contents` array. Coolhand reads there first and falls back to system or developer roles inside `contents`, so role-based instructions may still be captured — but the top-level field is the reliable one.

• Ollama best practices

  Ollama identifies models as `name:tag`, and Coolhand treats each tag as a distinct model, so `llama3.1:8b` and `llama3.1:8b-instruct-q4_K_M` report separately. Standardize tags across your team or your cost and quality analytics will fragment across variants of the same underlying model.

• OpenRouter best practices

  OpenRouter model IDs are routing aliases in `provider/model` form, not provider-native names. Coolhand records the alias you sent, so a change to the upstream provider behind that alias is invisible in your logs. Pin the alias you intend to compare over time before relying on its cost trend.

• ElevenLabs best practices

  ElevenLabs logs arrive from post-call transcription webhooks rather than live API interception, so they land after a conversation ends and omit fields that only exist at request time. Knowing which fields are structurally unavailable saves you from chasing gaps that are not misconfiguration.