ClawWork - Moses Yebei

The Problem

Many AI assistants can generate text but cannot autonomously complete real‑world work that incurs costs and generates revenue. Teams that need a self‑sufficient “AI coworker” must build the surrounding accounting, task‑selection, and sandbox infrastructure themselves.

What This Does

ClawWork bundles that infrastructure around the OpenClaw agent. The livebench package (≈8 k files) stores GDPVal tasks, tracks token expenses, and evaluates earnings. The frontend React app visualises balance, completed tasks, and survival metrics (frontend/src/App.jsx). The clawmode_integration module provides a CLI (clawmode_integration/cli.py) that launches an agent loop (clawmode_integration/agent_loop.py) and registers tools from clawmode_integration/tools.py. Supporting scripts in scripts/ automate data back‑fill and estimation.

Key files:

livebench/main.py – orchestrates the daily simulation.
livebench/agent/economic_tracker.py – holds the balance, logs income/expenses, and exposes log_message, start_task, end_task.
livebench/api/server.py – FastAPI entry point that serves the React dashboard.
clawmode_integration/cli.py – entry point for the “agent” command (python -m clawmode_integration.cli agent).

How It Is Wired

Entry point – Running python -m clawmode_integration.cli agent executes clawmode_integration/cli.py:agent.
The CLI loads configuration (clawmode_integration/config.py) and creates a ClawWorkAgentLoop.
ClawWorkAgentLoop registers default tools (e.g., clawmode_integration/tools.py) and starts the message processing loop.
Each tool eventually calls into livebench utilities: livebench/agent/economic_tracker.py functions log_message, start_task, end_task are invoked from 19, 15, 15 places respectively (largest blast radius). livebench/agent/economic_tracker.py also calls track_tokens, add_work_income, and write_json (13–9 callers each).
When a task is completed, livebench/agent/economic_tracker.py writes JSON logs (write_json) and updates the balance file under livebench/data/.
The dashboard (frontend) fetches those JSON files via the FastAPI server (livebench/api/server.py). The server currently allows any origin (allow_origins=["*"]) and reads the same JSON files to serve the UI.
Model calls occur in a few places: livebench/agent/economic_tracker.py → generate_meta_prompt_for_category (model via client.chat.completions.create). clawmode_integration/tools.py → evaluate_artifact (model via self.client.chat.completions.create).

Cycles & hot spots – livebench/tools/direct_tools.py sits in a circular import with livebench/tools/productivity/code_execution_sandbox.py and file_reading.py. The most connected module frontend/src/App imports 10 others but is only used by the UI, while clawmode_integration/cli imports six modules and has an instability of 1, indicating a fragile entry point.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/ClawWork.git
cd ClawWork

# Python dependencies
pip install -r requirements.txt

# Frontend dependencies
cd frontend
npm ci            # uses package-lock.json
npm run build     # creates static assets for the dashboard
cd ..

# Start the FastAPI backend (reads .env.example for keys)
python -m livebench.main   # runs the daily simulation loop

# Run the AI coworker CLI (requires OpenRouter/other model keys in .env)
python -m clawmode_integration.cli agent

A .env.example file lists required variables (e.g., OPENROUTER_API_KEY). No Dockerfile is present, so containerisation must be added manually if desired.

Real‑World Use

A fintech team could embed the CLI in a nightly cron job. The job runs python -m clawmode_integration.cli agent, which pulls new tasks from livebench/data/agent_data/, lets the agent earn income, and writes task_completions.jsonl. The same file is consumed by the internal reporting dashboard, giving product managers a live view of cost‑per‑task and net profit.

# Example: programmatic trigger from another service
from clawmode_integration.cli import run_agent
run_agent()   # respects the same accounting logic as the CLI

Code Health & Issues

