Integration proposal: Empirica epistemic measurement + context budget improvements

[Nubaeon]

Hi! 👋

We're the team behind Empirica — an epistemic measurement system for Claude Code (MIT, 130+ stars). We've been using your organizer and found a strong integration opportunity.

What we noticed

Context Budget accuracy improvements possible:

• Budget shows ~12.5K loaded + ~13.7K deferred. Claude Code's actual runtime data (context_window.cache_read_input_tokens via statusline stdin JSON) reports ~343K. The offline estimation significantly underestimates.
• CLAUDE.md shows 16 tokens when it contains @~/.claude/empirica-system-prompt.md — following @ includes would show the real 1.2K-6.3K token cost.
• Hook-based plugins (like ours with 14 hooks) have per-event latency costs, not static context costs — the budget could distinguish "always loaded" from "fires on event."

Invisible data that could be surfaced:

• .empirica/ directories per project contain epistemic measurement data (sessions, calibration, findings, goals) — ~1,800 findings and ~300 unknowns in our main project. This is invisible to the organizer but represents significant project intelligence.

Proposed integration

We've drafted a detailed proposal: EMPIRICA_INTEGRATION.md

Summary (~140 lines, 0 new dependencies):

1. Scanner: scanEpistemics(scope) — discovers .empirica/ dirs, shows session/finding counts, calibration scores
2. Context Budget: Follow @ includes for accurate token counting, add Empirica prompt cost
3. Detail panel: Epistemic summary when clicking a project with .empirica/

Everything is read-only filesystem access — no dependency on Empirica being installed.

The symbiosis

Your organizer manages config (where things are). Empirica manages intelligence (what AI knows). Together, users see both layers in one dashboard.

We also have a Chrome extension for capturing AI conversations — artifacts flow through .empirica/ and would become visible in the organizer.

Context Budget: what Claude Code actually sends

For reference, here's the full JSON that Claude Code sends to statusline commands — richer than documented:

{
  "context_window": {
    "total_input_tokens": 9916757,
    "total_output_tokens": 6892566,
    "context_window_size": 1000000,
    "current_usage": {
      "input_tokens": 1,
      "output_tokens": 1,
      "cache_creation_input_tokens": 701,
      "cache_read_input_tokens": 343106
    },
    "used_percentage": 34,
    "remaining_percentage": 66
  },
  "cost": {
    "total_cost_usd": 1213.13,
    "total_lines_added": 57142,
    "total_lines_removed": 11041
  },
  "rate_limits": {
    "five_hour": { "used_percentage": 2, "resets_at": 1774479600 },
    "seven_day": { "used_percentage": 15, "resets_at": 1774602000 }
  }
}

This runtime data could augment your offline estimates with actual numbers.

About us

David & Philipp, Vienna. Building cognitive infrastructure for AI agents. Happy to collaborate — PR, issue threads, or a call. We saw your Reddit post and reached out there too.

Branch ready: Nubaeon/claude-code-organizer → feat/empirica-integration

[ithiria894]

Thanks for the detailed write-up and for sharing the statusline stdin JSON — useful reference. The point about @ includes not being counted in token estimation is a real gap worth looking into.

I want to think through a few things before reviewing the PR. Some questions that would help me evaluate this properly:

@ import resolution

This is the most broadly useful idea here and I'd like to understand the mechanics before scoping it. How does Claude Code resolve @ includes — is this documented by Anthropic or reverse-engineered from behavior? Specifically: relative vs absolute path handling, nested includes (A imports B imports C), circular reference protection, and whether it works consistently across CLAUDE.md / skills / hooks.

Context budget comparison

Want to make sure I'm reading your numbers right. CCO's ~12.5K is an offline estimate of config/system prompt tokens. The 343K from cache_read_input_tokens includes the full conversation context — prompt, history, tool definitions, everything. These seem like fundamentally different measurements rather than a gap in accuracy. Could you break down what portion was actually config vs conversation? Also — is there anything in the statusline stdin JSON beyond what's in the Claude Code docs on statusline commands? Want to understand what's new here vs already documented.

Epistemic vector reliability

This is important for me to understand before evaluating any integration. The vectors are self-reported by the same model that's doing the work — how do you validate that the scores are accurate? Specifically: at the CHECK gate, when the system decides proceed vs investigate, the ground truth (test results, git diff) doesn't exist yet. So what's the gate decision actually based on at that point? And how does calibration work across sessions given that LLMs don't carry state between sessions? I'd want to see data on how well self-reported scores correlate with actual outcomes.

User story for epistemic data in the organizer

CCO is an on-demand tool — users open it, review config, clean up, close it. Not a live monitoring surface. If we surface .empirica/ data (calibration scores, vectors, findings) in that context — what does the user do with it? When someone opens the organizer and sees "know: 0.75, uncertainty: 0.30" from a session that ended hours ago, what decision does that help them make? Want to understand the concrete user action.

---

Would be great if you could open 4 separate Discussion threads for these under the Ideas category — one per topic. That way each gets its own space and others can weigh in too.