lantern 0.1.3

lantern 0.1.3

A run now ends with what it cost and whether the token budget got in the way, a
scripted setup saves what the environment already knows, and the report
describes a flow that has actually finished.

The cost of a run, measured

findings: 3
report  : /home/ianclemence/.local/share/lantern/reports/flw_1a0eb8865620000.md
model   : 2,468 in / 112 out tokens - $0.0008
context : peak 91 / 6,000 tokens, 0 summarization(s), 0 budget stop(s)

Every model call now goes through one counted path, so the tokens are the
endpoint's own usage block rather than a number reconstructed afterwards.
Tokens print on every run; money prints only when you say what a token costs
where you buy it, because a rate recalled from memory would be a fiction with
a dollar sign on it:

export LANTERN_PRICE_INPUT_PER_MTOK=0.27    # USD per million input tokens
export LANTERN_PRICE_OUTPUT_PER_MTOK=1.10   # ...and per million output tokens

The context line is the instrument the defaults were missing: the peak working
set, how often it was compressed, and how often LANTERN_TOKEN_BUDGET ended a
role before it said it was done. A budget stop was previously invisible — the
role simply stopped.

A --dry-run prints the same line labelled (scripted - estimate, nothing billed), and that estimate now counts the tool schemas too, so it is a real
pre-flight size check instead of a floor.

The report stopped describing a flow that had ended

The report was rendered before the flow's own counters landed, so every
stored report claimed Status: running and quoted whatever the rows
happened to offer at that moment — the 16-step, 38-tool-call example.com run
recorded 5 model steps and 0 tool invocations in its own report.

Status, counters and spend are now written to the row before it is read:

- Status: completed

## Summary

0 finding(s), 0 tool invocation(s), 2 model step(s), 2,468 in / 112 out tokens.

Context peaked at 91 of 6,000 tokens: 0 summarization(s), 0 budget stop(s).

A flow from before this release has no measured spend, so its summary omits the
token clause rather than claiming it spent nothing.

Setup, with and without a keyboard

With a terminal the three questions are unchanged. Without one there was
nobody to ask, so setup printed a generic "export the key" line and left the
machine unconfigured — the two questions it existed to answer were simply
dropped.

It now takes provider, model, endpoint and key from the environment (the same
environment-beats-file-beats-preset merge the run itself uses), checks them
with one real call, and stores them: config.json plus credentials at
0600. A second run reports already configured and calls nothing. When the
environment cannot finish the job, nothing is written and the message names
the one variable that would:

[skip] AI provider: no terminal here - export DEEPSEEK_API_KEY; run `lantern setup` in a terminal to be walked through provider, model and key

Also new since 0.1.2: lantern setup links the binary into ~/.local/bin so
the next terminal simply types lantern. It never edits your startup files —
if that directory is not on PATH yet, the export line is printed — and it
refuses to clobber a real file already called lantern.

GETTING_STARTED.md

The walkthrough is now in the repository rather than in a chat log: clone,
build, setup (both paths), doctor, the free dry run, the real read-only
assessment, reading the report, and what the two lines at the end of a run are
telling you to change — with a table saying where each default came from.

Verified

• 213 tests pass, 1 ignored (the live NVD query), 0 warnings — up from 198
  at 0.1.2. README and walkthrough quote the same number.
• Measured on this host: a call starts at 3,034–3,290 tokens before the
  conversation has said anything — 2,770 tokens of schema for the 20 tool
  definitions sent on every request, plus 264–520 for the system prompt. A
  test now fails if that overhead grows past 4,000.
• Cost line proven against a local stand-in endpoint (no key, no spend):
  2,468 in / 112 out at 0.27/1.10 renders as $0.0008, and the stored flow
  options carry the same numbers.
• Both scripted-setup paths run live: complete environment → connected in 1 ms → config.json + credentials at 0600; no key → the skip line above
  and nothing written.
• run --dry-run: 0.3–0.5 s for the full pipeline (one cold run 1.6 s), report
  written, nothing billed. lantern doctor exits 0 in 36–38 ms.
• The 20% disk floor earned its keep while this was being built: at 5.98 GB
  free against a 6.16 GB floor, run refused with both numbers in the message
  rather than starting and failing halfway.
• No warnings across cargo check --workspace --all-targets, and no line this
  window added exceeds the project's 100-column style.

Upgrade

git pull
cargo build --release          # ~/.cargo/bin/cargo if it is not on PATH
./target/release/lantern doctor

No database schema change, so flows recorded on 0.1.0–0.1.2 still render —
their reports keep the text they were written with. No new CLI flags, and no
new required variables: the two price variables are optional, and DEEPSEEK_API_KEY
(or the wizard's files) still works exactly as it did.

Attached: lantern-v0.1.3-aarch64-linux-gnu (8,546,696 bytes), built on Debian
13 / glibc 2.41 / aarch64. For anything else, build from source as above.