CClawMetryDocs

Runtime reference

Lovable#

Lovable runs entirely on the vendor's side: no local process, no local transcript store, no OTLP hook. What it does ship is GitHub two-way sync, which writes one commit per accepted agent edit into the linked repo. Clone that repo and you have a real, on-disk, per-edit activity record — and that is what ClawMetry reads, strictly read-only. It never runs git fetch and never touches the network.

Runtime idlovable
CategoryCloud app builder
VendorLovable
TierPaid tier (Starter and up)
Upstreamlovable.dev

Where the data comes from#

ClawMetry reads these locations, in order, and never writes to any of them.

  • <project>/.git — the commit history of a local clone
  • <project>/README.md — the project marker lovable.dev/projects/<uuid>
  • <project>/.git/FETCH_HEAD — when present, the last fetch time

Format. Git history. Commits are matched on the Lovable GitHub app bot identity — gpt-engineer-app[bot] on the wire, branded lovable-dev[bot] in the docs, plus the email's stable numeric id — and current-generation commits carry an X-Lovable-Edit-ID trailer with a per-edit UUID.

Environment variables#

VariableEffect
CLAWMETRY_LOVABLE_DIRScolon-separated project roots; when set it is the only source
CLAWMETRY_LOVABLE_BOTone extra accepted bot author name, for GitHub Enterprise Server installs

See Environment variables for the variables that apply to every runtime.

Tokens and cost#

Tokens. None. Nothing local records tokens.

Cost. Unavailable. Lovable bills credits and nothing on disk records spend, so cost_usd is None with cost_status="unavailable" — never an estimate.

Why this section exists

Runtimes differ enormously in what they persist. Rather than showing a plausible number everywhere, ClawMetry reports what the store actually contains and marks the rest unknown. A cost of $0.00 and a cost of unknown mean different things, and the dashboard keeps them different.

Sub-agents and delegation#

Not applicable. Each commit is one accepted edit; there is no delegation structure in the sync.

Things worth knowing#

  • Detection requires BOTH the README project marker (lovable.dev/projects/<uuid>) AND at least one bot-authored commit, so a manually forked scaffold never appears as agent activity.
  • The clone shows the world as of your last fetch. The session carries extra.lastSyncedCommitAt, and extra.lastFetchedAt when .git/FETCH_HEAD exists. Nothing claims to be live.
  • running is always false. A local clone cannot prove a cloud agent is active, and fabricating liveness is a bug class this project has been burned by.
  • ClawMetry can only surface projects whose clone you point it at. That is a documented limitation, not a silent gap.
  • Older 2025-era repos carry neither trailer; both are optional in the parser, so history still parses.
  • Discovery is bounded, never a $HOME walk: CLAWMETRY_LOVABLE_DIRS first, otherwise a fixed list of likely roots (the cwd, ~/Projects, ~/dev, ~/code and similar) each scanned one level deep.

Verify it is being read#

bash
# Is this runtime detected, and would this install unlock it?
clawmetry runtimes --json | jq '.runtimes[] | select(.id=="lovable")'

# Why is it locked, if it is?
clawmetry runtimes --why lovable

# Any sessions ingested yet?
curl -s 'http://localhost:8900/api/local/sessions?limit=5' \
  | jq '.rows[] | {session_id, agent_id, events, cost_usd}'

If detection succeeds but no sessions appear, work through Troubleshooting — the usual causes are a relocated data directory (set the override above), a session limit that is hiding older runs, or a runtime that simply has not written anything yet.

Edit this page View as Markdown Report an issue
Cookie preferences