uwuclxdy/clauth

Current behaviour Burn-aware switching (Config tab switch mode = burn-aware, burn_aware_switching in config.toml) projects an account's 5h utilization forward from its recent burn rate. That rate comes from the OAuth history series (usage_history.jsonl), which only the Claude OAuth fetch leg writes. An account clauth judges on its provider's windows (Profile::usage_cache_is_third_party: any provider-recognised or generic api-key endpoint account, with or without an OAuth login beside it) has no series of its provider window. An OAuth login beside the key builds one for the Anthropic pool, which is never this account's rate. So every projection site skips it: the burn-aware walk (is_exhausted_active_from_usage in src/fallback.rs) returns window.utilization >= member.threshold when third_party is set App::burn_rate_for in src/tui/app.rs returns None for such a profile, so the TUI's startup one-shot (startup_rate) passes no rate, and the Overview's projected-switch line (projected_switch

Current state src/providers/mod.rs owns ms_to_iso, the epoch-ms -> ISO helper, and src/daemon/status_json.rs reaches into providers for it since #118. Its sibling epoch_secs_to_iso lives in src/usage/fetch.rs and is re-exported from crate::usage. src/daemon/gateway.rs still converts by hand: epoch_secs_to_iso((tick.wall_ms / 1000) as i64). Expected ms_to_iso lives next to epoch_secs_to_iso in src/usage/fetch.rs and is re-exported from crate::usage the same way. The z.ai, Alibaba and MiniMax providers, status_json.rs and gateway.rs all call it, and every published timestamp stays byte-identical. Where to look src/providers/mod.rs: ms_to_iso and its tests in tests/inline/providers.rs src/usage/fetch.rs: epoch_secs_to_iso src/daemon/status_json.rs: iso_from_ms src/daemon/gateway.rs: the wall_ms conversion Acceptance no hand-written / 1000) as i64 feeding epoch_secs_to_iso remains the existing ISO string tests keep their exact expected strings and stay green the ms_to_iso tests move wit

Current behaviour A background delegate hands its result back through two paths, both bound to the session that started it: the mcp-await-job hook while that session runs, and the resume notice (src/hook_jobs.rs) when that same session is resumed. A session that quits and is never resumed leaves its done results unnamed. They sit in ~/.clauth/jobs/ until the startup sweep reaps them a day after they finish, so a result the account already paid for reaches nobody. Example: start a background delegate from a session in ~/work/app, /exit before it finishes, then open a fresh claude in ~/work/app. Nothing tells the new session the result exists. Only monitor with no job_ids, or clauth jobs, would show it. Expected On SessionStart, a session is told about every finished, uncollected background result that was started from the same project dir by a session that is no longer running: told on any SessionStart (startup, resume, clear, fork), at most once per session id, and again on compact, s

Current behaviour The session index (src/sessions.rs) walks every *.jsonl under ~/.claude/projects/ (and each runtime store) down to WALK_MAX_DEPTH. Workflow runs write a journal.jsonl at projects/<slug>/<session>/subagents/workflows/wf_<id>/journal.jsonl. It is a run log, not a conversation transcript: its first record has only the keys agentId, key and type ("type": "started"). Each journal still becomes a session row, with the id journal (its filename stem). On a store with 389 workflow runs, all 389 collapse into one journal row in clauth sessions, clauth sessions --json and the daemon API's session listing, and clauth info journal resolves to whichever journal the index happened to keep. Expected A workflow run journal is not a session: the index skips a journal.jsonl whose parent directory is a wf_* directory under workflows/. Every real transcript keeps listing, the subagent transcripts beside the journal in that same wf_* directory (agent-<hex>.jsonl) included. Where to look s

Current behaviour start_walk in src/fallback.rs skips a chain member whose name does not resolve to a profile. So a non-empty fallback_chain whose names are all dangling gives zero rows, and cmd_start's --auto arm refuses through format::start_refusal with the headroom wording. Example: profiles.toml has fallback_chain = ["alice", "bob"] and neither profile exists. clauth start --auto refuses with --auto found no chain member with headroom, which names the wrong cause: no member is short on headroom, none exists. Only a hand-edited profiles.toml gets here, since deleting a profile already removes it from the chain. Expected When the chain is non-empty and none of its names resolve, the refusal reads exactly: --auto found no chain member that exists (alice, bob) (the names in chain order, joined with , ). A chain whose members all exist but are all blocked keeps the current headroom wording. Where to look src/fallback.rs: start_walk (the config.find(name) skip) src/format.rs: start_re