AI Kanban

Add task

Todo

3

In Progress

0

Staled

13
Local Claude Code context/cost readout: parser + status script + skill (+ VSCode bridge)Build a LOCAL (no network) readout of Claude Code context + cost, as one shared parser feeding three consumers. Remote sync + dashboard is a separate card. ## Deliverables (build in this order) 1. **Parser library** — reads the live session transcript, returns context size, per-turn cost, subagent cost, session total. Prototyped + validated 2026-08-01. 2. **Status script** — standalone, prints ONE line to stdout. Wire to `statusLine.command` (works in terminal today). 3. **Skill** — deep on-demand view, same parser. Works in BOTH terminal and VSCode extension today, so it unblocks the ambient-display problem. 4. **VSCode status bar bridge extension** — thin wrapper that shells out to the status script and renders stdout in the native status bar. Works in VSCode + Cursor. Build only if the skill proves insufficient. ## Verified mechanics - Transcript path: `~/.claude/projects/<cwd with / replaced by ->/<$CLAUDE_CODE_SESSION_ID>.jsonl` — verified working. - **Context size = the LAST assistant record's `input_tokens + cache_creation_input_tokens + cache_read_input_tokens`.** NOT a sum across turns (that gives cumulative usage, ~15x larger and wrong). - **CRITICAL: dedupe by `(requestId, message.id)` keeping MAX `output_tokens`.** Claude Code rewrites each assistant message to the JSONL repeatedly while streaming; early copies hold partial counts (e.g. 7 then 1505). Taking the first/last naively misreports the headline number by up to ~200x. This is the single highest-risk bug in this card. - `input_tokens` being ~0 is CORRECT — nearly all context arrives as cache_read. Do not "fix" it. - Subagent transcripts: `~/.claude/projects/<slug>/<session-id>/subagents/agent-*.jsonl` (nested one level deeper; a one-level glob misses them entirely — they were 27% of historical spend). - Pricing: cache read 0.1x input; cache write 5m 1.25x, **1h 2.0x** (`usage.cache_creation.ephemeral_{1h,5m}_input_tokens`). Sonnet 5 is on intro $2/$10 per MTok **until 2026-08-31** (list $3/$15). - Context windows: 1M for Opus 5/4.8/4.7, Sonnet 5/4.6, Fable 5; 200K Haiku 4.5. Model string may carry a `[1m]` suffix — strip before lookup. ## Status line format `◐ 43.8% (438K/1M) · turn $0.28 (+$0.11 sub) · carry $0.22/turn · ⚠ cache miss` - context % + absolute vs the model's real window - last turn cost, subagent broken out separately with `+` - **carry cost** = `context * input_price * 0.1` — what the NEXT turn costs before you type anything. The headline insight: context is a recurring bill, not a capacity gauge. On a live 438K-token session, 78% of each turn's cost was just re-reading context. - warnings: cache-prefix invalidation (large cache_creation + small cache_read => that turn cost up to 20x the cached equivalent), and context crossing a threshold ## Locked decisions - Status line REPORTS AND WARNS (not purely informational). - Subagent cost DISPLAYED, broken out separately (not silently rolled in). - Skill covers CURRENT SESSION ONLY, fully local, no network. - Scope is claude-code only — dropped the original cross-agent mirroring to cursor/antigravity (transcript format, session-id env var, and cache-tier accounting have no equivalent there). ## Performance note (VSCode bridge) Watch the project dir and read only the TAIL (~256KB) of the transcript — do not re-parse a multi-MB file on every append. Still apply max-output_tokens across copies in the tail, or the status bar flickers through partial streaming values before settling. The bridge cannot ask Claude Code which session is active (no API); infer via newest-mtime `.jsonl` in the workspace's project dir.
yesterday
Cross-machine Claude Code usage sync + dashboard UIAggregate Claude Code usage from BOTH machines into one remote DB, with a web UI for visualisation. Sibling of card #112 (local readout) — reuses the SAME parser library; build #112 first. Motivation: ccusage is accurate but per-machine by construction, and the JSONL contains NO account/org/machine identity — so cross-machine and per-account attribution can only be solved at sync time, never reconstructed later. ## Sync behaviour (locked) - **Triggers: `SessionStart` (inline upload) AND `UserPromptSubmit` (dirty-marker only, detached).** - `SessionEnd` is REJECTED — does not fire on tab close, crash, or kill -9. - `UserPromptSubmit` must NOT do network I/O inline: it runs BEFORE the model sees the prompt, so it is in the per-turn latency path and a hung connection stalls the session. It writes a dirty marker and exits (~5ms); upload happens detached. Needs a real detach — `& disown` is not always enough since Claude Code can wait on inherited fds. - `UserPromptSubmit` structurally never syncs the last turn of a session; `SessionStart` catches it on next launch. - **No cron, no launchd, no daemon.** The JSONL on disk is the durable source of truth and survives every failure mode; the hooks are freshness, not delivery. Staleness is bounded by "when you next open Claude Code on that machine" — an idle machine generates no new usage anyway. - **On failure: do nothing, exit silently.** No error surfaced into the session, no retry logic. ## Data rules - **Aggregates ONLY — transcripts NEVER leave the machine.** The JSONL contains source code, file contents, and all tool output. Ship token counts per message. Entire history is ~46K rows. - **PK `(request_id, message_id)`** — globally unique. Makes re-sync a no-op: no watermark, no "what did I already send" state to corrupt, no harm in overlapping ranges. - **Self-healing upsert** — `on conflict (request_id, message_id) do update set output_tokens = greatest(excluded.output_tokens, usage_events.output_tokens)`. This makes the streaming-partial bug IMPOSSIBLE TO PERSIST: a row written from a partial record is corrected upward on any later sync. Build this in rather than trusting the reader. - **Stamp at write time: `machine_id`, `account_uuid`, `org_uuid`** — none exist in the JSONL. `machineID` + `oauthAccount.{accountUuid,organizationUuid}` come from `~/.claude.json`. - **Store `cost_usd` computed at sync time**, plus a separate `pricing` table for audit. Do NOT compute cost at query time from current prices: Sonnet 5 intro pricing ($2/$10 vs list $3/$15) expires **2026-08-31**, and query-time pricing would silently reprice all pre-expiry history. - Include `is_subagent` (subagent transcripts are nested at `<session-id>/subagents/agent-*.jsonl`; ~27% of historical spend). ## Backfill One-shot script per machine over existing history (~46K rows, ~$5.9K of usage). Same parser, same idempotent upsert. ## Dashboard UI Web app over the synced data. Wanted views: - cost per day / per machine / per project / per model - subagent share of spend over time - cache efficiency (read vs write ratio) — spikes indicate prefix invalidation - session drill-down - optional: join `~/.claude/usage-data/session-meta/*.json` (tool counts, git commits, lines added/removed, interruptions, response latency) for cost-per-commit style metrics. NOTE: only covers 134 of 175 sessions and looks like a one-off snapshot from 2026-07-01 — verify it still regenerates before depending on it. ## Open (deferred by user until behaviour was settled) 1. **DB host** — recommend a NEW dedicated Supabase project (Supabase MCP already wired; Postgres over REST means the sync is a plain curl with no client library on either machine; RLS keeps it private). Alternatives: existing mainnet/testnet project (mixes personal telemetry into something else), or Neon via personal-infra Pulumi (consistent with existing IaC, but needs a PR/deploy cycle and free tier has a 6h retention cap). 2. **Account topology** — do both machines run under the same Anthropic account (`b7bc187e-7b55-4c62-8977-c069bffdfd83`), or is one a work account? Decides whether `account_uuid` is a constant or a real schema dimension. Recommend modelling it as a first-class column regardless, so adding a work account later needs no migration.
15 hours ago
Fix near-bankrupt sleeve inflating the 1/N blended book (fake +9193% bar)Run #28 showed a single +9193% bar (equity 5,254 -> 488,352 in one hour). Root cause found: on 2021-04-16 22:00 dogeusdt's fold equity fell 2,045 -> $1.62 (Doge squeeze over a naked short), then recovered to $1,329 = +82,002% in one bar; _blend_1n averages the 9 coins' RETURNS index-wise so that became +91.1 blended. TWO compounding causes: (1) the S4 bankruptcy floor is a knife-edge at exactly equity<=0, so a sleeve at $1.62 of $10,000 is economically dead but treated as fully alive with astronomically leveraged percentage returns; (2) _blend_1n averages percentages, implicitly re-funding every sleeve to a full 1/N each bar, so a dead sleeve's +82,000% is credited as if earned on real capital. DAMAGE: run #28 reads +409% total but that ONE bar is 92.9x — everything else is -94.5%; mean-of-fold Sharpe was -1.105 and the DSR gate still PASSED at 0.970. Run #27 (the z-ladder research run behind the "scaling-in beats single-entry, +0.366 stitched" conclusion) has the SAME artifact from the same Doge event (+1292% bar = 13.9x; everything else -87.2%), so that headline is NOT supported and the project memory + docs/features/zscore-ladder-mean-reversion/spec.md are now wrong. FIX (user approved both): (1) insolvency threshold instead of a knife-edge — liquidate and hold dead below a fraction of starting capital; (2) blend DOLLARS not percentages so a dead sleeve contributes its actual negligible capital. Then re-run #27/#28 configs for honest numbers and correct the memory + spec.
17 hours ago

