A model on your own laptop

You have rough notes and need a short working draft you can use without an Internet connection. In LM Studio, a desktop application, you will select a downloaded model, ask it to structure supplied text, and improve the answer in the same chat. Your useful result is a concise handoff that distinguishes what happened, what remains unknown, and what to do next.

The optional example is a fictional Northstar bench exercise. You will first draft a working note, then revise it after a synthetic record check. The parallel Harbor team example uses the same method for a company handover. Neither contains real findings or personnel details. Your own bounded drafting task is equally valid when its source text is public, synthetic, or explicitly approved for this device and application.

This is Level 1 User: one person, one laptop, one desktop chat. Your main work happens in the application's chat window. System settings tell you whether the laptop has memory headroom and is disconnected; an existing local document editor holds the result. There is no command line, server, model API, connector, or service for colleagues to set up.

Learning objectives

After this book you can:

• Install an approved local-model desktop application through its graphical installer and find its model discovery and chat views.
• Choose downloadable model weights with a suitable instruction-following purpose, compatible format and reviewed licence, then assess actual memory headroom on your own machine.
• Generate a fresh answer after disconnecting all network connections, rather than presenting an old answer as an offline run.
• Turn supplied notes into a useful draft and make one meaningful, source-grounded revision.
• Record observed responsiveness, answer quality and repair effort, then explain when you would use local inference, an approved hosted route, or a manual process.

Core concepts

Know which window does what

The LM Studio website in your browser supplies the installer and documentation. Visiting it does not install the application or download a model. The installed LM Studio application has a Discover view for finding model downloads and a chat view for asking the selected model questions. A model file is separate from the app; both it and the necessary inference runtime must be available before you go offline.

In chat, the selected-model control identifies the model to use, the message box holds your prompt, and the conversation displays the response. The vendor's current chat documentation describes a + control for a new chat. Controls may move between releases: use the official documentation for your installed version if the labels differ. Select the downloaded local model explicitly, rather than inferring the route from a familiar chat layout.

Screenshot placeholder SC-01 — LM Studio desktop orientation. Intended view: a new chat with a downloaded local model visibly selected, an empty message box, and the chat navigation visible. Proposed caption: “Choose the downloaded model here; paste your supplied notes into the chat below.” Reference: Manage chats (opens in a new tab). Capture status: not captured. No interface image or reuse permission is claimed; any future capture needs recorded provenance and a rights check in a separately approved isolated session.

A small local model can be enough

A local model is a model file processed by an application on your own computer. Once the application, its runtime and the model are present, basic chat can work without a cloud model. Small models can be useful when you supply everything needed and can judge the result: rewrite a paragraph, propose headings, classify invented feedback into fixed labels, or turn rough notes into a draft.

That is the shape of this exercise. You are asking for a transformation of five supplied facts, not a new scientific explanation. A fluent answer still needs inspection: an assistant can turn an unchecked box into a claimed cause, or a proposed action into a completed one. The revision will make those distinctions more useful to the next reader.

Current research, reliable citations, difficult calculations, high-impact decisions, or work you cannot check require another approved process. A task does not become suitable for a small local model simply because the source is private.

Model suitability has two gates

First, purpose and permission. Choose an open-weight model: its weights are available to download, and its model card identifies its intended use and licence. Open weights do not necessarily mean an unrestricted open-source licence. Look for a conversational or instruction-following model appropriate for English text drafting. Read its limitations and the actual licence terms that apply to your use; a popularity rank or licence badge alone is not enough.

If the download is a converted or quantized derivative, identify its publisher and the original model it comes from, and follow the linked applicable terms. A visible licence is not permission for every use. If terms are missing, unclear, incompatible, or require approval you do not have, choose another suitable model or stop. Reviewing a licence for this personal synthetic exercise does not approve subsequent commercial or sensitive-data work.

Second, technical fit. Use a format your application supports and leave memory for the operating system, application and conversation. A download fitting on disk does not prove it fits in working memory. Model names and laptop recommendations age quickly; record the exact file you actually select instead of treating one name as a permanent course requirement.

Quantization reduces the precision used to represent model weights, generally reducing file size and memory needs with a possible quality trade-off. Labels such as Q4 describe a variant, not a guarantee of fit or correctness. LM Studio's download guidance suggests a 4-bit option or higher when the machine can handle it. A smaller instruction model may be a better first choice than squeezing a much larger model into an extreme compression setting.

Make hardware fit visible

