Skip to main content

Documentation Index

Fetch the complete documentation index at: https://xerg.ai/docs/llms.txt

Use this file to discover all available pages before exploring further.

Xerg surfaces seven named finding kinds today. Two are confirmed waste, three are workflow opportunities, and two are Cursor-specific usage opportunities. For the conceptual view of how these categories are meant to be interpreted, see waste taxonomy.

Finding taxonomy

KindTerminal labelClassificationConfidenceMeaning
retry-wasteRetry wastewastehighFailed calls were followed by more work, so that spend is pure retry overhead.
loop-wasteLoop wastewastehighA run reached at least 7 iterations, and spend after iteration 5 is treated as likely loop waste.
context-outlierContext bloatopportunitymediumA workflow with at least 3 runs had one or more runs whose input token volume was far above its own baseline.
idle-spendIdle wasteopportunitymediumA workflow name looks like a recurring heartbeat, cron, monitor, or poll loop.
candidate-downgradeDowngrade candidatesopportunitylowAn expensive model appears to be used on a simple operational workflow. Treat this as an A/B test candidate.
cache-carryoverCache carryoverwastemediumA long Cursor session is carrying too much stale cached context forward.
max-mode-concentrationMax mode concentrationopportunitymediumCursor is leaning too heavily on max mode rather than escalating selectively.

What counts as confirmed waste

Only retry-waste and loop-waste count toward:
  • wasteSpendUsd
  • structuralWasteRate
  • --fail-above-waste-rate
  • --fail-above-waste-usd
The opportunity classes roll up into opportunitySpendUsd and are shown as directional savings opportunities.

Recommendation objects

When you run xerg audit --json, Xerg includes a ranked recommendations array derived from the findings. The same recommendation objects are now part of the v2 push payload as well.
FieldMeaning
idStable recommendation id
findingIdThe finding this recommendation came from
kindThe source finding kind
titleHuman-readable next step
summaryWhy this recommendation exists
priorityBucketfix_now, test_next, or watch
recommendedOrderRank within this audit after bucket and savings sorting
implementationSurfaceWhere the fix lives, such as retry_policy, model_routing, or user_behavior
categorystructural_efficiency, model_fit, context_hygiene, cadence_activity, or other
severityhigh, medium, or low
estimatedSavingsUsdExpected dollar impact
estimatedSavingsPctExpected impact as a share of total spend
confidencehigh, medium, or low
effortlow, medium, or high
scopeworkspace, source, or workflow
scopeIdStable scope identifier used for recommendation identity
scopeLabelDisplay-ready label for the scope
whereToChangeOperator-facing guidance on where the change belongs
validationPlanCompare-aware instructions for proving the result
actions2–3 concrete action bullets

Current recommendation patterns

| Finding kind | Bucket | Typical action | | --- | --- | | retry-waste | fix_now | add retry backoff or lower retry count | | loop-waste | fix_now | cap iteration depth or add an early exit | | context-outlier | test_next | trim prompt or context size | | idle-spend | test_next | reduce cadence or switch to event-driven work | | candidate-downgrade | test_next | A/B test a cheaper model | | cache-carryover | test_next | reset or summarize long Cursor chats | | max-mode-concentration | test_next | reserve max mode for the hardest Cursor turns |

What not to overread

  • Opportunity findings are directional recommendations, not proven waste.
  • A candidate-downgrade finding is intentionally low-confidence and should be treated as an experiment, not an automatic downgrade order.
  • Cost per outcome is intentionally unavailable in v0.