LaufwerkLaufwerk
Learn Laufwerk

Studio, logs and usage

Inspect what happened and interpret measurements without treating missing evidence as success.

A useful run record answers three questions: what was attempted, what actually happened, and why the workflow chose its next step.

Inspect one run through two interfaces

bunx laufwerk@0.0.1-alpha.13 status
bunx laufwerk@0.0.1-alpha.13 status RUN_ID --json
bunx laufwerk@0.0.1-alpha.13 timings RUN_ID --json

Replace RUN_ID with the listed ID. Studio shows recorded execution, logs, sessions and pending interactions. Use CLI JSON for the stored top-level workflow result; alpha.13 Studio does not display that return value directly.

ObservationWhat it establishes
completed lifecycleThe workflow finished; its business result can still be declined
Valid structured outputThe response matches the schema
Recorded command resultThe command's exit code and captured output
Human responseThe person's recorded answer to that request
Reported token usageUsage the provider reported for captured events

None alone proves that a result is correct or that an external action completed.

Put useful context in activity logs

Call this helper within a registered workflow. Logging occurs inside the recorded activity, with the check name and policy version attached.

check.ts
import { Activity } from "@effect/workflow";
import { Effect, Schema } from "effect";

export const checkLength = (draft: string) => Activity.make({
  name: "check-length", success: Schema.Boolean,
  execute: Effect.gen(function* () {
    const passed = draft.length <= 500;
    yield* Effect.logInfo("Draft length checked").pipe(
      Effect.annotateLogs({ passed, characters: draft.length, policyVersion: "length-v1" }),
    );
    return passed;
  }),
});

The caller must use the returned boolean to decide whether to proceed. A warning or error log does not fail an Effect; use Effect.fail to make failure part of the workflow contract. Avoid logging tokens, credentials or entire private inputs.

Read timings as overlapping work

Research A:  [──────── 20 seconds ────────]
Research B:  [──── 12 seconds ────]
Elapsed:     about 20 seconds, plus setup and coordination

Adding operation durations can exceed elapsed time because parallel work overlaps. Separate setup latency, agent time and verification when investigating slowness. Missing token usage is unknown, not zero. Token counts are not invoice receipts; there is no universal monetary calculator or hard spend cap in this release. Container limits bound local resources, not provider billing.

Go deeper: Studio · Logging · Inspect and debug


← Context and memory · Next: Evidence and reusable cases →

On this page