Blocked

0

Need Review

9
Ladder verdict soundness: stop_z ceiling guard, baseline sizing, true B&H arm + re-run bake-offOpus audit of run #31 found the run did not test its configured strategy. FLAWS: (1) stop_z=5.0 is mathematically unreachable — RollingZScore uses statistics.pstdev over the full lookback window, so max |z| = (n-1)/sqrt(n) = 4.359 at lookback=20; 0 of 18415 trades exited on 'stop', max entry_z observed 4.3537. Combined with max_hold_bars=0 (disabled) the run had NO loss exit and NO time exit. (2) rung 2 (|z|>=4.0) fired 8 times in 15550 baskets — 84% single-entry, so the ladder thesis was barely exercised. (3) ladder_verdict.py:313 calls run_backtest with no size kwarg so the baseline arm runs at 100% of cash vs the ladder's ~33% — arms compared at ~3x different notional. (4) bah_sharpe stores the single-entry MR arm, not real buy-and-hold (run #30 stores true B&H +1.0857 in the same column) so #31 cannot answer 'should I just have held?'. (5) The gate's real comparator max(baseline,0.0) is not persisted, so the record reads as 'beat the baseline but failed'. VERDICT ON #31: the FAIL is trustworthy in direction — frictionless per-trade edge is -15.8bps over 18415 trades and 47000 OOS bars, i.e. it loses at ZERO cost; fees $120,165 vs gross-of-fee PnL -$118,566. But the ladder thesis is UNTESTED, not refuted. REFUTED (my own suspicions, checked and wrong): purge=0 is not leakage (neither arm trains a model; each fold builds a fresh engine over test_idx only). train=2000/test=1000 is BETTER than the old test=120 (47 vs 398 folds, 47000 vs 47760 OOS bars, 940 vs 7960 warm-up bars wasted). The negative-baseline gate is already correctly floored at max(baseline,0.0). No repeat of the run-#28 blowup artifact (equity never exceeds its 10000 start; largest step +3.03%). SCOPE (user-approved): guards + code fixes + re-run as a 2-config bake-off (rescaled rungs at lookback=20 vs original [2,3,4] at lookback=50), realistic costs only — no zero-cost diagnostic.
13 hours ago