Check the current system requirements (opens in a new tab) before downloading. Installing the app successfully is only the first hurdle. Vendor recommendations do not establish that a particular model and conversation fit your machine.

Use the operating system's graphical views:

• Windows: Settings → System → About for installed hardware; Task Manager → Performance → Memory for current memory figures, and GPU views for dedicated/shared memory where present. Settings → System → Storage or File Explorer shows free storage.
• macOS: About This Mac for installed memory; Activity Monitor → Memory for pressure, memory used and swap. System Settings → General → Storage shows storage. Record the labels your version exposes rather than inventing an “available RAM” figure.
• Linux: the distribution's graphical System Monitor and system/storage settings provide the corresponding information. Labels vary; if a metric is absent, record “not exposed.”

Dedicated VRAM belongs to a graphics processor; shared or unified memory draws on a shared pool. Do not add shared memory twice or assume free RAM can substitute for dedicated VRAM in every setup. The application may distribute work between CPU and GPU; record the placement or offload information it exposes, or mark it unknown.

Record memory before loading, after loading, and during the actual draft and revision. The conversation needs working space too; a longer context can consume more memory. Where available, copy the context-length setting and any application memory estimate, labelling that estimate as an estimate. Leave advanced settings alone for the first short task rather than raising the context to the largest offered value.

Headroom is visible spare capacity and usable behavior: the system is not persistently under high memory pressure, other ordinary windows remain responsive, and the task finishes at a pace you can accept. Do not invent a universal “safe GB” margin. If your interface supplies only pressure and used-memory figures, report those. A file that loads but makes the laptop unusable has not passed this task's fit check.

Offline is a narrow, useful boundary

The vendor documents offline chat with downloaded models. Searching for models, downloading models or runtimes, and checking for updates involve network access. Prepare those parts online, then disconnect before the useful request.

A fresh response generated while the computer has no active network connection supports a narrow conclusion: this selected local setup completed this prompt without an active network. A screenshot records the displayed state at capture time; your sequence and observations establish when you disconnected and submitted. The image alone cannot prove the entire generation history.

Neither is a privacy certification. Local conversation storage, device accounts, backups or sync folders, retention, optional connected features, other software and later reconnection remain separate concerns. LM Studio's documentation describes chats stored on the local filesystem; being offline does not make those files disappear. Use synthetic material here, and review permission and storage before putting real data into any tool.

Local versus hosted is a task decision

You need not make a hosted call to reach an informed choice. An untried hosted alternative is untested, not faster or better by measurement. A manual draft is also a valid choice when repairing the answer costs more effort than writing it yourself.

Runnable exercise

Prerequisites and the artifact you will make

Start after T01-L01 · What AI can and can't do for your work. You need permission to install approved software, a supported Windows/macOS/Linux computer, storage for a large model download, and access to graphical memory and network settings. Installation and downloads are outside the roughly 30-minute active exercise; their duration depends on your setup.

Use LM Studio's desktop GUI for this route. If your organisation supplies a managed installation or approved model shortlist, start there and still check the particular model's fit and terms. Do not open Terminal or PowerShell, or turn on a local server. Jan is an alternative for later consideration, not an interchangeable set of buttons for these instructions.

In an existing local document editor that can hold text and an image, create a new report called local-draft-trial; do not replace an existing file. Save it in an approved local location, mindful of automatic sync. It will contain your source and prompt, first answer, revised handoff, actual fit observations, one evidence screenshot and a short route decision. No special report software or export format is needed.

Choose Northstar, Harbor, or your own permitted small task. For your own task, state the intended reader, supply the exact source text, request a short checkable artifact, and make a later revision that changes its usefulness. Do not paste real participant, patient, customer, personnel or credential data, unpublished findings or confidential notes just because inference is local.

1. Prepare and choose while online

1. In your browser, open the official LM Studio site (opens in a new tab), check the linked system requirements, and obtain the installer appropriate to your supported system. Confirm the expected vendor and installer publisher through your normal installation process. Use managed software when required; stop if the app is unsupported or installation is not permitted.
2. Open the installed app. In the operating system's graphical tools, record your hardware and baseline memory/storage observations. Close games, large analysis tools, video editors and unused browser windows.
3. Open Discover in LM Studio. Search an approved model name or paste its model repository URL. Open the model card and licence information in your browser. Apply the purpose/permission gate above; record the publisher, model-card URL, exact file/variant, licence and why the intended use fits.
4. Select a supported, modestly sized download that leaves room beyond its file size for runtime work. Use the application's compatibility information as a starting point. If a memory estimate is exposed, record it alongside the available-memory or pressure readings, not as an observed runtime measurement.
5. Download that model and wait for completion. Open a new chat with +, explicitly select the downloaded local model, and allow required runtime preparation to finish while connected. Keep web search, tools and connectors off; do not set up a server or API.
6. Send this readiness prompt in the app's message box:

