What Signals helps you find
Repeated restarts
Find work that keeps restarting on the same project instead of continuing from a useful handoff.
Missing project context
Find files that everyone keeps reopening because the important project knowledge is not documented once.
Exploration-heavy sessions
Find sessions with lots of reading and searching but little or no landing work.
Waiting sessions
Find sessions where the assistant responded, then the next user prompt arrived after the configured wait threshold.
Session bloat
Find sessions that continue past a user’s normal completion point while context keeps growing.
Model mismatch
Find repeatable cases where a costly model appears to be used for work that matched lighter-model sessions complete comparably.
Current pattern set
Signals currently covers ten workflow patterns:Signals are calibrated as investigation leads. Always open the evidence before changing policy, coaching a user, or treating a finding as confirmed waste.
Personal and enterprise views
Individual users can use Signals to understand why their own sessions or projects are expensive. The MCPsignals tool can return open workflow-efficiency findings for the current project and user.
Enterprise admins get broader scope. They can review open findings across members, projects, teams, and the organization, then drill into the exact sessions behind each pattern.
- Developer workflow
- Enterprise workflow
Use Signals when you want to understand why your current project has become expensive or repetitive.The assistant can use the RCLM MCP server to return current findings without changing your project.
How Signals are calculated
Signals are calculated from captured session metadata, normalized tool calls, project names, team membership, policy snapshots, model usage, provider-reported token data, and session similarity data. The backend evaluates patterns over a trailing weekly period. It records a score for evaluated patterns and creates an open signal only when the pattern crosses its threshold. Examples:P2counts repeated reads of the same canonical file across sessions.P3compares exploration calls to edit calls.P4counts sessions with at least one assistant-to-next-user wait over the configured threshold. The default threshold is 20 minutes.P5compares a session to the user’s own baseline rather than a global constant.P8requires conservative cross-team similarity evidence before it fires.P10compares model choices only within matched user, project, and task-category contexts.
Acting on a signal
1
Read the pattern code
The code tells you what kind of workflow problem to investigate. For example,
P4 means sessions waited over the configured threshold; it does not prove the user was blocked.2
Open the evidence
Review the linked sessions, files, models, projects, or teams. Confirm whether the examples match the pattern.
3
Choose the fix type
Habit issues need workflow changes. Project issues need durable context. Team issues need process changes. Org issues need policy or installation repair.
4
Check the next period
Signals refresh through backend jobs and backfills. Recheck after the next run before assuming a change worked.
Limits
- Missing or incomplete captured sessions mean missing evidence.
- Some patterns need provider-reported token or cache data.
- Waiting time does not explain why the user waited.
- Similarity and model-comparison patterns are conservative by design.
- Signals should reduce the search space, not replace human review.
Enterprise Signals reference
Read the full P1-P10 pattern reference, including calculation details, examples, and admin actions.
MCP Server
Use the
signals MCP tool from an AI coding assistant to inspect current workflow-efficiency findings.