Skip to main content
Every chart in Analytics can be split by client. The client name comes from the MCP handshake: when a client connects, it announces itself with a name of its own choosing. Nobody standardizes those names, so Alpic maps them to a canonical list before showing them to you.

​
Why the raw names need mapping

Three things happen with raw client names, and all three make a breakdown harder to read than it needs to be.
  • Vendors rename their clients. Claude.ai used to announce itself as claude-ai and now sends Anthropic/ClaudeAI. Codex moved from codex-mcp-client to openai-mcp (Codex), and that switch is still in progress, so its traffic is split across both names right now. Older builds keep sending the old name for months, so without mapping the same product shows up as two rows forever.
  • Proxies add their own version to the name. A client reached through mcp-remote announces itself as claude-code (via mcp-remote 0.1.37), so one client turns into one row per release of the proxy.
  • Clients that never set a name still send one. The Python MCP SDK defaults clientInfo.name to mcp, so a large share of traffic arrives under a name that means nothing.

​
What Alpic does

Alpic keeps a list of the clients it recognizes and folds every name a vendor has shipped for the same product into one row. claude-ai and Anthropic/ClaudeAI both count as Claude. codex-mcp-client and openai-mcp (Codex) both count as Codex. Proxy versions are stripped before the lookup, so all mcp-remote variants of a client land on that client. Surfaces stay separate. Claude Code, Claude, Claude Cowork and the Anthropic API each get their own row under the same vendor logo, and so do ChatGPT, Codex and the Responses API under OpenAI’s. They are different ways of using your server, so you probably want to tell them apart. A name Alpic does not recognize is left alone. It gets its own row, spelled exactly as it was received, without a logo. Alpic will not guess at what it is, and neither should you read too much into it: on a private server these are usually your own agents, scripts and uptime probes, but on a public server anyone can connect under any name they like. One row deserves an explanation: Unnamed client is traffic that sent no name at all, so all Alpic received was the SDK default. There is nothing more to say about it, it could be any client or script.

​
What to keep in mind when reading the breakdown

  • The client breakdown counts connections, not engagement. A session is one MCP handshake, and every client reconnects on its own schedule. Claude Code handshakes when a conversation starts and again whenever it considers what it knows about your server stale, whether or not it ends up calling a tool, so it racks up handshakes with very few tool calls behind them. A client like the Alpic Playground is the other way round, several tool calls per handshake. A tall bar means a client connects a lot, not that people are using your server through it a lot. Look at tool calls for that.
  • OpenAI surfaces cannot always be told apart. Every OpenAI surface used the same openai-mcp name before they started adding a suffix, so ChatGPT, the Responses API and Agent Builder are mixed together in the OpenAI Other row. A number labelled ChatGPT is therefore a floor, not a total. Vendor-level OpenAI totals are reliable.
  • Client names are self-reported. Anything can claim any name in the handshake. Alpic shows the mapped name for readability and nothing more: it is never used to authenticate or authorize a request, and the vendor logos are decoration, not verification.
  • Raw names are always available. Filtering and the session list use the exact name received, so you can still search for claude-ai or your own agent name and find those sessions.