Reply with exactly: LOCAL TEST READY

The expected response is LOCAL TEST READY. This checks readiness only. If nothing responds, resolve loading before disconnecting. If the model answers but ignores the exact wording, note the instruction-following weakness; readiness is not evidence of useful drafting quality.

Record post-load memory and whether switching between the chat, system monitor and report stays responsive. Do not write fictional numbers into the report to resemble a successful run. If loading fails or memory pressure stays high, unload the model and choose a smaller compatible, licence-reviewed option. If the app is unresponsive, use the operating system's normal graphical close/force-quit facility, then reopen it without reloading the oversized choice.

2. Disconnect, then start a fresh useful request

Through graphical system controls, turn off Wi-Fi and Bluetooth tethering, unplug Ethernet, and stop mobile/USB tethering or any other active network adapter connection. Disconnect the VPN too, but remember that disabling a VPN alone does not disconnect the underlying network. Confirm that the operating system reports no active network connection.

Keep the downloaded model loaded. Open a new chat and confirm its local model selection again. After disconnecting, choose a short run label you have not used before, such as a made-up four-character tag. Replace the bracketed label in the prompt below before submitting it. This helps distinguish the new useful request from your earlier readiness answer; it is a record-keeping aid, not a network audit.

Do not paste the worked answer from this book into chat. Let your selected model produce its own first answer, then save that actual answer unchanged in your report. Keep the laptop disconnected through the revision and final capture.

3. Northstar: turn rough notes into a working note

Source: the five synthetic notes in this prompt. There is no external dataset or actual experiment to retrieve. Expected artifact: an 80–120-word private working note with three headings, useful to the fictional researcher who needs to decide what to inspect next. The word target covers the note, excluding its run-label line.

Paste this into the new LM Studio chat, replacing only the run label:

Run label: [replace with a fresh label chosen after disconnecting]
Repeat the run label on a separate first line.

Use only the synthetic notes below. Draft a private working note of 80-120 words
for the fictional researcher who wrote them. Separate Observation, Possible
explanation, and Next check. Do not add causes, measurements, or conclusions.

Synthetic notes:
- Northstar bench exercise, samples L-01 to L-04
- L-03 showed a weaker signal in both repeat readings
- preparation log for L-03 has one unchecked mixing box
- no cause established
- next action under consideration: inspect the preparation record and repeat L-03

Here is an author-written acceptable illustration, not an observed model response. Your wording may differ:

Observation
In the synthetic Northstar bench exercise, covering samples L-01 to L-04,
L-03 showed a weaker signal in both repeat readings. Its preparation log
contains one unchecked mixing box.

Possible explanation
The unchecked mixing box is a lead to inspect, not an established cause of
the weaker signal. These notes do not establish why the signal was weaker.

Next check
The action under consideration is to inspect the preparation record and
repeat L-03. The notes describe this as a possible next action, not as
completed work or a confirmed explanation.

Inspect every factual sentence against the supplied notes. “The sample was not mixed” would be invented: an unchecked box is a documentation observation, not evidence that mixing did not happen. “Repeat L-03 confirmed the issue” would also be invented: the two readings already happened, but the proposed next repeat has not been reported as done.

4. Make a meaningful revision for the next reader

The first note is for its writer. Now a colleague needs a shorter handoff that makes completed and pending actions obvious. We also supply one new fictional update, so the revision must change the status of the record check without inventing a cause.

In the same disconnected chat, send:

Revise the Northstar note into a 50-75-word handoff for the next fictional
researcher. Keep the same run label on a separate first line, outside the
word target. Use these headings: Observation, Still unknown, Next action.

New synthetic source update:
- The preparation record has now been inspected; the mixing entry for L-03 is blank.
- The proposed repeat of L-03 has not yet been performed.

Retain the original source facts where relevant. Make the completed record
inspection distinct from the pending repeat. A blank entry does not show
whether mixing occurred. No cause is established. Do not invent an owner,
deadline, measurement, or experimental instruction. Return only the handoff.

An author-written revised illustration, again not a model-run claim:

Observation
In the synthetic Northstar exercise, L-03 showed a weaker signal in both
repeat readings. The preparation record has now been inspected; its mixing
entry is blank.

Still unknown
The blank entry does not establish whether mixing occurred or what caused
the weaker signal. No cause is established.

Next action
The proposed repeat of L-03 remains pending; it has not yet been performed.

This improves the handoff because the next reader can see that the record inspection is complete and the proposed repeat remains pending. Merely requesting “more professional wording” would not expose that distinction. Save your actual revised answer beside the first version; do not silently replace a failed answer with the illustration.

If the model claims the blank entry proves skipped mixing, correct that sentence explicitly: “The record is blank; whether mixing occurred is unknown. Remove the causal claim and revise the handoff using only the supplied facts.” Retry while disconnected. If it keeps inventing facts, shorten the task to three source-grounded bullets or finish the handoff manually and record why. An honest failed model attempt is useful evidence for your route decision.

Company route: Harbor uses the same method

Choose this instead of Northstar, not as another compulsory exercise. The fictional manager needs a working note about an unassigned case. In step 3, use this prompt in your new disconnected chat:

Run label: [replace with a fresh label chosen after disconnecting]
Repeat the run label on a separate first line.

Use only the synthetic notes below. Draft a private working note of 80-120 words
for the fictional manager who wrote them. Separate Observation, Possible
explanation, and Next check. Do not add motives, promises, or conclusions.

Synthetic notes:
- Harbor team exercise, cases C-01 to C-04
- C-03 remained unassigned after the second daily review
- handover checklist for C-03 has one unchecked ownership box
- no cause established
- next action under consideration: inspect the handover record and confirm an owner

The first answer should preserve the unassigned case and unchecked box without blaming anyone. The original useful sentence still applies: “Possible explanation: the unchecked ownership box is a lead to inspect, not an established cause.”

For step 4, send this follow-up in the same chat:

Revise the Harbor note into a 50-75-word handoff for the next fictional manager.
Keep the same run label on a separate first line, outside the word target.
Use these headings: Observation, Still unknown, Next action.

New synthetic source update:
- The handover record has now been inspected; the ownership entry for C-03 is blank.
- An owner has not yet been confirmed.

Retain the original source facts where relevant. Distinguish completed record
inspection from pending owner confirmation. Do not infer anyone's motives or
blame anyone from a blank entry. No cause is established. Do not invent a
person, promise, or deadline. Return only the handoff.

An author-written revised illustration, not a recorded run:

Observation
In the synthetic Harbor exercise, C-03 remained unassigned after the second
daily review. The handover record has now been inspected; its ownership
entry is blank.

Still unknown
No cause is established. The blank entry does not explain why the case
remained unassigned or establish anyone's motives.

Next action
Confirm an owner for C-03. This is still pending; no owner has yet been confirmed.

5. Keep the useful result and observe the whole task

Before you keep either handoff, check:

1. Source: every factual detail comes from the initial notes or the explicitly supplied update. Stable IDs such as L-03 or C-03 remain correct.
2. Uncertainty: no cause is established; a blank record is not proof of behavior or blame.
3. Revision: the record inspection is now complete, while the repeat or owner confirmation remains pending. The answer fits its new reader and requested headings and length.
4. Route: both actual answers completed after disconnection with the downloaded local model selected. The run label matches the fresh request, and the system remains disconnected.

Observe memory during the short generation and revision as well as after loading. Note whether the report editor and system monitor stay usable, whether the response completes, and whether waiting and correction effort are acceptable for this task. If the app displays timing or speed, you may copy it with its label; otherwise write a qualitative observation such as “completed, but editing the report stalled.” Do not invent seconds or tokens per second.

Use this structure in your report. Replace brackets with actual observations; “unknown” or “not exposed” is better than a guess.

Local draft trial — [date]
Task and intended reader: [Northstar / Harbor / my permitted task]
Application/version and OS: [as displayed]
Model publisher/repository and model-card URL: [actual selection]
Exact downloaded file, format and quantization: [as displayed]
Licence URL/name and suitability decision: [terms reviewed, scope and any limits]

Installed memory and free disk before download: [figures and displayed units]
Memory before loading: [available RAM, or used/pressure/swap as exposed]
Accelerator memory arrangement: [dedicated/shared/unified/none/unknown]
Application placement/context setting and memory estimate: [exposed values or unknown]
Memory after loading: [actual displayed figures/pressure]
Memory during draft and revision: [actual displayed figures/pressure]
Headroom decision: [why adequate, inadequate or uncertain for this task]

