fireworks-vibe-cleaner

English | 简体中文 · Compatibility · Security

fireworks-vibe-cleaner is a Skill plus CLI. Tell Codex or Claude Code what you need in plain language; the Skill inspects and explains, while the CLI performs deterministic scans, verification, execution and recovery. Real cleanup starts only after you see and approve the exact list, method, impact and plan hash.

Start with three prompts

1. Install it and preferably configure Jev

Install fireworks-vibe-cleaner from https://github.com/yizhiyanhua-ai/fireworks-vibe-cleaner. Check requirements and any existing installation; do not overwrite it or clean files. Then explain how to configure Jev securely. If I skip configuration, start with local rules.

Requires macOS/Linux and Python 3.11+. See the CLI guide for manual installation. Jev receives fixed metadata to help triage; it does not receive paths, titles, transcripts or code. Disclose data scope and possible charges before a network call, and never paste an API key into chat or command history.

2. Review the list and state what must be kept

Check how much storage Codex and Claude Code use. Show candidates, recommendations, reasons, alternatives, expected impact and unknowns directly in chat. Leave active, linked, explicitly kept and unclear content alone. Show findings before deleting anything.

Say “I need to continue these conversations” for important sessions. If file-copy recovery is enough, say which sessions only need a verified archive. Unclear requirements stay unknown. Jev, local rules and assistant purpose judgments provide advice; none can approve cleanup for you.

3. Approve this specific operation

Show the exact files, method, backup location, expected reclaim, recovery limits and plan hash, then link the full plan. Wait for my approval and report actual results afterward.

Relevant writers must stop first. If an unchanged plan expires, archive-refresh revalidates the same sources and archive bindings and creates a new hash, which still needs approval. For larger cleanup, use archive-workflow-*: the CLI removes and restores one canary file and verifies its original path and bytes before it can start the cleanup plan.

What do backup, archive and cleanup change?

Real execution evidence

On 2026-09-23, one real operation completed after approval of its exact scope:

Sanitized execution evidence. Logical bytes removed, volume movement and recovery coverage are separate measurements; they do not establish that every removed session was restored.

When Codex history gets large

Check my Codex history. If total size exceeds 3 GiB, one session exceeds 3 GiB, or the unarchived count exceeds 200, show a recommendation. Keep the newest 100, the last 30 days, pinned/current sessions and my explicit keep list. Give me an overview before the full plan and wait for approval.

Thresholds trigger advice only. Native history archive is expected to reclaim 0 bytes. Actual storage recovery uses the separate “verify ZIP → approve exact plan → restore canary → remove originals” flow. See the history guide.

Supported and protected scope

See the CLI guide, Jev boundaries, purpose evidence, compatibility and security policy. Keep local inventories, plans, archives and recovery journals private.

v0.6.0: useful purpose evidence, with a rules comparison

The same 14 real files (404,874,193 bytes) were evaluated using metadata and four locally prepared assistant purpose annotations. Two annotations conservatively identified possible continuation needs. These are fallible judgments from bounded text, not user labels or proof of project status. No text or semantic summary was sent to Jev.

Both purpose runs matched the rule baseline's final reason codes on 14/14 files. This is not accuracy, and no advantage over rules was demonstrated. The useful change is source-bound purpose evidence and clearer next steps. Two extra local keeps came from assistant continuation judgments, not Jev. Four raw Jev backup choices lacked purpose evidence and were routed to review locally. One original-preserving suggestion in each purpose run remained tentative; confidence is not deletion safety.

The experiment excludes the first local annotation work and extra source hashes from timing; annotation time/model cost was not measured. Thus 1.16 seconds is not the complete first-use workflow. Nine checked source hashes matched, five protected/dynamic files were not hashed, and zero bytes were reclaimed. No human action labels, real Claude transcripts, visual-media understanding or real cleanup were tested.

We retain the initial probability-sum rejection, a diagnostic call and the earlier run that suggested unnecessary new copies. Across all attempts: 11 real calls, 26,635 known input tokens, estimated known input cost US$0.00111867 at the official price; one failed call's usage and billing remain unverified. Full sanitized evidence · Reproduction tool.

v0.5.0: real evidence and decision comparison

On 2026-09-22 we checked 14 existing files, 404,874,193 logical bytes, with 10 distinct evidence combinations. These included old/recent/current and related sessions, protected files and assets. Local evidence took 329 ms (index/policy 16, activity 287, backup 24); no full inventory scan is included.

The 16 MiB logical verification budget covered 9,776,540 bytes of source plus expanded selected-member reads. It did not verify whole ZIPs or native conversation resume. Selection and additional before/after hashes are outside the timed stage. Pinned threads and eligible old logs/caches were not covered by this real sample.

This validates evidence collection and stricter gates, not accurate backup-versus-delete judgment. New runs were slower than this baseline. Removing the old baseline's two preparation suggestions follows stricter evidence/recovery requirements, not proven model improvement. Two repeats do not establish a general consistency rate.