Done

103
#21
P0
Integrate AI-Kanban with OpenClaw (feature idea + OpenClaw setup reference)FEATURE IDEA Integrate AI-Kanban with OpenClaw so the board can be driven from a chat channel (e.g. Telegram): create/query/move cards, get progress pings, and potentially have OpenClaw agents pick up and work cards. OpenClaw already exposes MCP tools + a paired Telegram control channel, so a thin bridge to the ai-kanban-dispatch MCP tools is the likely integration surface. --- OpenClaw local setup (reference, as of 2026-07-06) --- Host: Quan's MacBook Pro (macOS 26.5.2 arm64). OpenClaw 2026.6.11 (brew: /opt/homebrew/bin/openclaw). Config: ~/.openclaw/openclaw.json. Gateway: LaunchAgent, ws://127.0.0.1:18789. GATEWAY: was crash-looping every ~10s ("Gateway start blocked: existing config is missing gateway.mode"). Fixed with `openclaw config set gateway.mode local` + relaunch. Now listening/reachable. doctor --lint: 0 errors (only warning: gateway.auth.token stored plaintext — cosmetic). MODEL / AUTH: `openclaw configure --section model` → provider Anthropic via claude-cli OAuth (mode=oauth, profile anthropic:claude-cli) = REUSES the Claude Code subscription (no metered API key). Default model = anthropic/claude-opus-4-8 (fallbacks 4-7 / sonnet-4-6 / 4-6). Verified with a live agent turn. NOTE: subscription OAuth in a 3rd-party tool is a ToS gray area; fine for light manual use, risky for unattended. Cost on this route = Max-plan quota, not $. Switch models per-conversation from Telegram with /model <id>; /model default resets to Haiku/Opus default. TELEGRAM CHANNEL: bot @quan_vo_open_claw_bot, dmPolicy=pairing. Paired + set as command owner (telegram:1767875031, "Quan Vo") via `openclaw pairing approve telegram <code>` — only this account can command it or switch models. Inbound + outbound + agent auto-reply all confirmed working (first msg was silent due to a one-time auth-profile session reset; resend worked). BROWSER: plugin enabled. Isolated `openclaw` profile (CDP, port 18800) running. `user` profile = existing-session / chrome-mcp attach to real Chrome (where Bitwarden lives) — NOT yet wired (real Chrome not exposing a debug port; chrome-mcp bridge needed). Existing-session profiles also have some unsupported browser actions (ACT_EXISTING_SESSION_UNSUPPORTED). PRIMARY USE CASE BEING BUILT (separate from the ai-kanban integration): on-demand AWS SSO login for Claude Code's aws CLI. Flow: OpenClaw runs `aws sso login --sso-session upredict --no-browser` → navigates the printed verification URL in the real Chrome → Bitwarden autofill login (company SSO portal TTL ~1h, NO MFA) → click Confirm → Allow → token cached → aws works. Trigger = MANUAL, on demand from Telegram ("refresh my AWS login"), not a cron. Model Haiku (cheap). Hard rule: stop and ping on any unexpected page. (upredict SSO covers prod=eu-south-1 + testnet=us-east-2 DevOps — token grants both.) OPEN ITEMS 1. Wire `user` profile bridge so OpenClaw can drive the real Chrome (Bitwarden). 2. Write the "refresh aws" OpenClaw skill (pings back over Telegram). 3. Test AWS flow end-to-end. 4. (This card) design + build the AI-Kanban <-> OpenClaw bridge.
4 weeks ago