The local-model catalog in GPT Realtime Assistant makes those distinctions explicit. This article focuses on the inspected download service rather than making a latency claim about every device or language.

Model identity is more than a display name

RealtimeDownloadableModel entries identify a repository, a remote filename, a destination filename, and an installation kind. The catalog includes Whisper Large v3 Turbo variants and Qwen 3 8B variants with different quantizations.

That metadata is operational configuration. “Qwen” is not enough information to select a compatible file or explain its storage cost. The precise artifact matters, and companion artifacts can matter too.

Installed and selected answer different questions

The status builder resolves the runtime’s chosen Whisper, Qwen, and Qwen-ASR paths separately. For each catalog entry it inspects the local file size and checks that required companion files exist. It reports isInstalled separately from isSelected.

This avoids a common UI trap: showing a model as active simply because a download finished.

Stage large downloads separately

The downloader is an actor. It creates the model destination directory and uses a .part path while transferring a file. It reports downloaded bytes, expected bytes when known, speed, and an estimated remaining duration.

Progress remains below completion while transfer work is still in progress. When expected size is unavailable, the UI must tolerate uncertainty rather than inventing an accurate-looking completion time.

The downloader processes companion files after the primary model. That ordering reinforces why “main file finished” cannot be the only readiness signal.

Do not confuse a local pipeline with the cloud voice path

A local speech-recognition model and a local language model are distinct dependencies. Cloud live voice and local inference also have different startup and failure behavior. The useful interface makes the selected path and missing assets visible rather than silently switching providers.

For regression testing, start with a missing companion, an interrupted .part download, a selected file that has been moved, and two installed quantizations. Assert the displayed state, then separately run a synthetic inference check. File length checks are not cryptographic integrity checks; the code inspected here should not be described as providing such verification.

Product demos: voice and photo context

These short demos show the app's live voice and photo-question workflows. They are not tests or benchmarks of the local Mac model pipeline described above.

Live translation, lecture tasks, and interview preparation

https://www.youtube.com/watch?v=wOWFlpuPaZk

Asking about an illustrative train timetable

https://www.youtube.com/watch?v=p8f-OksdV5k

The scenes and presenter voices are AI-generated. The timetable is fictional; the route answer comes from a real app test and is edited for time. Some on-screen text in the first demo was adapted.

For shorter cuts, watch the family Short or the 13-second train edit.

The model lifecycle is a first-class part of a native AI product. It determines whether “offline” is an understandable capability or an ambiguous toggle. GPT Realtime Assistant’s comparison pages describe the product-level choices around that architecture.

Available on GPT Realtime Assistant on the App Store.

In Reel Screen Recorder, the broadcast extension receives ReplayKit buffers and keeps their source identity until the writer dispatches them. The useful engineering detail is not the slider itself. It is what happens when transforming a buffer fails.

Keep source identity through the pipeline

The current SampleHandler.handleAudio distinguishes .audioMic from .audioApp and asks the shared settings for recordingGain(forMicrophone:). It then passes the processed buffer, with its original source type, to BroadcastWriter.

The writer routes video, app audio, and microphone audio to separate capture functions. Its asset writer uses the MP4 container. This division keeps capture policy out of the file-writing dispatch code and makes it possible to reason about each source independently.

Zero gain is different from a small gain

The handler tries a volume-adjusted copy when gain is not one. If that transformation fails and the requested volume is zero, it tries to create a silent buffer. If silence creation also fails, it returns without writing the buffer.

Here is the policy in condensed pseudocode, not a drop-in ReplayKit implementation:

if transformation succeeds:
    write transformed buffer
else if requested gain is zero:
    if silent copy succeeds: write silence
    else: discard buffer
else:
    write original buffer

That last nonzero case is a fidelity compromise: requested gain may not be honored. The zero case is a privacy boundary. Writing the original buffer after the user muted it would violate the user’s explicit choice. The implementation treats those failures differently.

A floating camera is a separate concern

Reel also offers a picture-in-picture camera workflow. A camera preview, a system PiP surface, and an encoded recording are different objects with different lifetimes. A visible camera window alone is not proof that the exported clip contains the intended image and audio.

For verification, use a short recording with identifiable synthetic app sound and a spoken microphone marker. Inspect the exported MP4, then repeat with each source muted individually. Include interruption and failed-transform cases in tests. These are suggested checks, not performance results claimed from this code review.

