Skip to main content
Tracking whether Claude Code or Cursor recommends your API is fundamentally different from tracking whether ChatGPT mentions your brand. Answer engines produce prose; coding agents produce working code, execute it, and switch to a competitor the moment something breaks. That shift changes what you need to measure — and Lightsage is built around those distinctions.

Why coding agent tracking is different

When a developer asks an answer engine “what’s the best payments API?”, the engine responds with text. Your goal is to appear in that text. When the same developer asks Claude Code “add payments to my Next.js app”, the agent recommends an SDK, writes an npm install command, generates integration code, runs it, and debugs any errors. If the generated code fails and the agent can’t recover, it recommends an alternative — and you never know you lost the deal. This means two failure modes exist that answer engine tracking can’t see:
  • High visibility + low usability. Agents recommend you, but the generated code fails. You are scaling frustrated developers, not adoption.
  • Low visibility + high usability. Your API works flawlessly with agents, but agents never suggest it. That is a missed opportunity you can fix.
Lightsage tracks both dimensions across 10 coding agents — Claude Code, OpenAI Codex, Cursor, GitHub Copilot, Gemini CLI, OpenClaw, OpenCode, Hermes, Pi, and Kilo — plus 7 answer engines.

Metrics to monitor

Recommendation rate

How often does a coding agent suggest your API when given a relevant implementation prompt? Measures visibility at the moment the developer asks for help.

Tool call success rate

When an agent writes code using your API and executes it, what percentage of attempts succeed? This is the usability signal that answer engine tools miss.

Error recovery rate

When agent-generated code fails, how often can the agent troubleshoot and fix the error without switching to a competitor? Directly tied to your error message quality.

Completion rate

Does the agent finish the task using your API, or does it abandon mid-task and recommend an alternative? Abandonment is a leading indicator of DX problems.

Benchmark thresholds

Use these ranges to interpret your dashboard numbers after you have at least two weeks of data:
These thresholds apply to implementation prompts targeted at your API’s core use cases. Broad category prompts — “add payments to my app” vs. “add [Your API] to my app” — will show lower recommendation rates by design, since you compete with every alternative in the category.

Defining implementation prompts

The prompts you track are the foundation of your measurement. A good implementation prompt reflects what a developer would actually type into a coding agent when they want to use your API. There are three prompt types to define before you start tracking: Implementation prompts — Direct integration tasks:
  • “Add [Your API] to my Next.js app”
  • “Set up [Your API] authentication in my Express backend”
  • “Connect [Your API] webhooks to my Vercel deployment”
Integration prompts — Connecting your API with another service:
  • “Integrate [Your API] with Supabase”
  • “Use [Your API] alongside Auth0 in my app”
Troubleshooting prompts — Error and debugging scenarios:
  • “Fix [Your API] 401 error in my code”
  • “Debug [Your API] webhook not firing”
Start with three to five prompts covering your top use cases. You can expand the set once you have baseline data.

Setting up tracking in Lightsage

1

Create your API profile

Go to your Lightsage dashboard and add your API. Include your API name, SDK package names (npm, PyPI, etc.), and the primary competitors you want to track share-of-voice against.
2

Define implementation prompts

Add your implementation, integration, and troubleshooting prompts. Lightsage runs these prompts across all 10 coding agents on a daily schedule. Aim for at least three prompts per core use case.
3

Select agent coverage

Choose which coding agents to prioritize. Start with Claude Code, Codex, and Cursor — they account for the largest share of usage and have the most developed ecosystems. You can add the remaining agents as your baseline matures.
4

Establish your baseline

Let Lightsage run for at least one week before making any optimizations. Record your starting numbers for each metric and each prompt. This baseline is the reference point for measuring whether changes are working.
5

Connect agent visit tracking (optional)

Install the Lightsage middleware on your docs site to see when coding agents crawl your documentation. This adds a real-world signal to the prompt-based tracking. See Detect AI agent visits with agent tracking middleware for setup instructions.

Review cadence

Each week, check for:
  • Share-of-voice shifts — did any competitor gain or lose significant recommendation rate?
  • Completion rate drops — a sudden drop often signals a new error pattern or a breaking change
  • Prompt-level anomalies — if one prompt underperforms the others, it points to a specific gap in your docs or DX
Weekly reviews should take 15 minutes. The goal is catching regressions before they compound.

Reading the Lightsage dashboard

Visibility Score — An aggregate of your recommendation rate across all tracked prompts and all selected coding agents. Use this as your headline number for sharing progress with the team. Share of Voice — Your recommendation rate relative to the competitors you track. A declining share of voice means a competitor is gaining ground even if your absolute numbers are stable. Tool Call Success Rate by Agent — Broken down by coding agent. If Claude Code shows 85% success but Codex shows 42%, the problem is agent-specific and likely tied to how that agent generates code for your SDK, not a universal DX issue. Error Recovery Rate — Tracks how often an agent successfully recovers from a failed API call. Low recovery rate usually means your error messages are too generic. See Optimize your API for AI coding agent discovery for how to fix this. Completion Rate — Tracks full task completion. Abandonment events — where the agent switches to a competitor mid-task — appear here.

Warning signs to act on

High visibility + low usability. Your recommendation rate is strong but tool call success and completion rate are low. This means agents are choosing you but failing to use you. Developers are hitting broken integrations at scale. Prioritize error message quality and DX fixes immediately.
Low visibility + high usability. Your tool call success rate is excellent but your recommendation rate is low. Agents either can’t find you or don’t know when to suggest you. Focus on Layer 2 (web search, robots.txt, comparison pages) and Layer 3 (llms.txt, MCP) optimizations.
Declining share of voice. Your absolute numbers are stable but a competitor is growing faster. Check whether they recently shipped an MCP server, published comparison content, or fixed their robots.txt. The Devtool Arena leaderboard tracks these signals publicly.

Next steps

Once you have a baseline, use it to prioritize your optimization work: