Typing a prompt and getting a useful answer are two different skills

Nothing here needs special syntax. What separates a useful answer from generic advice is how much you say before you ask.

1. Step 1

   Select New session at the upper left

   A new entry appears at the top of the session list and the conversation area clears. Do not drop a new topic into an old session — its history adds to your usage and distracts the model.

2. Step 2

   Choose your model from the lower-left menu

   Composer is the large input area at the bottom: model selector at the lower left, Send at the lower right. Pick the OpenRouter model from Part 3 — for example anthropic/claude-sonnet-4, the exact value entered in models[].name. Model IDs change, so check the live catalog if yours is missing.

3. Step 3

   Type this question

   You askMy living-room light is a Xiaomi model. After 10:00 p.m., I want Home Assistant to dim it gradually to 20%. How should I configure that? Please respond in English.

   Five facts, briefly stated: device, time, target brightness, platform, output language. Those constraints are why the reply will be specific rather than a lecture about smart lighting.

4. Step 4

   Press Enter, or select Send

   Composer sends on Enter and starts a new line on Shift+Enter; if your version differs, use the visible Send control.

An answer, with its receiptA shorter, more general question than the one above — but every reply is metered the same way.GPT-5.6 Sol

• 1,094 in · 53 out — far more went in than came back. Most of it is the standing instructions sent with every request, not your sentence.
• $0.0071 for a two-sentence answer. Part 6 covers what moves that number; for now, note that it is always shown.
• GPT-5.6 Sol at the lower left, Send at the lower right. That bottom strip — model, medium, default, Compact — is where you change the model before you type, not after.

A useful answer separates the trigger at 22:00 from the action that dims to 20%, offers UI steps or YAML you can review, and asks for the entity details it lacks.

Note what has not happened: you have not operated a single switch. This is adviser mode — the model proposes, you review and test.

The first answer is a starting point, not a conclusion

Two more messages in the same session turn that reply into something you can act on.

The first states your experience level and asks for a different format — you should get UI steps such as Settings → Automations → Create automation rather than unexplained code. The second tests a failure case, the habit worth keeping: a strong answer explains what happens if someone adjusts the light mid-transition, and whether a conditions: section is needed. Ask one thing at a time, though — three unrelated problems in one message produce an answer you cannot inspect.

These work almost anywhere:

Fluent writing makes a weak claim sound convincing

Four checks, for the answers that matter rather than for every sentence.

When it is confidently wrong

Every current model can state something false with complete confidence, including any reached through OpenRouter. This is called a hallucination.

Here is a real one. A model may hand you light.slow_dim as a Home Assistant action. There is no such action — a gradual change uses light.turn_on with the documented transition option. It is printed here as an example of the failure, not to copy. The same habit produces invented product numbers, one brand's features attributed to another, and material that was current when the model was trained.

• Verify the facts that change what you do. Model numbers, commands, prices, regulations — thirty seconds against a current primary source.
• Ask another model. It can expose uncertainty, but it is not independent evidence.
• Be more skeptical when it sounds certain. Counterintuitive, but hallucinated claims can sound more certain than true ones. Ask for sources and assumptions, then check them.

Ask it to change something and the conversation changes shape

Everything above was advice. Ask Pi Agent to touch a file and you get tool cards instead of prose — one per action, each with its own timing and charge.

Work in progressTwo tools, two cards, two separate charges — and a message box that has become a set of controls.

• write notes.md names the tool and the file: 5s, 1,180 in · 70 out · $0.0080.
• read notes.md is a second round trip: 2s, 1,265 in · 18 out · $0.0069. One instruction from you, two billed requests.
• $0.02 in the top bar is the running total for the session, not for this message.
• Steer, Follow-up and the red Stop replace the message box while work runs: redirect the run, queue for afterwards, or end it.
• Waiting for model… under the second card. The tools are done; the reply that explains them has not arrived yet.

Use Stop when a response is unsafe, irrelevant, or built on a premise you can see is wrong. But do not stop it on a stopwatch: a fixed wait does not distinguish a slow model from a failed request, and reasoning models are genuinely slower. Check the add-on log for 402 Payment Required, 429 Rate Limit or a quota message first.

Not a transcript — a project file

The same run, finishedThe work folds into one summary line, and a real file appears on the left.

• Process details · 2 messages · 2 tool calls is the whole run in one line. Expand it to see what ran.
• notes.md in the EXPLORER, where the previous screenshot still read No files found. A real file on your host.
• 1,152 cache R — part of the input came from cache rather than being charged in full, which is why this step cost less.

All of that is now part of the session, which is where the word stops meaning “chat.” A session holds every event in the conversation — messages, responses, reasoning data, tool cards and diffs — plus the model information, the Skills loaded, the working directory and the system instructions.

That matters because the model itself remembers nothing. Each turn, Pi Agent rebuilds the request:

flowchart TD
  A["You type a message"] --> B["Pi Agent builds one request:
your message plus relevant
stored history from this session"]
  B --> C["The model reads only
what is in that request"]
  C --> D["The reply and its events are
appended to the session file"]
  D -->|"same session, next turn"| A
  D -.->|"a new session instead"| E["A request with none
of this history in it"]

So longer history means more input usage and more latency, and no amount of model capability removes that. Earlier details can fall outside the effective context — which is what people mean when they say the model forgot. When it happens, ask for a summary, check it, and start a new session with it.

The left column of the screenshots above is that list. Each session is one row: its title, how long ago it was last touched, and a message count — 2 msgs next to 8 msgs. Watch that count. It is the closest thing you have to a running estimate of what your next question in that session will cost, because the stored history is what gets re-sent.

Sessions are files on your host:

One file per session, one event per line — that is what .jsonl means. /data/pi-agent/ is add-on data, separate from the /config/ holding your Home Assistant configuration. Whether it reaches your backups depends on the add-on's backup behavior, so make a test backup and verify the restore rather than assuming. Part 14 covers that.

New topic, new session

After a week, a lighting fault and a sunset automation share one session and the long one has become slow. This is the rule that prevents that.

Give each session a title you would search for — “Living-room light 3 — unavailable” beats “Check the light” — and rename at the end of the work, because the cause is often not your first guess.

Export gives you a file to keep outside pi-web. .jsonl is the archival copy: structured events that may include messages, roles, reasoning, tool calls and paths. .md, where supported, is a readable transcript. Either can contain prompts, file contents, paths and secrets — read and redact before sharing.

Where to go from here