Which AI coding tools are your developers using?

Two different questions wear the same words

When somebody asks which AI coding tools their developers are using, they mean one of two things, and the two need completely different instruments.

• Inventory. Of the tools we know about and pay for, who is actually using which, how much, and in which codebases?
• Discovery. What is running that nobody told us about, on whose machine, paid for by whom?

Most of this category sells the first and lets you assume the second. It is worth being exact about which one you are buying, because a tool that answers the inventory question will answer it confidently and will never once tell you about the thing it cannot see.

What Synopt can tell you

The inventory question, on macOS, for three tools, on the machines where the agent is installed.

• Which of Claude Code, Codex CLI and Cursor IDE produced events, broken down by engineer, team, repository, branch and day.
• A locally detected billing profile per engineer and tool: subscription, API-metered, mixed, or unknown, with the plan where it resolves to one. That is presence without usage, which is how a seat nobody uses becomes visible.
• Which machines are reporting, which have gone quiet, and which are paused.

The second bullet is the one that pays for itself. A row that says subscription seat, plan known, zero events this month is a cancellation, and it needed no discovery capability at all: just the seat list and the activity list, joined.

What it cannot tell you

This list is on the public site as well, and it is here because a page about which tools are in use is exactly where an unmarked gap does the most damage.

• Tools nobody told you about. Shadow-AI discovery is not shipped. The agent reports the three tools it has readers for, and it does not go looking for a fourth.
• GitHub Copilot and ChatGPT. There is no reader for their log formats, so their events are dropped rather than guessed at.
• Cursor CLI and Cursor's Background Agents. Synopt captures Cursor IDE only, and Cursor's own analytics does not cover those two either.
• Anything on a Mac without the agent, and anything at all on Windows or Linux. There is no Windows agent and no Linux agent.
• Anything on a machine where collection is paused.

The pause is deliberate and it is not covert. An engineer can pause collection on their own machine for any duration, there is no administrator setting that overrides it, and the machine reports itself as paused rather than as silent. So no activity and not collecting are different states on the screen. If you need a tool where the org can force collection on, this is not that tool, and it is not going to become one.

AI Code Tracking has not been implemented for Background Agents, or the Cursor CLI yet.

What presence detection actually looks at

Worth knowing, because it explains the shape of the limit. The agent decides a tool is present by looking for what that tool leaves on disk: ~/.claude/settings.json or claude on PATH, ~/.codex/config.toml or codex on PATH, ~/.cursor/hooks.json or Cursor.app in Applications.

That is a list of three known signatures, checked. It is not a search of the filesystem, not a process scan, and not a network watch, so a tool that is not on the list produces no signal of any kind. Any product that does discovery properly has to work from something unbounded, which is a different design with different privacy consequences.

If you actually need discovery, look here

These are the places that answer the discovery question, none of them are us, and most of them are already running in your company.

• Network egress and DNS logs. Requests from engineer machines to model provider API endpoints are the strongest single signal available, and your existing network tooling probably already records them.
• Your identity provider's application inventory. Anything that authenticates through SSO appears there whether or not anybody filed a request for it.
• Expense reports. A personal subscription on a personal card, reimbursed, is the classic path for a tool nobody approved. Finance can query that today, with no new software.
• MDM software inventory, if you run MDM. It lists installed applications, which is the question, asked directly.
• Ask people. An anonymous survey with no consequences attached, from someone credible, gets a more honest answer faster than any of the above, and it is the only method on this list that finds a browser tab.

We would rather point you at those than sell you a capability we do not have. If discovery is the actual requirement, start with network and identity, and treat any endpoint product's answer as a floor.

When is an endpoint agent the right instrument?

When the question has moved on from what is out there to how is it being used. Network logs will tell you that forty machines talked to an API endpoint. They will not tell you which repository the work happened in, what it cost, whether the edits were accepted, or whether a credential went into a prompt. That is the layer an endpoint agent is for, and it is a layer above discovery rather than a replacement for it.

The practical sequence, if you are starting from nothing: find the surface area with network and identity data, standardise on a small number of tools, then instrument those properly. Buying the instrument first gets you a precise measurement of the part you already knew about.