Two Floors: Swift Quest and This One

"Swift Quest is the floor the family's apps stand on. This quest is the floor under that one. The card you have filled is where the two meet."

The Software Floor

Swift Quest, the quest this one was slotted beside in the catalog, teaches the Swift that Apple work needs and everything a working family of apps is built from: the concurrency rules, packages and projects, AppKit and SwiftUI, signing and trust, launchd, the universal iOS app, extensions, the Watch, talking to an engine at home, and delivery through TestFlight. Every native app in the household — the prose editor, the drawing app, the file workbench, the voice sibling, the coding agent's clients — stands on that floor, and the fleet track's daemons are launchd jobs from its lessons. It is a quest about what the household writes.

The Silicon Floor

This quest is about what the household's code runs on, one level down: the pool, its bandwidth, the ceiling a token cannot cross, the working set the OS will give a claimant, the four doors a token can take, the wires between machines, and the market that sets the price of the memory. Where Swift Quest says which part of a lesson is Apple's law and which is the household's choice, this quest says which number is physics, which is a vendor's claim, which was measured on which Mac on which day, and which is the household's judgment — the four evidence labels that every table in fifteen tracks has carried. The two floors meet at the fleet: apps written on the first, placed on machines by the second, with the tier lesson's setting as the hinge between them.

The Card, Closed

The code block is the household's Mac card as a decision table, filled from the tracks that priced each row and with a last column for what would change the answer. Yours has the same rows with your numbers: the chip and the pool; bytes per token for the largest model you run; the bandwidth a kernel actually pulled on your Mac; decode at a short prompt and at 90% of the window; the working set and where the cliff is; what fits a card and not your Mac; the wires you have; which jobs are local for availability and which are cloud for quality; and the term — the three conditions with today's readings. Read down the answer column and the card is a position: run what can be left alone, buy the frontier where quality wins, keep a store for the machine that does not exist yet, and wait with a term. Read across the last column and the card is a calendar: the die, the wire, the software, the price. Next September, run the lab again, change the numbers that moved, and see which rows changed their answers. That is the whole method of this quest — predict, then measure — applied to the one machine you own, and it is the point at which the quest hands the card back to you.

Code

mac_card.py — the household's card as a decision table, with the column that dates it·python

#!/usr/bin/env python3
"""The Mac card, closed as a decision table. Fill the rows from the earlier tracks; the
last column is what would change each answer. The household's own card, 2026-09-15."""
card = [  # row, the household's answer, the lesson that filled it, what would change it
    ("chip / memory / bandwidth",         "M3 Ultra, 512 GB, 819 GB/s (office, server); M2 Ultra 192; laptops 128; Air 24",  "T1 map",        "a denser die (T14) or a wider bus"),
    ("bytes per token, largest model run", "14.42 GB (27B at 4 bits); the store's 753B fits at 452",                         "T6 physics",    "quantization bits; a mixture's active set"),
    ("measured bandwidth to a kernel",     "497 GB/s decode fit, 638 stream, 605 MPS matvec (61-78% of spec)",               "T9 lab",        "a runtime release; a new chip"),
    ("decode at short context",            "27B 32.6 tok/s; 9B 95; Ollama's engine 48-51 with speculation",                  "T6, T8",        "bandwidth; speculation; bits"),
    ("TTFT and decode at 90% context",     "27B: 90 s wall, 27.5 tok/s at 29K",                                              "T9 curve",      "a prefix cache (software), not capacity"),
    ("the working set and the cliff",      "464 GiB (90.6%) on 512; the Air ran a 27B with 1.7 GB swapped",                  "T4, T5",        "MLX's limit vs the OS recommendation"),
    ("what fits a card and not a Mac",     "a 27B: the card decodes 2.2x faster; above 96 GB: only the Mac",                  "T10 rivals",    "the model you actually run"),
    ("wires between Macs",                 "TB5 10 GB/s vs UltraFusion 2.5 TB/s: 250x; pooling not practical",              "T12, T13",      "a wire 10x wider"),
    ("local for availability, cloud for quality", "search, images, dictation, the agent's last rung local; voices, transcripts, summaries, frontier cloud", "T12, T15", "a local model that passes the household's test"),
    ("the term",                           "0 of 3 conditions turned; wait with a term",                                       "T15",           "memory price, model pace, cloud pricing turning together"),
]
print(f"{'row':38} {'answer (the household, 2026-09-15)':92} {'filled by':12} what would change it")
for row, ans, lesson, flip in card:
    print(f"{row:38} {ans:92} {lesson:12} {flip}")

Exercise

Close your card: fill every row of mac_card.py with your own numbers and the lesson that gave you each, then write the last column for each row. Date it. Then write one sentence at the bottom — your position, in the household's form: what you run, what you rent, what you keep, and what you are waiting for, with its term.

Hint

If a row is empty, its lesson has a script; run it. If the last column is empty, the row is either physics — and will not change — or a number you do not yet know what would move, which is the next thing to learn. Either way, the card is done when every row has a label and a date.