The broader lesson is to preserve source identity until the last component that needs it. Mixing early makes later controls harder to explain and harder to verify. For the product workflow and alternatives, see Reel’s recording comparisons.

Available on Reel Screen Recorder on the App Store.

When building Arte Sheets—a local-first browser spreadsheet supporting 184 Excel-compatible functions, dynamic arrays, Pivot Tables, and .xlsx / .ods / .csv / .tsv import/export without requiring an account—we moved formula evaluation and file conversion into dedicated Web Workers.

Moving work off the main thread is only half the fix. If the worker still recalculates all 10,000 formulas on every keystroke, rapid edits queue up behind stale worker messages. Here is how we designed a hybrid incremental precedent-closure + dynamic-spill fallback engine in under 60 lines of worker coordination code.

Problem 1: Why Pure Topological DAGs Break on Real Spreadsheets

In textbook spreadsheet tutorials, cell dependencies form a static Directed Acyclic Graph (DAG):

• C2 = A2 * B2 depends statically on A2 and B2.
• Edit A2, walk outgoing edges from A2, recalculate C2, done.

Real-world .xlsx workbooks immediately break static DAG assumptions in three ways:

1. Volatile & Dynamic-Reference Functions: INDIRECT(), OFFSET(), NOW(), TODAY(), RAND(), and RANDBETWEEN() either change their target coordinates at runtime or mutate without any cell edit.
2. Dynamic Array Spills: Modern Excel functions like FILTER(), UNIQUE(), SORT(), SORTBY(), SEQUENCE(), and TRANSPOSE() write output into neighboring empty cells (spill regions) whose dimensions depend on runtime data values.
3. Structural Mutations: Renaming a sheet, changing merged regions, or updating named ranges invalidates range resolution globally.

If you try to handle OFFSET and FILTER spills inside an incremental single-cell walker, subtle stale-cache bugs creep in. Conversely, if you fall back to full recalculation for every workbook, simple financial sheets feel sluggish.

Problem 2: Splitting Safe Incremental Edits from Spill/Volatile Passes

Inside our calculation worker, we classify every formula cell on upsert using a fast regex check for volatile and dynamic-spill functions, tracking them in an unsafe set alongside sheet spillOwners:

