Snapshot of the three tracked domains. Full detail on the Nodes tab; what changed and when on Version History.
Cowork exposes no per-session or per-model token telemetry, so this is a transparent turn-weighted estimator calibrated against one real Settings > Usage reading — provisional, not a settled constant, recalibrated whenever a fresh reading lands. Full methodology, weighting rationale, and worked examples: CL07 claude-session-load.md; raw weekly data points: outputs/usage-capacity-ledger.md.
Weekly Usage % ≈ k × Σ(turns × weight) — weight 3 for browser-automation/screenshot-heavy turns, 2 for large-context/audit/research turns, 1 for routine text-only turns. Example: a 200-turn browser session ≈ 200×3×0.0118 ≈ 7.1% of the week's quota by itself. This is a fallback for sessions you can't inspect directly — always prefer a direct read_transcript count when a session is inspectable.2026-08-05: the CL07 formula is now a hard-coded, live-computed field (DATA.usage_formula) instead of descriptive text only — enter turn counts by class below for an instant estimated %. This does not replace a real Settings > Usage reading (the stat pill above); it's an estimate, labeled as such per CL07's own convention, for sessions you can't or haven't measured directly.
Pulled via mcp__session_info__list_sessions during this dashboard update — a real, current count of inspectable sessions, not a modeled figure. This number is refreshed whenever Claude is actively working in this KB (system-document regen, dashboard updates, etc.); it is not part of the automated daily launchd refresh, since that runs as a standalone script with no access to session-introspection tools. Treat the "as of" date as the actual freshness of this number.
Every real list_sessions pull ever taken in this KB, appended chronologically — not overwritten. Continues from the 2026-07-10 anchor date forward, and keeps growing every time outputs/dean-dashboard-live/update_session_snapshot.py is run with a fresh count during a future rebuild. Distinct from the Era-trend table below (that one is a one-time judgment-call classification of ~48% usage concentration; this one is a plain running count with no classification attached).
| Date | Sessions | Running | Δ since prior |
|---|
2026-08-05: now data-driven and extendable via outputs/dean-dashboard-live/update_era_trend.py instead of hand-edited HTML rows — each new era's heavy-ratio is computed by matching session names against the known scheduled-task registry (same method as the original 2026-07-10 census), a real per-count classification, not a usage-share measurement (only the 07-10 row's ~48% figure is a real turn-weighted usage measurement — do not read other rows' ratios the same way).
| Era | Sessions | Heavy ratio | Dominant register |
|---|
claude-session-load.md §Case Study + §Forward capacity planning · outputs/usage-capacity-ledger.md · outputs/usage-capacity-audit-2026-06-12-to-2026-07-10.md. Cross-referenced on the Economics tab's "Where the credits go" section (this tab is the dedicated, current-state view; Economics keeps the cost-modeling angle).Everything logged in the KB for the Gravitas Universe platform, in one place — headline stats, live platform status, the build timeline, current active work, recent activity, and open items. Sourced verbatim from outputs/gravitas/gravitas-dashboard-progress-summary-2026-09-11.md; refreshed weekly as an extension of the existing weekly-review-friday scheduled task.
Snapshot from the most recent verified BUILD-NETLIFY-DEPLOY.command run — deploy footprint, per-asset-folder breakdown, source LOC, and capstone-minigame/character-portrait coverage. Written every real build to outputs/gravitas-build-metrics-latest.json (+ trend history in outputs/gravitas-build-metrics-history.jsonl); not on the daily launchd refresh — updates whenever a build actually runs.
| Folder | Files | Size (MB) |
|---|
weekly-review-friday.Every gravitas-suite-*.zip pushed, from the first playable build through today — — build days, — zips traced. Click a day to see exactly what shipped and every zip filename from that day. Continuously updating: outputs/dean-dashboard-live/update_deploy_timeline.py re-reads outputs/gravitas-build-metrics-history.jsonl (written by every real BUILD-NETLIFY-DEPLOY.command run) and regenerates this tab — no hand-editing required for any future build.
outputs/gravitas-build-metrics-history.jsonl, live since 2026-08-14. Earlier zip filenames + what-shipped descriptions (2026-07-03 → 2026-08-13) are sourced from changelog-lanes, LONG-TERM-MEMORY.md, and wiki GU/GG articles — see each day's own citation. This traces 91 of the zip filenames found across the KB; a handful of the very earliest iterative variants predate any per-build log and are not individually distinguishable beyond their filename.Every tracked node, grouped by domain. version_added marks which dashboard version first surfaced it.
One entry per check that produced a real change. INIT first build · PATCH a node updated · MINOR a node added or structural change · NOOP checks (nothing changed) are logged to the refresh log only, not here, to keep this list signal-only.
A complete file-based agentic operating system, from a Karpathy-pattern seed to an externally-benchmarked, multi-machine fleet. Click a phase to see its milestones.
Plain markdown on local disk, governed by a two-level router. Everything reads from a three-file session start, routes down to content, and syncs off-machine.
claude-system-architecture.md was refreshed 2026-07-04 and now correctly documents the current active-tasks system (checkpoints explicitly labeled deprecated). Verified current as of 2026-07-17 — no longer stale.Copying files reproduces the library. Adopting these seventeen findings reproduces the system. Ordered by leverage; gold = highest.
Two paths. Clone Dean's exact KB for a same-operator machine, or fresh-build the architecture for a separate persona with its own data.
Last full refresh 2026-07-30 (v6, living process — see below), 10 rated entries, cumulative since the 2026-06-29 baseline snapshot. Ahead on governance/concurrency-safety, at parity on core memory-consolidation practice, four honest open gaps (context-editing automation, multi-agent orchestration, prompt-injection standard mapping, no external reliability benchmark run against this KB itself), one trade re-validated against new field data.
What the system saved, what it costs to run, and what a comparably-skilled engineer would spend to build it from scratch. No raw billing telemetry exists — credit figures are a transparent model (frequency × model tier × token cost), labeled measured / modeled / estimated, now anchored to periodic real Settings > Usage readings starting 2026-07-10.
~440 man-hours (280–660) = 2.2 FTE = ~$23.5K wages avoided in 5 weeks. Top roles: Software Dev + Knowledge Manager — not admin. (OP13)
The recurring operation displaces ~$150K–$250K/yr in labor once one-time build spikes are stripped.
Same output ordered from agencies: $70K–$236K (mid ~$150K). The Gravitas platform drives the high end.
Comparable-skill solo engineer to reproduce the apparatus: ~460 hrs (300–630) × $100–175/h = ~$60K ($30K–$110K), 3–6 months. Actual: ~150 operator-hrs + ~$300 tooling → ~3× compression, >95% cash saving.
Gravitas has outgrown its original 40/70/110-hour placeholder line in OP11 by roughly two orders of magnitude — this is a dedicated single-project deep dive, same bottom-up method as the lenses above, six line items each sourced to a named market rate (RocketBrush · Toadhouse real invoices · Centus · Alconost · Upwork/Salary.com/ZipRecruiter/Glassdoor). Full methodology + every source: OP38.
42,773 lines career-track / 81,752 total scenario lines, 12 tracks. Two independent methods (LOC-based, eLearning-hours proxy) cross-checked. $156K–$365K.
488 files / 38 characters (~12.8 imgs/character). Toadhouse real invoices (floor) vs. RocketBrush 2026 studio rate card (ceiling). $15.6K–$190K.
~294K words at full target scope (Gate: 11 locales; minigame suite: es-MX shipped + 9 more in progress) + LQA overhead. $34K–$106K.
91 deploy pushes / 20 build days (incl. a 15-rebuild single day); aria-live + reduced-motion across 12 tracks; deploy scripting & guardrails. $3.5K–$13.8K combined.
raw/20260821_gravitas_devvalue_research_digest.md.Settings>Usage read 26% weekly / Fable 0%. Turn-weighted attribution: ONE browser-automation session (character factory, 350 turns) ≈ 48% of that week's usage alone — 9× past its 40-call checkpoint threshold, none fired. Formula k≈0.0118%/weighted-turn calibrated from this reading — provisional, not a cardinal rule. Full detail: CL07 claude-session-load.md; trend: outputs/usage-capacity-ledger.md.
The census above first shipped historical turn counts marked "not measured, too costly" — untested, and wrong; 3 real read_transcript pulls came back cheap. Found: at least one session_id spans multiple day-resets (session_id ≠ work-unit). Fix rolled forward into planning: weekly-review-friday Step 4C computes a weekly capacity budget/headroom; daily-briefing's Monday run surfaces it (no re-computation). Full diff for Jim: outputs/jim-update-audit-2026-07-10.md.
~25 long Sonnet runs/week (curiosity, kaisen, youtube, claude-opt). #1 recurring sink.
browser_batch embeds base64 images — ~10× a text-tool flow. #1 per-session burn.
~7× token multiplier. Powerful fan-out, priciest per unit of work.
~22K tokens across 4 core files × ~20 daily runs = a fixed daily floor. (Halved by CLAUDE 512→265.)
Highest per token, low frequency (Gravitas strategy, decisions, contradiction resolution).
Haiku mechanical tasks, disabled one-time reminders (zero cost), routed pointer-memory, short briefings.
Text-tools over screenshots (~10×) · JIT routing (~4.7K tok/session) · CLAUDE 512→265 (~½ read cost) · spent-output pruning · Advisor (11%) · suppress-explanations (30–50%) · no vector DB · task condensation · lane system (kills re-read waste).
Done 2026-07-01: nightly research consolidated (4→1) · frequency-tuned (YouTube + Claude-opt → M/W/F) · JIT loading rule. Remaining: Haiku-first (interactive / API only — no model param on tasks) · n8n/API migration (tabled) · skill-chains (already CL03 standard).
Three phone-native videos showing the KB's growth over time, built from the same dated snapshots the System Map's own Timeline panel scrubs through — bubble-style (cluster circle-packing), connection-map style (force-directed node-link, matching the System Map's own Panel B/F), and a stacked-column "KB size by kind" build-up. All three regenerate automatically every time a new snapshot lands from a SYS06 rebuild — loading…
Re-encoded 2026-09-08 at 1080px width (up from 640px), CRF 22 / medium preset (was ultrafast) — per kb-growth-timeline-video-format-redesign-research-2026-09-08.md (CL72). Each player keeps its source's native aspect ratio (portrait for bubbles/connections, landscape for category-bars) rather than being forced to a uniform 16:9 — a deliberate deviation from the research's literal recommendation, to avoid disturbing content deliberately fitted to those frames without a way to visually re-verify the crop. "Bigger" is delivered via resolution + CSS intrinsic-ratio sizing (no collapsed-height risk on slow loads) instead.
The live five-panel map: Panel A the operating architecture as a labeled concept map · Panel B the FULL KB content graph — every tracked .md file in the KB, not just registered wiki articles — grouped by topic, Canvas-rendered for scale · Panel C the citation network — typed edges (Internal Findings / Wiki Cross-link / Raw Source / Task Output) traced from the KB's own [EXT]/[INT]/[WIKI]/[RAW]/[TASK] citation markers, colored by type · Panel D knowledge clusters — the clean, registered-wiki-only view (242 articles) grouped by domain · Panel E File References — directed, arrowed edges showing exactly which file references which, typed/colored by mechanism (article-code mention / markdown link / the KB's own "→ file.md" arrow convention), styled after Jim's autelligence-command.pages.dev KB Graph tab; click any node for an ID/domain/degree/hub/isolated info card. Panel E also formalizes the relationship between the content graph and the citation network: of 126 formal citations, 91 (72.2%) are backed by a discoverable structural link, 35 are narrative-only citations with no matching link, and the graph carries 13,590 structural links that were never formally cited — most links in the KB simply aren't citation-marked prose, which only appears inside wiki articles. Panels B and D also carry a ⇄ Direction toggle (top-left, below the search box): off by default (undirected, single-color, easiest to scan by topic); switch it on for directed arrows colored by each edge's source node's cluster, so you can see at a glance where a region's outbound connections are headed. Panels C/D/E added 2026-07-17 per Dean's directives; the direction toggle added same day. If the frame is blank, open system-concept-map.html directly (it sits beside this file in outputs/).
Panel B — content graph (FULL KB): 3,063 files · 13,690 links · 315 hubs · 674 isolated (no detected cross-refs — mostly changelog-lane archives and raw source dumps) · 52 topic clusters. Panel C — citation network: 120 nodes · 143 typed edges (INT 65 / WIKI 42 / RAW 28 / TASK 8) · 411 external citations counted (not graphed). Panel D — knowledge clusters: 443 registered wiki articles · 2,493 links · 115 hubs · 9 isolated. Panel E — file references: same 3,063 files/13,690 edges as Panel B, directed + typed by mechanism. Panel A — architecture map: 31 nodes / 7 subsystems. Full-pipeline rebuild 2026-08-21 (mandate: any dashboard-touching task — rebuild, feature add, or content fix — runs this whole chain, no lighter path, per the 2026-08-21 SOP hardening — SYS07). Source builders: outputs/build_full_kb_graph.py, outputs/build_citation_graph.py, outputs/rebuild_kb_adjacency.py, outputs/build_edge_reconciliation.py + outputs/build_system_concept_map.py.