Disconnected connections and status: [what I actually disabled/unplugged and observed]
Fresh run label chosen after disconnecting: [label]
Source and exact prompts: [include original notes and revision update]
First answer: [actual text, including errors]
Revised handoff: [actual text]
Content checks and any correction/manual edit: [what changed and why]
Observed usability: [completion, responsiveness, wait and repair effort]
Evidence screenshot: [insert the inspected image here]

Next-time choice: [local / approved hosted route / manual / defer]
Reason from this task: [observed strengths and costs]
Remaining answer or fit weakness: [actual limit]
Hosted comparison: [not run, or describe an optional permitted comparison honestly]
Data boundary: [this run's scope; separate storage, backup and permission limits]
Model unloaded after capture: [actual action]

6. Capture the bounded evidence, then unload

Arrange the chat and operating system's graphical network status side by side. Show the selected model and completed revised handoff with its run label. Close unrelated windows and notifications; keep account names, personal paths and sensitive content out of view. Take one readable screenshot through the operating system's normal graphical capture tool, inspect it, and insert it into your local report. The source and first answer remain readable as report text, so the screenshot need not squeeze the entire conversation into one image.

Screenshot placeholder SC-02 — completed synthetic offline handoff. Intended view: LM Studio with the local model selected, the completed revised handoff and fresh run label, beside OS network status showing disconnection. Proposed caption: “A revised synthetic handoff completed after disconnection on this learner's selected local setup.” References: Offline Operation (opens in a new tab) and the learner's actual OS interface. Capture status: not captured; no hardware, model run, screenshot provenance or reuse clearance is claimed by this manuscript.

After capture, unload/stop the model through the app's graphical controls so it does not keep using memory, battery and accelerator resources. Save your report. Reconnect only when the offline sequence is finished, and remember that ordinary updates or sync may resume afterward.

For a short session, allow roughly five minutes to record fit and selection, five for readiness and disconnection, ten for drafting and revising, and ten for the report and capture. These are planning allowances, not measured runtimes. A slow or failed run should be recorded, not disguised to meet a schedule.

What goes wrong and how to recover

Explain your local/hosted decision

Write a short conclusion from the actual trial: which model fit, what loading and response behavior you observed, how useful the revised handoff was, what weakness remained, and what you would choose next time. For example, you might prefer local drafting when offline availability matters and corrections are small; prefer manual writing when the three-bullet result needs more repair than it saves; or consider an approved hosted tool for a task this model could not handle.

Those are possible decisions, not outcomes observed by this author. No hosted comparison is mandatory. If you did not try one, write “hosted alternative untested” and explain what you would need to know before using it, including permission to send the source. A disallowed cloud tool does not make an unapproved local app an acceptable destination for confidential work.

Exit check

Deliver one inspectable artifact: your local draft-trial report, with the screenshot embedded and the usable revised handoff easy to find.

It passes when another reader can:

• Identify the task, exact supplied source, initial prompt, new source update and meaningful revision request.
• Read your actual first answer and revised handoff, see the preserved uncertainty and action status, and identify any corrections or manual contribution.
• Identify the application and exact model file, its purpose/licence decision, actual memory observations before and during use, and the reason you judged headroom adequate for the task.
• Follow your recorded disconnect → fresh labelled request → completed draft → completed revision sequence, and read the model selection, completed revised answer and disconnected status in the screenshot.
• Understand observed usability, remaining limitations and your next-time local/hosted/manual choice, with untried alternatives labelled untested.
• See only permitted exercise material and a truthful account of stopping/unloading the model.

If the machine cannot complete a fresh offline response, fit remains uncertain, or the source-grounded revision still fails, keep the failed-attempt report and its useful recovery decision, but mark the local-run exit not yet met. Do not substitute the book's illustration, a hosted answer or invented hardware figures. A completed offline drafting trial may still lead you to choose a manual or approved hosted process next time.

The screenshot records one displayed state, and the report documents one task on one machine. Neither certifies the device's privacy or approval for real sensitive data.

Rule to remember: Fits in memory, or it does not run. Fits the task, or it is not useful.

Source notes

• Public baseline: T11-L01 · A model on your own laptop (opens in a new tab). This revision used the complete supplied editorial/drafts/l1-refinements/T11-L01.md. The completion brief supplies baseline body SHA-256 b54b4e7323886bed41ce3e3b5642da6532971c2e055b0b83cf7bb6f83176faeb; it was not recomputed or live-validated in this authoring session.
• Official text read on 11 September 2026: LM Studio Offline Operation (opens in a new tab), System Requirements (opens in a new tab), Manage chats (opens in a new tab), and Download an LLM (opens in a new tab). These support the bounded desktop workflow, new-chat control, preparation/network distinction, storage caution and quantization explanation. They do not establish successful installation or model execution here.
• Official model-card guidance read on 11 September 2026: the opening sections of Hugging Face Model Cards (opens in a new tab), including intended uses, limitations, licence metadata and base-model relationships. The returned page was truncated; later sections were not reviewed. No individual model card or licence was selected or approved by this author. The learner must review the actual download's sources and terms.
• Synthetic material: Northstar, Harbor, sample/case IDs, notes, record-check updates and illustrated handoffs are fictional teaching inputs and author-written outputs. The original five-note examples and their uncertainty boundaries are retained; the completed-record-check updates and revised handoffs are additions. No catalogue example association is claimed.
• Historical contribution: the supplied baseline records Astra (OpenAI, openai/gpt-6-astra) making the 9 September 2026 L1 refinement on hardware fit, memory headroom, observed usability and the local/cloud decision. Its historical Payload fetch/checksum time was 2026-09-09T10:50:57.3688468Z; that is not a new source check. Its “prepared only” note described that earlier authoring session; the current completion brief identifies that edition as the published baseline. The supplied manuscript does not identify an earlier named writer beyond that credit, so no additional Sol/Luna authorship is invented here.

Further reading and tools

• Taught: LM Studio desktop documentation (opens in a new tab) and the specific pages above for current interface guidance. Use the official site or managed distribution for installation.
• Taught: Hugging Face model cards (opens in a new tab) for intended uses, limitations, provenance and applicable licence information.
• Catalogued alternative: Jan source repository and documentation (opens in a new tab). Retained from the baseline, not freshly read in this session. Its graphical workflow must be checked independently; this book teaches LM Studio.
• Related teaching: Local & Private Models, the current track catalogue for wider-boundary reading; T01-L01 for bounded tasks, and T12-L01 for permission before using real material.
• Next capability: T11-L02 · A local model your tools can call continues to tool connections after this GUI-only personal run. It is not a prerequisite.
• Catalogued: Tools index for options to investigate after checking approval, fit, data handling and primary documentation.

Unknowns and limitations

No application was installed or controlled, no model was downloaded or run, and no hardware figures, inference timings, successful revision or screenshot were observed during this authoring session. Model suitability and licence approval depend on the learner's actual selection. System settings and app controls may differ by release and OS; documentation reads do not substitute for hands-on confirmation.

The supplied worked answers are inspectable illustrations, not predictions that every small model will satisfy the requested lengths or preserve uncertainty. Prompt execution, word targets, report usability and screenshot readability await the coordinator's consolidated verification and any separately approved hands-on work. A source-grounded note does not validate an experiment or staffing decision.

Offline inference does not establish secure local storage, absence of telemetry outside the disconnected interval, future behavior after reconnection, backup policy, organisational permission or anonymity. No hosted comparison, independent acceptance, classroom outcome, new publication or deployment is claimed.

How this book was made

Coordinator editorial update, 11 September 2026: The independent Terra reader accepted this revision. The account below records authoring-stage work; learner execution and classroom outcomes remain unobserved.

Astra — OpenAI, openai/gpt-6-astra — authored this example-led revision on 11 September 2026 in one fresh authoring context. The author read the assigned completion brief, editorial style/learnings/template and complete prior manuscript, then used five bounded official documentation reads for the desktop and model-selection details. The work was written with apply_patch to this book's single assigned manuscript file. No extra agents were used.

The revision retains the prior Northstar/Harbor sources, local-model explanation, purpose/licence and memory gates, trade-off table, fresh offline evidence requirement, recovery lessons, further reading and recorded Astra contribution. It connects them to a useful first draft and a shorter revised handoff, with an explicit new source update and actual-observation report. Screenshot planning is text only; no image was fabricated or captured.

The production lesson is that a shorter handoff becomes meaningfully better when it separates completed checks from pending actions—not merely when it sounds more polished. Likewise, a plausible illustrated answer teaches a target but cannot demonstrate that a laptop ran it. The report therefore leaves hardware and execution fields for real observations. Tests, lint, typecheck, validation and browser checks were not run; the coordinator owns the single consolidated verification after all ten edits. Token, cache, reasoning and cost counters are unknown. This output is a prepared manuscript, not a publication or independent approval.