DSPy 3.2.1 ships a dspy.utils.usage_tracker.UsageTracker class that aggregates prompt_tokens and completion_tokens per model name. It's wired into LM.forward() — after every litellm call, if dspy.settings.usage_tracker is not None, it calls usage_tracker.add_usage(self.model, dict(getattr(results, 'usage', {}))). Enable it with dspy.configure(track_usage=True), then read totals via dspy.settings.usage_tracker.get_total_tokens() which returns {model_name: {prompt_tokens: N, completion_tokens: M, ...}}. The tracker merges nested Pydantic usage objects (like litellm's PromptTokensDetailsWrapper) into flat dicts.
However, it's disabled by default (dspy.settings.usage_tracker is None), not mentioned in DSPy's main docs or getting-started guides, and the class lives in dspy.utils.usage_tracker — not exported from the top-level dspy namespace. Most users building DSPy pipelines never discover it exists.
For production cost tracking, the UsageTracker is useful for per-pipeline-run token summaries but has limitations: it's an in-memory accumulator with no persistence, no cost calculation, and no subsystem attribution. For cross-request observability, a litellm CustomLogger callback (litellm.callbacks = [YourLogger()]) is more practical — it fires on every litellm completion (including DSPy's), receives the full response object with usage data, and can persist/forward to any analytics system. The two approaches are complementary: UsageTracker for quick per-run totals during development, litellm callback for production observability.