---
title: Lovable
description: How ClawMetry observes Lovable — where its data lives, the environment variables that move it, what cost data is real, and the traps in its store.
eyebrow: 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 id** | `lovable` |
| **Category** | Cloud app builder |
| **Vendor** | Lovable |
| **Tier** | Paid tier (Starter and up) |
| **Upstream** | [lovable.dev](https://lovable.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

| Variable | Effect |
|---|---|
| `CLAWMETRY_LOVABLE_DIRS` | colon-separated project roots; when set it is the only source |
| `CLAWMETRY_LOVABLE_BOT` | one extra accepted bot author name, for GitHub Enterprise Server installs |

See [Environment variables](/docs/config/environment/) 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.

:::note 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](/docs/ops/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.