If you searched for "prompt tracking," you probably landed here from one of two very different problems. Both are real. Both have tooling. They almost never need the same tool.
This is a guide to telling them apart in under five minutes, with honest pointers to the tools that fit each one.
The two things "prompt tracking" can mean
Tracking the prompts your application sends to an LLM API. You're building a product that calls Claude, GPT, or Gemini behind the scenes. You want to know which prompts your app is sending in production, what they cost, how they're performing, when they fail, and how a model change affects them. The unit of work is one API call (or one chain of API calls in a tool-use loop). The audience is the engineer who owns the LLM integration.
Tracking the prompts your team uses when coding with an AI agent. Your engineers spend their day inside Claude Code, the Codex CLI, or Cursor. The reasoning that used to happen in Slack threads and design reviews now happens inside those agent sessions. You want to know what threads exist, what they produced, and how to make the valuable ones reusable. The unit of work is one session (a conversation with the model that may span hours). The audience is the engineering manager and the team.
These are different problems, served by different categories of tool. Mixing them up is the most common mistake we see when teams start asking about "prompt tracking."
Category A: LLM API call logging
You want this if you're shipping a product that calls an LLM as part of its runtime. The questions you're answering are:
- Which prompts is my application actually sending?
- How much is each one costing in tokens?
- What's the latency distribution per prompt template?
- When the model returns garbage, what was the prompt?
- If I switch from one model to another, what changes?
The tools in this category sit between your application and the LLM API. They log every request and response, surface usage and cost metrics, and often let you replay prompts against different models for evaluation.
Established options:
- PromptLayer: one of the originals; emphasizes prompt versioning and tagging.
- Helicone: proxy-based observability with a generous free tier.
- Langfuse: open source, self-hostable, popular in LLM-first products.
- LangSmith: tightly integrated with LangChain.
If you're trying to answer "which prompt is my app sending and what does it cost," pick one of these. They are not what Lore is.
Category B: Coding-agent session sharing
You want this if your team uses Claude Code, Codex, Cowork, or another coding agent every day, and the reasoning behind your codebase has moved from Slack threads and design docs into individual agent sessions. The questions you're answering are:
- Which agent threads exist across the team?
- When someone solves a hard problem, can others learn from how they prompted, debugged, and recovered?
- When something breaks three months from now, can I find the session that produced that code?
- When a new hire joins, can I show them how the team actually works with these tools?
The tools in this category sit next to your coding agent, not between it and an API. They capture sessions when you ask them to, turn them into URLs your team can read, and make them searchable across the workspace.
This is what Lore does. Run /share inside a Claude Code or Cowork session, or /share-codex inside a Codex session, and you get a URL. The session is searchable, linkable, and replyable.
A two-question decision
The fastest way to tell which one you need:
1. Is the AI inside your product, or inside your team?
If the AI is inside your product (your application calls an LLM API as part of its runtime), you need Category A.
If the AI is inside your team (your engineers use an AI agent to write the code that ships), you need Category B.
2. What's the unit you want to track?
If you're tracking individual API calls, you need Category A.
If you're tracking sessions and conversations, you need Category B.
Most engineering organizations need Category B. Most LLM-first product companies need both: Category A for their app's runtime, Category B for the engineers building it.
What if you need both
The categories don't overlap. You can run Helicone on your application's LLM API calls and Lore on your engineers' Claude Code sessions, and neither tool knows the other exists. There is no integration to set up because there's nothing to integrate.
If your team is mostly Claude Code users and you're trying to choose where to start, Category B has more leverage. The reasoning behind your codebase is more valuable to capture than any single API call.
Why this matters more than the search term suggests
The reason "prompt tracking" is a confusing search term is that the AI era has split engineering work into two visible surfaces: the LLM calls a product makes, and the AI sessions an engineer runs. Both produce streams of prompts that nobody fully sees. The instinct to capture them is correct. The tools that capture each one are different.
If you're an engineering manager whose team has gone from typing assistance to thinking assistance over the past year, the gap that's about to bite you isn't your application's prompt logs. It's your team's session reasoning. That's what Lore is built to make legible.