Frame the CLI LLM summarizer experiment

Success is not “I followed the tutorial.” Success is producing evidence that: fake transport returns a summary string; real adapter is isolated behind env credentials. The accepted input is narrow on purpose: non-empty text, model name, timeout, API key from environment. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: offline fake transport producing a fixed summary. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

const job={system:'Summarize in one sentence.',user:'Embeddings map items to vectors.'};
console.log(JSON.stringify(job));

Expected evidence: a JSON object containing system and user strings. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the command-line LLM summarizer, a decorative win often looks like a clean run that never checks contract-test pass rate, latency, retry count, output length. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: printing API_KEY or full prompts into logs.

For llm-api-hello, write the claim on a sticky note in this exact shape: “Given non-empty text, model name, timeout, API key from environment, the CLI LLM summarizer will …”. Fill the ellipsis with the observable part of: fake transport returns a summary string; real adapter is isolated behind env credentials. Tape the baseline beside it: offline fake transport producing a fixed summary. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to turn one user passage into a bounded one-sentence summary via an HTTP-shaped client. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (system+user job object for an embeddings definition sentence) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against system+user job object for an embeddings definition sentence. Note the metric you will eventually require (contract-test pass rate, latency, retry count, output length) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is missing choices array treated as empty success, or retries on 400.

At the experiment brief stage for llm-api-hello, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about system+user job object for an embeddings definition sentence that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: offline fake transport producing a fixed summary.

For this page specifically, success looks like a falsifiable claim and baseline written before coding while still centering the user decision to turn one user passage into a bounded one-sentence summary via an HTTP-shaped client. If you cannot point to a file, command, or assertion that proves that for the CLI LLM summarizer, stay on this page instead of advancing.

API: chat completions · Glossary: API key

Next