const DYNAMIC_OR_VOLATILE =
  /\b(INDIRECT|OFFSET|NOW|TODAY|RAND|RANDBETWEEN|SEQUENCE|FILTER|UNIQUE|SORT|SORTBY|TRANSPOSE|RANDARRAY)\s*\(/i;

// During cell upsert in the worker:
const isFormula = typeof cell.raw === 'string' && cell.raw.startsWith('=');
const identity = `${sheet.id}!${key}`;

if (isFormula && DYNAMIC_OR_VOLATILE.test(cell.raw)) {
  unsafe.add(identity);
} else {
  unsafe.delete(identity);
}

When an edit message arrives from the UI coordinator, the worker decides in O(1) whether it must run a full topological pass or can execute a targeted incremental closure:

const nextLayout = JSON.stringify([
  data.sheets.map(s => [s.id, s.name, s.mergedRegions]),
  data.namedRanges,
  data.locale,
  data.currency,
]);

const needsFullPass =
  !store ||
  data.reset ||
  store.workbookId !== data.workbookId ||
  layout !== nextLayout ||
  unsafe.size > 0 ||
  store.sheets.some(s => s.spillOwners.size > 0);

Problem 3: Closing the Precedent Graph Before Evaluation

For the common case—workbooks filled with SUM, XLOOKUP, INDEX/MATCH, SUMIFS, IFERROR, PMT, and standard arithmetic—needsFullPass is false.

Instead of evaluating dependents immediately as we discover them (which risks reading half-updated intermediate cells in diamond dependencies like A1 -> B1, C1 -> D1), we first close the transitive dirty set across recorded range precedents [r1..r2, c1..c2], and then evaluate dirty formulas cleanly:

// Close the dependency graph before evaluation so chains see fresh values.
for (let i = 0; i < points.length; i++) {
  const [sheetName, key] = points[i];
  const [r, c] = key.split(',').map(Number);

  for (const [dependent, ranges] of store.precedents) {
    if (dirty.has(dependent)) continue;

    const hitsRange = ranges.some(
      x => x.sheetName === sheetName &&
           r >= x.r1 && r <= x.r2 &&
           c >= x.c1 && c <= x.c2
    );

    if (hitsRange) {
      dirty.add(dependent);
      const sep = dependent.lastIndexOf('!');
      points.push([dependent.slice(0, sep), dependent.slice(sep + 1)]);
    }
  }
}

And if a newly edited formula introduces a dynamic spill mid-evaluation, store._needsPass flips to true, seamlessly escalating to store.recalculateAllSync() before posting the delta payload back to the main thread.

Minimal Worker Payloads: Ship Only Formula Outputs, Not Whole Grids

Posting an entire WorkbookStore back across postMessage via structured cloning can easily serialize megabytes of formatting metadata on every edit. Instead, the worker returns a compact patch containing only:

• id: monotonic request ID so the UI coordinator ignores superseded calculations
• evaluated: exact count of cells recomputed (great for live telemetry & regression tests)
• values: [cellKey, computedValue] tuples strictly for formula cells
• spill & spillOwners: active dynamic array regions

Browser Spreadsheet Trade-Offs: Cloud SaaS vs. Local-First Worker Engine

Designing around Web Workers, IndexedDB, and an offline Service Worker changes the operational profile compared to cloud-only spreadsheets:

Key Takeaways for Heavy Browser Apps

1. Separate file parsing and formula calculation into independent workers. Importing a multi-sheet .xlsx archive shouldn't block UI scrolling or incremental cell edits.
2. Be honest about dynamic dependencies. Fast-path static range precedents (SUMIFS, XLOOKUP), and explicitly gate volatile/spill functions (INDIRECT, OFFSET, FILTER) into full-pass verification rather than risking silent stale values.
3. Return compact value diffs over postMessage. Keep cell style trees and DOM layout state on the main thread; let the worker own pure values and precedent ranges.

You can test the live worker engine directly in your browser (no sign-up) at sheets.arte-soft.com, or browse detailed formula and workflow comparisons against Excel, Google Sheets, LibreOffice Calc, and Numbers at sheets.arte-soft.com/compare/.

Transcribing chess puzzles by hand or scraping unverified problem collections breaks down fast. Two failure modes show up immediately in real training:

1. Cooked solutions: A position has a flashy sacrifice, so a human annotator marks it as winning—missing a quiet defensive resource at depth 18, or missing a second equally winning move that punishes a student for playing an objectively strong alternative.
2. Horizon flips: A shallow engine pass (depth 10–12) flags a move as +2.10, only for depth 22 to reveal perpetual check (0.00).

Instead of transcribing puzzles, we built a deterministic mining and independent verification pipeline powered by Stockfish 18. Along the way, we hit a subtle FEN validation edge case in chess.js that silently breaks UCI engines.

Stage 1: Mining for Uniqueness, Not Just Blunders

A good tactics puzzle isn't simply "someone blundered in a game." The actual mathematical requirement for a fair puzzle is uniqueness: exactly one legal move must preserve or seize a decisive advantage, while every alternative drops significant win probability.

Our generator runs a multi-stage filter:

1. Human-strength self-play seeding: Stockfish plays games at calibrated Elo bands (1320–2500), randomizing among shallow top candidates in the opening so positions diversify across pawn structures rather than repeating five mainlines.
2. Shallow two-line screen (Depth 12, MultiPV = 2): Every candidate position is evaluated with two principal variations. Most positions either have multiple good moves or zero good moves; both are discarded cheaply here.
3. Deep uniqueness confirmation (Depth 20, MultiPV = 2): Survivors are re-searched at depth 20. We only keep a candidate if bestMove beats the second-best move by at least 140 centipawns (>= 140 cp) and achieves a concrete evaluation swing.
4. Branchless line extension: We step forward along the principal variation, extending the puzzle ply by ply only while every solver turn continues to have a single uniquely best reply. The moment two moves become interchangeable, the puzzle terminates cleanly.

That pipeline produced 14,351 verified tactics puzzles spanning 760–2899 puzzle rating, alongside 116 positional judgement exercises (where no forced tactical win exists) and canonical endgame drills.

Stage 2: Independent Depth-22 Verification & Time Caps

Never trust the same search depth that generated your dataset to grade your dataset. In scripts/verify-puzzles.mjs, we spin up a fresh Stockfish instance and re-verify every puzzle two plies deeper (depth 22) with a per-position wall-clock ceiling (6000 ms) so fortress-like positions cannot stall batch runs for hours:

const { lines } = await engine.analyse(puzzle.fen, {
  depth: DEPTH,       // Default: 22 (two plies deeper than mining)
  movetime: TIME_CAP, // 6,000 ms ceiling for pathological positions
  multipv: 2,
});

if (lines.length < 2) {
  problems.push('only one legal move');
} else {
  if (lines[0].move !== puzzle.solution[0]) {
    problems.push(`deeper search prefers ${lines[0].move} over ${puzzle.solution[0]}`);
  }
  const gap = cpFor(lines[0].score, solverColor) - cpFor(lines[1].score, solverColor);
  if (gap < 100) {
    problems.push(`solution is not unique (gap ${gap}cp)`);
  }
}

Why Endgames Need Time Budgets Instead of Fixed Depth

For endgame drills (rook vs. pawn, opposition, Lucena, Philidor, two bishops), fixed search depth fails in both directions:

• In a bare KR vs K position, depth 28 finishes in milliseconds.
• In a minor-piece endgame with pawns on both wings, depth 28 explodes combinatorially and times out.

Switching endgame verification from fixed plies to a fixed 4,000 ms movetime budget gave consistent tablebase-like stability across all drills, asserting cp >= 400 (or forced mate) on positions labelled "win" and |cp| <= 150 on positions labelled "draw".

The Illegal-FEN Trap chess.js Won't Catch

When curating hand-crafted endgame drills or mutating FEN strings in tests, there is one mistake that is shockingly easy to make: placing a piece so that the side not to move is already in check.

No legal sequence of chess moves can ever reach such a position—because the player who just moved would have left (or moved) their own king into check.

Here is the catch:

• new Chess(fen) in chess.js accepts these FENs without throwing.
• When you pass that same FEN to Stockfish over UCI (position fen ... -> go movetime 4000), Stockfish immediately responds with bestmove (none)—which looks identical to an engine crash or pipe timeout if you aren't checking for it!

The fix is a 10-line helper that flips the active turn token in the FEN, clears the en-passant target square, and asks chess.js whether the swapped side is in check:

import { Chess } from 'chess.js';

/**
 * True when the side *not* to move is in check — an illegal position
 * that no game can reach. chess.js accepts these, and Stockfish replies
 * with "bestmove (none)", which is easy to misread as an engine crash.
 */
function opponentInCheck(fen) {
  const parts = fen.split(' ');
  parts[1] = parts[1] === 'w' ? 'b' : 'w';
  parts[3] = '-'; // Clear en-passant target before swapping active color
  try {
    return new Chess(parts.join(' ')).isCheck();
  } catch {
    return false;
  }
}

Adding opponentInCheck(fen) before invoking UCI saved hours of debugging mysterious empty engine evaluations during endgame drill authoring.

Grading Human Moves: Win Probability vs. Raw Centipawns

Raw centipawn loss (CPL) is a poor teacher for human players because engine centipawns are non-linear:

In Brass Pawn's coached play and native iOS/macOS trainer (which pairs Stockfish 18 with Reckless on-device), moves are graded by win-probability loss rather than raw centipawn deltas. Trading down into a clean, slightly lower-centipawn king-and-pawn endgame isn't penalized as an "inaccuracy" when win probability stays pinned near 99%.

Architecture Snapshot: Cloud Chess Platforms vs. Local Engine Study

Because the full puzzle set and neural engine run locally, there is zero network round-trip per ply and zero account wall:

Try the Code or Run Your Own Verification Pass

• Open-Source Repo (AGPLv3): github.com/minchopm/chess-trainer (npm install && npm start, or inspect scripts/verify-puzzles.mjs)
• Live Web & Native App Overview: brasspawn.com (also available natively on iPhone, iPad & Mac)
• Technical Chess Guides & Trainer Benchmarks: brasspawn.com/guides and brasspawn.com/compare

If you maintain chess tooling or puzzle generators in JavaScript or Swift, drop opponentInCheck() into your FEN ingestion tests—it catches broken test fixtures before they ever reach UCI.