The initial attempt had one unavailable-or-invalid batch; its old generic status did not record whether transport or validation caused it. One frozen diagnostic and the subsequent full comparison succeeded. Across all attempts: 11 calls, 10 accepted responses, 20,159 known input tokens; known input cost is estimated at US$0.000846678 using the official price, excluding unknown usage of the failed call. Billing was not verified. All sanitized results, including the failure · Reproduction tool.

v0.4.0: real Jev triage latency comparison

On 2026-09-22, the same 33 existing old main transcripts, 1,049,047,931 bytes (about 1.05 GB) were evaluated with serial and concurrent real provider calls. No provider responses were mocked; full source hashes matched before and after.

Concurrent elapsed time was about 66% lower in this comparison. Timings cover fresh identity/retention/header checks and real inference, reusing an existing selected inventory. Full scans, archive verification and benchmark-only before/after source hashes are excluded. The two runs used 25,628 input tokens, estimated at US$0.001076376 using the official rate; billing was not verified.

All 33 files had identical metadata in the provider packet; different choices did not establish file-specific understanding. Recommendations differed between runs; low confidence routes to review under a product rule. This sample has no labeled ground truth and establishes neither deletion accuracy nor a repeatable speedup. No real cleanup occurred. Removal preparation still needs recovery-needs review, verified backups, protection checks and explicit approval of the final plan. Sanitized results · Reproduction tool.

v0.3.0 history checks

Two different checks ran on 2026-09-21; the native API check used isolated synthetic transcripts.

Real read-only evidence, isolated native evidence, and full workflow. Counts describe that snapshot; coverage gaps overlap and do not prove missing data. No real-user native archival, UI performance benefit or conversation continuation is claimed.

v0.2.0 workflow validation

On 2026-09-21, the published v0.2.0 was checked against existing local files with real Jev calls. No synthetic files or artificial file aging were used for this run.

No old log/cache files in this scope met the 30-day retention and local eligibility checks, so none of the 20 candidates offered delete; live delete recommendations were not validated. Eleven candidates allowed backup; the remaining nine allowed only keep/review. Jev chose review for all of them. Two matching runs establish observed choice consistency for this sample, with no labeled ground truth or evidence of accuracy gains over rules. Only allowlisted metadata was sent, without paths, filenames, transcripts or code.

Fresh read-only evidence · Fresh sanitized Jev evidence · Earlier single-call check. Real-original removal and original-path restoration still require approval of the exact list; file recovery does not establish native conversation continuation.

Real 10 GiB validation and live Jev comparison

The following historical backup measurements predate v0.2.0 archive removal and its expanded Jev choices. They do not validate those new capabilities.

Cleanup of real user data always requires explicit human confirmation of the concrete scope. This run only read originals, created private archives and verified recovery bytes. No original was quarantined, moved or deleted.

Measured on 2026-09-21: 564 existing session files, 10,932,021,589 bytes (10.181 GiB). Codex samples were at least 7 days old; Claude samples at least 1 day old. Selection checked open handles and froze full-file hashes. The source inventory skipped 227 boundaries and is not a whole-disk inventory.

All 1,107,896 nonblank JSONL records passed parsing, with zero malformed or over-limit lines. Every archive was fully decompressed through SHA-256 verification; this was streamed verification, not restoration over live harness directories. The logical difference between originals and ZIPs is 4.873 GiB. Actual cleanup reclaimed 0 bytes because originals remain; archives and retained validation copies consume additional space. This difference is not a promised filesystem reclaim amount. The run was paused once to add a 64 MiB JSONL line-length limit (not a process memory cap), then resumed using one completed shard; its timings/free-space observations are scoped to that resumed invocation, not a cold-start performance benchmark.

Only category, size/age bands, rule eligibility and unknown active-state metadata were sent. No path, filename, original ID, transcript, code or credential was included in model state. A model's review or confidence never replaces human cleanup approval.

10 GiB sanitized measurements · Live Jev results · Native-read findings, including failures.

Reproduction tools are available in current main (the v0.1.1 release predates this validation): large real-data validation, opt-in live Jev comparison, and macOS network-isolated native reader. They create private artifacts and never remove originals. Native tools/SDK are optional local dependencies, not automatic installs. These real-data or paid-provider checks never run in CI.

The earlier 214 MiB validation and custom-log safety finding are preserved in historical real-data evidence.

Development and evidence

python3 -m unittest discover -s tests -v
python3 tools/build_skill.py --check
python3 tools/install_canary.py
ruff check .
mypy vibe_cleaner

Local tests cover the CLI workflow, native history boundaries and interrupted recovery. CI runs on macOS/Linux with Python 3.11/3.14; check the actual workflow results. See release notes, CONTRIBUTING.md and SECURITY.md. MIT © 2026 Fireworks.