HIGH – Missing lockfile for livebench/data/agent_data/kimi‑k2.5‑test‑openrouter‑10dollar‑1/sandbox/2026‑06‑25/package.json.
HIGH – Wildcard CORS (allow_origins=["*"]) in livebench/api/server.py.
HIGH – CI workflow does not run the test suite (.github/workflows).
MEDIUM – No Dependabot/Renovate configuration.
MEDIUM – No dependency‑vulnerability scan in CI.
MEDIUM – Large binary blobs (e.g., livebench/data/agent_data/GLM-4.7‑test‑openrouter‑10dollar‑1/.../TAVARUA_FINAL_MIX.wav 30 MB) should be moved to LFS.
MEDIUM – Checkout step keeps credentials; persist-credentials: false missing in deploy.yml.
LOW – Workflow jobs lack timeout-minutes.
LOW – Repository lacks convention files (.editorconfig, formatter config).

The repo includes tests (≈6 k files) and a GitHub Actions CI definition, but the CI never executes them, reducing the reliability of automated checks.

The Bottom Line

ClawWork provides a ready‑to‑run stack that turns an LLM into an autonomous, cost‑aware worker, with a visual dashboard and a CLI. The core accounting logic is well‑centralised, but the codebase suffers from import cycles, deep nesting, and several high‑severity security/maintenance gaps (CORS, missing lockfiles, CI omissions). It is suitable for teams that want a research‑grade sandbox and are prepared to address the highlighted health issues before production deployment.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

8,152 files

JSON68
Python54
Markdown18
JSX11
JavaScript5
Shell3

ReactExpressTailwindTerraformLangChain

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["livebench 33 modules"] g1["frontend 16 modules"] g2["scripts 13 modules"] g3["clawmode_integration 7 modules"] g4["eval 2 modules"] g2 -->|7| g0 g3 -->|3| g0

Module dependencies

The 10 most depended-upon modules of 72, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_livebench_tools_direct_tools["direct_tools"] n1_frontend_src_api["api"] n2_tend_src_DisplayNamesContext["DisplayNamesContext"] n3_bench_agent_economic_tracker["economic_tracker"] n4_ivity_code_execution_sandbox["code_execution_sandbox"] n5_livebench_work_evaluator["evaluator"] n6_clawmode_integration_tools["tools"] n7_livebench_utils_logger["logger"] n8_livebench_work_task_manager["task_manager"] n9_wmode_integration_agent_loop["agent_loop"] n9_wmode_integration_agent_loop --> n6_clawmode_integration_tools n0_livebench_tools_direct_tools --> n7_livebench_utils_logger n4_ivity_code_execution_sandbox --> n0_livebench_tools_direct_tools classDef cyc stroke:#ef4444,stroke-width:2px; class n0_livebench_tools_direct_tools,n4_ivity_code_execution_sandbox cyc;

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high3

medium4

low2

Commit a lockfile beside the manifesthigh

livebench/data/agent_data/kimi-k2.5-test-openrouter-10dollar-1/sandbox/2026-06-25/package.json

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Replace the wildcard CORS origin with an explicit allow listhigh

livebench/api/server.py

allow_origins=["*"] together with credentials enabled

Any page on the internet can call the API with the browser's cookies attached, so a logged-in visitor to an unrelated site performs authenticated requests without knowing, and the wildcard combined with credentials is the exact configuration browsers refuse for that reason.

Fix: List the origins the API actually serves, and never pair a wildcard with credentials.

Make CI invoke the test suite it hashigh14 occurrences

.github/workflows

14 test files, no test command in any workflow

A green check that never executed an assertion is worse than no check, because reviewers trust it.

Fix: Add a test step to the existing workflow rather than a new workflow.

Enable Dependabot or Renovatemedium

4 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Move large binaries to Git LFS or out of the repositorymedium11 occurrences

livebench/data/agent_data/GLM-4.7-test-openrouter-10dollar-1/sandbox/2026-08-25/TAVARUA_FINAL_MIX.wav

11 blobs over 5MB: TAVARUA_FINAL_MIX.wav 30.7MB, tavarua_mix.wav 30.7MB, TAVARUA_FINAL_MIX.wav 30.7MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Set persist-credentials: false on checkoutmedium

.github/workflows/deploy.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow

.github/workflows/deploy.yml

1 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.