DEV Community: Kevin Tang

I Ran DeepSeek V4 Flash Across Two DGX Sparks Over Ethernet

Kevin Tang — Sun, 06 Sep 2026 18:11:55 +0000

TL;DR: Two 128GB GB10 computers can run the official FP8 DeepSeek V4 Flash 0731 checkpoint as one tensor-parallel server over their built-in 10Gb Ethernet ports. My improvised link was roughly half as fast as the recipe's published 200G results, but it worked reliably: about 30 tokens per second for one stream, 85 tokens per second aggregate across six short requests, and a configured 1M-token context ceiling. The 200G cable is a performance requirement, not a functional requirement.

The 37.4 tok/s figure above is the median from my llm-gym comparison; the serving sweep later in this post measured 29–31 tok/s.

I had two 128GB GB10 computers, a 167GB model, and the wrong cable.

The computers were an NVIDIA DGX Spark and an ASUS Ascent GX10. They use the same Grace Blackwell GB10 platform, so together they give me 256GB of aggregate unified memory. The model was deepseek-ai/DeepSeek-V4-Flash-0731: 284 billion target-model parameters, 13 billion active at a time, plus an attached draft model for speculative decoding. The Hugging Face repository reports 304 billion parameters when that draft module is included.^[1]

On one Spark, I had already run a heavily compressed community build: an approximately 81GiB IQ2XXS/Q2 target model plus a 6.5GiB Q2K/Q8 draft model. It was surprisingly good. It scored 197 out of 199 on my llm-gym core benchmark and generated about 29.7 tokens per second.

But I wanted to run the official source checkpoint. It is commonly described as the FP8 model, which is fair shorthand, although “unquantized” is not. Its 48 weight shards occupy exactly 166,886,535,336 bytes, and its tensors use a mixture of FP8 E4M3 block-scaled storage, BF16, FP32, and packed integers. That does not fit comfortably on one 128GB system once the serving engine and KV cache need memory too.

Two boxes solve the capacity problem. NVIDIA even documents a two-Spark setup. The expected connection is the dedicated ConnectX-7 fabric: a QSFP cable carrying 200Gb/s Ethernet, separate from the ordinary RJ45 10GbE port.^[2]

Unfortunately, I had bought a QSFPTEK 400G QSFP-DD cable that these machines did not like. Both ends reported the same brutally clear status:

Cable unplugged

The ConnectX-7 device would briefly enumerate during boot and then power down. A community-reported compatible 200G QSFP56 DAC was on the way, but I did not feel like waiting.

Then I looked at the two unused RJ45 ports.

Ethernet is still a network

Each Spark has a built-in RJ45 10GBASE-T interface.^[3] I connected the machines directly with an ordinary Cat6/Cat6a Ethernet cable—no switch—and assigned a tiny point-to-point subnet:

nvidia-spark  enP7s7  10.10.10.1/30  MTU 9000
asus-spark    enP7s7  10.10.10.2/30  MTU 9000

I made the configuration persistent with NetworkManager. The commands looked like this, with the address changed for the second machine:

sudo nmcli connection add \
  type ethernet \
  ifname enP7s7 \
  con-name spark-direct-10g \
  ipv4.method manual \
  ipv4.addresses 10.10.10.1/30 \
  ipv4.never-default yes \
  ipv6.method disabled \
  802-3-ethernet.mtu 9000

Before involving CUDA, Docker, or DeepSeek, I tested the boring part. A 1GiB TCP transfer sustained about 9.9Gb/s from the NVIDIA box to the ASUS and 9.3Gb/s in reverse. Two simultaneous 84GB model transfers ran at roughly 1.0–1.1GB/s without link errors.

That established something useful: the cable and NICs were doing essentially everything 10GbE could do. If inference was slow later, I would not have to wonder whether I had accidentally negotiated at 1Gb/s.

I considered Wi-Fi too. It technically connected, but the machines were getting 702–867Mb/s PHY rates and wildly variable 68–79ms average ping times. That might be fine for sending prompts to a server. It is terrible for making two GPUs stop and synchronize repeatedly inside every generated token. I abandoned that idea quickly.

Convincing the recipe to use TCP

I used MiaAI Lab's two-DGX-Spark recipe, which packages vLLM tensor parallelism, DeepSeek's attached speculative draft model, and a 1M-token context configuration.^[4] The container was ghcr.io/anemll/dspark-vllm-gx10:0.1.1.

The recipe expected the ConnectX/RoCE path. Its startup logic tried to discover an InfiniBand or RoCE HCA and a GID before NCCL had a chance to fall back to an IP socket. With no working QSFP link, startup failed before the interesting work began.

I initially expected to patch the launcher. It turned out I did not need to. These were the important environment settings on the head node:

WORKER_HOST=10.10.10.2
MASTER_ADDR=10.10.10.1
MASTER_PORT=25000

NCCL_NET=Socket
NCCL_IB_DISABLE=1
NCCL_IB_HCA=unused
NCCL_IB_GID_AUTO=0
NCCL_SOCKET_IFNAME=enP7s7
TP_SOCKET_IFNAME=enP7s7
GLOO_SOCKET_IFNAME=enP7s7

VLLM_HOST_IP=10.10.10.1
WORKER_VLLM_HOST_IP=10.10.10.2
HF_HUB_OFFLINE=1

MAX_MODEL_LEN=1048576
MAX_NUM_SEQS=6
MTP_NUM_TOKENS=5

NCCL_NET=Socket selects NCCL's TCP/IP transport, while NCCL_SOCKET_IFNAME pins it to the direct 10GbE interface.^[5] Disabling IB and automatic GID discovery kept the launcher away from the disconnected ConnectX device. GLOO_SOCKET_IFNAME and the two vLLM host addresses made the rest of the distributed stack use the same route.

Both nodes also needed a complete local copy of the model. The 167GB checkpoint does not cross the cable at startup on every run, and it definitely does not cross it for every prompt. I staged the files on both machines and enabled Hugging Face offline mode so neither worker could quietly download a missing shard during launch.

Then the logs finally said what I wanted:

Bootstrap: Using enP7s7:10.10.10.1
NET/Socket

The full server took about 8 minutes 25 seconds to start. Model loading took roughly 244 seconds on the head and 153 seconds on the worker. Each tensor-parallel rank held about 79.2GiB of weights and allocated about 101GB of GPU/unified memory. The remaining 13.78GiB KV cache held approximately 1.96 million tokens in total—about 1.87 simultaneous full-context requests in the mathematical sense, though I would not actually serve it that way.

What crosses the cable

This is the part I had initially pictured incorrectly.

The model is not copied from one Spark to the other for every prompt. Tensor parallelism splits each large matrix operation across both ranks. Each machine keeps its own weight shard resident in memory, computes a partial result, and then NCCL exchanges or reduces intermediate tensors so the next operation can continue.

That communication happens over and over through the network. A 200Gb/s link has a theoretical line rate of 25GB/s. A 10Gb/s link has 1.25GB/s. The 200G fabric therefore has twenty times the raw bandwidth, along with lower latency and less TCP/IP overhead.

But twenty times the network bandwidth does not imply twenty times the token rate. Each token also spends time doing local memory reads, GPU math, routing through the mixture-of-experts layers, and speculative verification. Some communication can overlap with computation. The network only determines the portion of time spent waiting at distributed synchronization points.

There is another wrinkle specific to DGX Spark: NVIDIA says GPUDirect RDMA is not supported on its unified-memory architecture. Even the ConnectX path uses host buffers rather than letting the NIC directly DMA into GPU memory.^[6] The 200G connection still wins decisively on bandwidth, latency, RoCE behavior, and CPU overhead. It just is not magic direct NIC-to-GPU transfer on this machine.

Once I understood that, the 10GbE result stopped looking mysterious. NCCL supports a socket transport. I gave it a valid, fast-enough IP interface. Tensor parallelism cares that its collectives complete correctly; it does not care whether the connector looks impressive.

The results

I ran a bounded 256-output-token sweep across prompt lengths from 256 to 131,072 tokens and concurrency levels from one to six. All 20 test cases finished without NCCL errors, CUDA errors, out-of-memory failures, or worker restarts.

Here are the most useful points from that sweep:

Prompt	Concurrency	TTFT	Per-stream decode	Aggregate throughput
256 tokens	1	0.42s	30.47 tok/s	29.02 tok/s
256 tokens	6	1.97s	16.84 tok/s	85.48 tok/s
2,048 tokens	1	0.51s	31.05 tok/s	29.24 tok/s
8,192 tokens	1	8.63s	28.65 tok/s	14.57 tok/s
131,072 tokens	1	145.64s	30.17 tok/s	1.66 tok/s
131,072 tokens	6	496.73s	0.75 tok/s	1.79 tok/s

For ordinary chat-sized prompts, the experience was completely usable. Around 30 tokens per second is faster than I read. Six simultaneous short requests increased total throughput to 85.5 tokens per second, although each individual stream slowed and TTFT rose.

Long context exposed the real cost. Once generation began, even the 131K single request decoded at 30.2 tokens per second. Waiting 145.6 seconds for the first token was the problem. Six 131K requests were technically possible, but nearly eight and a half minutes to first token is not a serious interactive configuration.

That may still be good enough for overnight runs. If six long research or coding jobs are going to run for hours, I care more that they finish by morning than whether the first token appears in eight minutes. The same setup can be a bad interactive chat server and a useful batch machine.

I also ran vLLM's standardized benchmark with 2,048 input tokens, 128 output tokens, and 12 requests. At concurrency one it produced 31.49 output tokens per second with median TTFT of 583ms. At concurrency six it reached 72.03 aggregate output tokens per second with median TTFT of 1.79 seconds. The five-token speculative draft acceptance rate stayed around 65–67 percent.

How much did the cable cost? The recipe's matched published 200G sweep reported roughly 64–75 single-stream decode tokens per second depending on prompt length.^[4] My 10GbE setup delivered 29–31. In other words, ordinary Ethernet preserved about 40–46 percent of the intended single-stream speed.

Prompt	Published 200G	My 10GbE	10GbE share
256 tokens	75.4 tok/s	30.5 tok/s	40%
2,048 tokens	68.8 tok/s	31.1 tok/s	45%
8,192 tokens	73.9 tok/s	28.7 tok/s	39%
131,072 tokens	65.2 tok/s	30.2 tok/s	46%

That comparison is the closest thing here to a cable benchmark, but it is still not laboratory-perfect. It compares my machines and software state against the recipe authors' published run, not the same two machines with one variable changed. I will run the clean 10G-versus-200G A/B test when the correct DAC arrives.

The higher-precision model versus one box

I reran the same 199-question llm-gym core benchmark so I could compare this system with the compressed model I had been using on one Spark:

Deployment	Model format	Raw score	Weighted score	Median generation speed
One Spark	Community IQ2XXS/Q2	197/199	98.1	29.7 tok/s
Two Sparks over 10GbE	Official FP8 source checkpoint	196/199	96.0	37.4 tok/s

The two-box system was 7.7 tokens per second faster on this workload, or about 26 percent. The higher-fidelity weights did not produce a visible accuracy win on this small benchmark. Both models missed slightly different “flippy” questions, and a one-question raw difference is not enough evidence to claim either version is smarter.

That result was useful anyway. The compressed single-box model is not merely a consolation prize—it is an excellent practical configuration. The official FP8 model gives me higher-fidelity weights, the full intended serving path, more memory headroom, and better generation speed, but it spends a lot of its two-node advantage waiting on 10GbE.

This is also why “two boxes are faster” is too simple. The comparison changes the model format, serving engine, speculative draft, tensor parallelism, and network at the same time. The 26 percent is the result I observed, not an isolated claim about any one of those variables.

Why nobody recommends this

NVIDIA is not hiding the Ethernet port. It is documented as a separate 10GbE interface. The problem is that the validated cluster path is the 200G ConnectX fabric, so all the setup tooling, diagrams, and troubleshooting instructions naturally assume that topology. NVIDIA's cluster assistant even uses roughly 184Gb/s as the lower bound for a healthy expected link.^[2]

That is reasonable. If a vendor published “you can use the RJ45 port,” many people would interpret that as “the RJ45 port performs the same.” It does not. My short-prompt single-stream result lost more than half the published token rate, and long-context TTFT became painful.

The software defaults reinforce the assumption. The recipe went looking for an HCA and a GID because every normal deployment of this configuration has them. The socket path was already inside NCCL, but I had to explicitly route the rest of the launcher around its RoCE expectations.

So this is not the setup I would recommend buying on purpose. It is the setup I would recommend trying if:

The correct 200G cable is delayed or unavailable.
You want to prove that both nodes, model shards, Docker image, SSH setup, and vLLM configuration work before debugging the high-speed fabric.
You care more about fitting the model than maximizing its speed.
You already own the two machines and an Ethernet cable, which makes the experiment effectively free.

For latency-sensitive serving, heavy concurrency, or long-context prefill, buy the compatible 200G DAC. For Wi-Fi, I would not tensor-parallelize at all—I would run independent models and route whole requests between them.

What I learned

The interesting distinction was not between “supported” and “unsupported.” It was between capacity, correctness, and performance.

Two machines gave me the capacity to hold the official checkpoint. NCCL's TCP socket transport gave me correctness over an ordinary network. The expensive fabric gives performance by reducing the time both ranks spend waiting for each other.

I am still going to install the 200G cable when it arrives. I now know exactly what it buys me: not the ability to run the model, but time back at every synchronization point.

Until then, an ordinary Ethernet cable is carrying DeepSeek between two little boxes on my desk, which is much funnier than it has any right to be.

Citations

DeepSeek V4 Flash 0731 model repository, DeepSeek AI. ↩
Connecting two DGX Sparks and DGX Spark Cluster Assistant, NVIDIA. ↩
DGX Spark hardware overview, NVIDIA. ↩
DeepSeek V4 Flash DSpark on two DGX Sparks, MiaAI Lab. ↩
NCCL environment variables, NVIDIA. ↩
DGX Spark CUDA porting guide: GPUDirect RDMA limitations, NVIDIA. ↩

Your iPhone Is an OpenAI-Compatible LLM Server Now

Kevin Tang — Sun, 06 Sep 2026 18:11:15 +0000

TL;DR: Local LLM Server turns an iPhone, iPad, or Mac into an LLM server: Apple's on-device Foundation Models exposed over an OpenAI- and Ollama-compatible HTTP API. Any existing client library points at your phone's LAN address and just works. Free with ads; Pro is $1.99 without them.

Apple Intelligence ships a ~3B-parameter language model on every recent iPhone, running locally on the neural engine. It's genuinely capable for structured tasks—classification, extraction, summaries—and it costs nothing per token. The catch: Apple exposes it as a Swift framework. If your tooling speaks HTTP—Python scripts, LangChain, DSPy, a curl one-liner, literally the entire LLM ecosystem—there's no door in.

Local LLM Server is that door. Open the app, pick a port, hit Start Server, and the device serves at http://<your-lan-ip>:8080 with the two API shapes everything already understands: OpenAI's (/v1/chat/completions and friends) and Ollama's. Your OpenAI client library doesn't know it's talking to a phone.

The phone is the server.

What "compatible" actually covers

The parts I'm most pleased with, because they're the parts most wrappers skip:

Structured outputs — response_format with a JSON schema drives Apple's guided generation, so you get valid JSON back, not JSON-shaped prose.
Tool / function calling — the standard OpenAI client-executed loop.
Real token counts — usage comes from the actual tokenizer, with a context_length_exceeded preflight instead of a mystery truncation.
Embeddings — /v1/embeddings served from Apple's contextual embedding model, also on-device.
A browser playground at GET /, optional Bearer auth, LAN or localhost-only binding, and App Intents so Shortcuts can start and stop the server.

The compatibility test I actually care about: existing chat clients talking to the phone.

There's a 90-test suite behind the API surface. One user wired the server into DSPy for prompt optimization against the on-device model, which is exactly the kind of thing I hoped people would do and did not want to explain was impossible.

Why bother, when you could call a cloud API?

Three answers, in my order of caring: it's private (prompts never leave the device—for some data that's not a preference, it's the requirement); it's free at the margin (bulk classification jobs cost zero tokens); and it's always with you (the server is in your pocket, on a plane, in a dead zone). The honest counterweight: it's a 3B model. It will not write your novel. For extraction, tagging, structured summaries, and glue-code intelligence, it's shockingly serviceable—and those are most of what scripts actually need.

The important line: on-device processing, no cloud round-trip.

Free vs Pro

The free app is ad-supported; Local LLM Server Pro is $1.99, one-time, no ads. Same server, same API. Pro briefly hit #5 on the US paid Developer Tools chart—a thin, volatile chart, so I won't pretend that's fame, but it did tell me this audience would rather pay two dollars than look at a banner, which matches how I feel about banners.

Tiny chart, still a real signal: Local LLM Server Pro at #5 in Developer Tools.

Requires iOS/iPadOS/macOS 26+ on Apple Intelligence-capable hardware (that's where the on-device model lives). If you've got a spare device on your desk, it's a free local inference endpoint you didn't know you owned.

The Business Card That Lights Up When You Tap It

Kevin Tang — Sun, 06 Sep 2026 18:09:51 +0000

TL;DR: I made a circuit-board business card with an NFC chip and a batteryless LED powered by the phone tapping it. The hardware worked, but ordinary iPhone NFC apps couldn't format the blank NTAG I²C Plus chip. I wrote a tiny Core NFC app that sends the chip's native commands directly, and now each tap opens my site and lights Charizard's tail.

I wanted a business card that wasn't a piece of paper. Not out of some deep philosophy—I just thought it would be fun to hand someone a circuit board. So I designed one: credit-card sized, glossy black, with gold artwork and my name on it. Standard so far. The two things that make it not-just-a-card are both invisible until you bring a phone near it.

The first is an NFC chip. Tap the card to a phone and it opens kevintang.xyz—the same technology as a tap-to-pay card or a transit pass, running at 13.56 MHz^[1]. There's a spiral of copper wound seven times around the edge of the board; that's the antenna, and getting it to resonate at the right frequency is most of the work. That part I expected.

The second thing is the part I can't stop thinking about. There's a little Charizard printed on the card, and a red LED sits right at the tip of its tail—so tap the card to a phone and its tail catches fire. There's no battery on the card. There's no coin cell, no wire, nothing to charge. The LED is running entirely on energy the phone is throwing off.

The card mid-write—my own little app pushing the URL onto the chip—with the harvest LED lit from nothing but the phone's field. Several more waiting their turn.

An object that borrows power

Here's what's actually happening, and it took me a while to stop finding it magical (I haven't, really). An NFC phone doesn't just listen for a tag—it broadcasts a strong radio field to power the tag, because the tag has no battery either. The chip in a normal NFC sticker wakes up on that borrowed energy just long enough to answer, then goes dark the moment the phone leaves. What I didn't appreciate until I built one is that some chips will hand you the leftover power on a pin, to do whatever you want with. NXP's datasheet lists a typical harvested output of about 5 milliamps at 2 volts under one test setup^[2]—not much, but plenty to light an LED, or blink a low-power sensor, or wake a tiny microcontroller for a fraction of a second.

And the way it answers is stranger than it sounds: the tag never transmits a signal of its own. It replies by changing how much of the phone's field it absorbs, instant to instant, and the phone feels those little tugs on its own signal and reads them as ones and zeros. The analogy I keep coming back to is a mirror. A mirror makes no light—it only reflects a source. A passive NFC tag makes no radio of its own—it reflects the phone's, flickering it into a message. The phone brings all the energy; the card just decides what to bounce back.

(This, incidentally, is the NFC-versus-RFID distinction I used to fumble: NFC isn't a rival to RFID, it's the short-range, 13.56 MHz corner of it—close range on purpose, so the card talks only to the thing you deliberately touch it to.)

I'd always thought of NFC as a way to make the phone do something: open a link, pay for coffee, check in. But this flips it. The tap makes the card do something. For the half-second your phone is near it, the card is a live device—an inert rectangle of fiberglass that comes alive in your hand because you brought a battery near it. Once you've felt that, you start seeing NFC taps differently. You're not reading the tag. You're powering it.

It's not a brand-new idea—U.S. Bank shipped a credit card a few years ago whose logo glows during a contactless payment, and it was popular enough that they ran short of them^[3]—but it's rare, and it feels like a small miracle every time. And it points at a whole category of objects: things that don't need a battery because they only need to be alive for the instant you're touching them with a phone you were already holding.

The card is a program

I designed the whole board as code, which I'd recommend to anyone who, like me, finds dragging traces around with a mouse maddening. KiCad—the free PCB tool—has a Python API, so the entire card is generated by a script. Every trace, the antenna coil, the position of each letter: it's all computed. Want the coil to have one more turn? Change a number, re-run, done. The board is reproducible the way a program is reproducible, which for a hardware novice is enormously reassuring—there's no precious hand-drawn artifact I'm afraid to touch.

I couldn't resist a couple of jokes for anyone who'd flip the card over. The back is laid out like a component datasheet—the dense reference document every hardware part ships with—complete with the actual resonance math for the antenna printed right there in the silkscreen, and two real exposed test points a curious engineer could probe with a meter to check my numbers. And on the front, where a chip card has its little gold square of contacts, mine has only a drawing of one—that same eight-pad footprint printed into the board with nothing underneath it. The real NFC chip is hidden on the back; the thing that looks like the chip is a decoy. Anyone who's laid out a circuit board clocks it instantly—everyone else just sees a chip card. It's there for whoever looks closely.

The back, straight from the design files—laid out like a real datasheet, resonance math and all, with TP1/TP2 you can actually probe. The Charizard's tail is where the LED lives.

Then I sent it to a factory. This is the genuinely wild part of modern hardware: I uploaded my files to JLCPCB, and for about seventy-five dollars they manufactured ten copies and soldered the chip and the LED onto each one^[4]. Ten assembled circuit boards, in the mail, for the price of a nice dinner. A few days later, this little blue box showed up:

Inside were ten beautiful cards, and I was very pleased with myself. For about a day.

Then I couldn't write to it

I tapped the first card to my phone. The LED flickered—so it was getting power, the antenna worked, the hard electrical part was fine—but nothing happened. No link. The card had power but no message.

That's expected: a blank chip needs you to write the URL onto it. So I opened NFC Tools, the standard app everyone uses for this, held the card to my iPhone, and got: "NFC tag not supported."

I had made a rookie mistake in chip selection. The chip I'd picked, the NTAG I²C Plus^[2], is not really a plain sticker tag. It's a bridge chip—designed to sit inside a gadget and talk to a microcontroller over a wire, with the NFC part as a bonus. It's the same chip that gives me the energy-harvesting pin I wanted for the LED, which is exactly why I chose it. But it ships blank, without the NDEF formatting that tells a consumer app where a URL record belongs. NFC Tools uses iOS's high-level NDEF path, which treated my blank chip as unsupported instead of formatting it.

Fine, I thought. I'll try an Android instead—its NFC stack is far more permissive about this kind of thing. I dug out my backup phone, went to install the app, and discovered that my cheap prepaid Android doesn't have an NFC radio at all. The model officially supports NFC; my particular carrier's version of it had the chip left out to save a dollar. The phone literally cannot do NFC. There is no app for missing hardware.

The ordinary iPhone app wouldn't; my Android couldn't. Ten gorgeous cards, and no way to put a single word on any of them.

Writing my own key

The thing that got me unstuck was realizing the consumer apps weren't failing because the chip couldn't be written—they were stopping at the high-level NDEF check. Underneath, this chip answers the same basic memory commands as common NFC tags. It's command-compatible where it counts. The apps were bouncers checking IDs at the door; the chip inside would happily take my order.

And iOS, it turns out, will let you send a tag raw commands—if you're willing to write the app yourself. Apple's Core NFC framework has a low-level mode where you talk to the tag directly instead of asking iOS to interpret it for you^[5]. So I wrote a very small iPhone app—about sixty lines that matter—that does exactly one thing: open an NFC session and send the write commands by hand. First the little header that declares "I'm a URL tag," then my web address, spelled out four bytes at a time across the chip's memory, each command acknowledged before the next.

I built it onto my phone, opened it, tapped a card, and watched it count up the pages: writing, writing, done. Then I locked the phone, tapped the card again like a stranger would, and a banner popped up offering to open my site. It worked. It has worked on every card since.

One quirk: I have to hold the card right against the top edge of the phone or the write fails. The coupling is tight, and I'm fairly sure the reason is that glowing LED—it's drinking some of the same power the chip needs to do its job, so there's less margin than a plain tag would have. A fun problem to have. It's on the list for the next revision: a little less glow, a little more range, and decide how I feel about that trade.

The part I keep thinking about

What this drove home—again—is that the hard part of a hardware project is often the software at the very end: the last inch between "the object physically exists" and "the object does the thing." The electronics were textbook. The antenna math worked on the first try. What nearly beat me was a compatibility checkbox in an app that had never heard of my chip.

But that's not what I think about when I hold the card. What I think about is the glow. It's a flat piece of fiberglass with no power source, and it comes alive because you waved a phone at it. I set out to make a business card that opens a website, which is a mildly clever party trick. I ended up more interested in the few milliwatts of borrowed light—because that same trick, the object waking up on power it doesn't own, is the seed of a hundred other things I now want to build.

Anyway. If we meet and I hand you a black card, tap it. And watch the tail.

Citations

[1] Near-field communication — Wikipedia (NFC operates at 13.56 MHz) ↩

[2] NT3H2111/NT3H2211 NTAG I²C plus datasheet — NXP Semiconductors (energy harvesting output, ~5 mA typical) ↩

[3] U.S. Bank Shopper Cash Rewards Visa launch — Business Wire (LED card that illuminates during contactless payment) ↩

[4] JLCPCB — PCB fabrication and assembly service ↩

[5] sendMiFareCommand — Apple Developer documentation (sending native commands to an NFC tag) ↩

How to Jump to the Top or Bottom of Any App on macOS

Kevin Tang — Sun, 06 Sep 2026 18:08:09 +0000

I spend a lot of my day at the bottom of something. A long Slack channel, a 400-comment GitHub thread, a chat log, a diff that someone clearly generated with a for-loop. And constantly I want to get back to the top — or shoot down to the very bottom — and on a Mac there is no obvious, universal way to do it.

You'd think there would be. iOS has it: tap the status bar, you're at the top. Every iPhone user knows that one. On the Mac? It depends entirely on which app you happen to be in, and the answer changes app to app in ways that have quietly annoyed me for years.

So here's the actual state of jumping to the top or bottom on macOS — the shortcuts that exist, why they're such a mess, and what I eventually did about it.

The keyboard shortcuts (such as they are)

In a lot of apps, ⌘↑ (Command + Up Arrow) jumps to the top of the document and ⌘↓ to the bottom. Safari, Chrome, Notes, most plain text views — this works. Great.

Except:

In Finder, ⌘↑ doesn't scroll to the top. It opens the enclosing folder. Muscle memory from your browser will quietly send you up a directory.
In Terminal and iTerm, ⌘↑ scrolls to the previous command, not the top. To reach the very top of the scrollback you want ⌘Home — if your keyboard even has a Home key.
Which is the other problem: Home and End. On a full-size keyboard, Home jumps to the top of a field and End to the bottom, and they're great. But Apple stopped putting Home and End keys on laptops a long time ago. On a MacBook you fake them with Fn + Left Arrow (Home) and Fn + Right Arrow (End) — and even then, in many apps they move the text cursor rather than the scroll position, which is a different thing entirely.

There's also Space to page down and Shift + Space to page up, which is genuinely useful and underused — but that's paging, not jumping, and you'll be mashing it a while to clear a long page.

So the honest summary: there are roughly four different ways to scroll to the top of something on a Mac, none of them work everywhere, and the keys you'd most want to reach for don't exist on the keyboard you actually own.

Why is it like this?

I don't think anyone decided this on purpose. macOS never standardized "go to top / go to bottom" the way it standardized copy and paste — each app's developer wired up ⌘↑, Home, and the rest to whatever made sense in their app, and they all made slightly different, individually reasonable choices. Then laptops dropped the dedicated navigation keys to save space, and the whole thing calcified into the mess we have now. iOS, built later and from a blank page, got the clean version: tap the top, you're home.

You adapt, of course. You learn that Finder is weird, you learn ⌘Home in the terminal, you reach for the scrollbar when in doubt. But "you adapt" is the sentence I tend to say right before I build something.

What I did about it

I made a tiny menu-bar app called Scroll Elevator. The idea is almost embarrassing in how direct it is: when you scroll, two little elevator buttons appear right at your cursor — one to jump to the top, one to the bottom. Click and the window leaps there. Hold one and the page glides, faster the longer you hold. Move your mouse away and they fade.

What makes it click is that your hand never leaves the trackpad. To hit Home or ⌘↑ you reach for the keyboard and have to remember which incantation this particular app wants; Scroll Elevator puts top and bottom under the cursor your hand is already on. And it behaves the same in Chrome, Finder, Preview, Mail, Xcode, and your terminal — because under the hood it drives each app's own scrollbar instead of firing a keystroke and hoping.

It's $4.99, one time, signed and notarized, and nothing ever leaves your Mac. If you'd rather not pay, the whole thing is open source and you can build it yourself for free — I mean that, the instructions are right there in the README.

Is a dedicated app for "scroll to the top" overkill? Maybe. But I do it something like fifty times a day, and the friction was real enough that I'd rather have one button than a flowchart of keyboard shortcuts in my head. If you've ever pressed ⌘↑ in Finder and watched it jump up a folder instead, you know the exact feeling I'm talking about.

A Game Controller Is a Second Keyboard for Your Mac

Kevin Tang — Sun, 06 Sep 2026 18:06:45 +0000

TL;DR: a game controller is a wireless macro pad you may already own. ControllerKeys maps its buttons, sticks, triggers, paddles, touchpads, and motion sensors—whichever ones the hardware actually has—to keyboard shortcuts, mouse input, macros, scripts, webhooks, OBS, and other Mac actions. It supports the familiar Xbox and PlayStation controllers, but also Nintendo, Steam, Apple TV, 8BitDo, and more than 300 third-party gamepads.

People pay $150 for a Stream Deck: fifteen buttons, wired to the desk. Meanwhile there is probably a DualSense, Xbox controller, Joy-Con, or tiny 8BitDo pad in a drawer somewhere. It already has Bluetooth, controls shaped for muscle memory, and enough inputs to run a surprising amount of a Mac. That asymmetry bothered me enough that I built ControllerKeys.

The core mechanic is layers. Hold or toggle a trigger and every button can mean something different. ControllerKeys supports up to twelve layers per profile, and unmapped controls can fall through to the layer below. A controller is not just one small keyboard—it can be a timeline controller, presentation remote, media remote, and automation console without changing devices.

Which game controllers work on a Mac?

ControllerKeys has first-class layouts and hardware-specific handling for these controllers:

Family	Supported controllers and special hardware
Xbox	Xbox Series X\|S, Xbox One, Xbox 360, and Xbox Elite Series 2—including all four rear paddles
PlayStation	PS5 DualSense, DualSense Edge, and PS4 DualShock 4 v1/v2—including touchpad regions, gyro, lightbar, and Edge paddles
Nintendo	Switch Pro Controller, a single Joy-Con, or paired left and right Joy-Cons
Valve	Original Steam Controller—including both touchpads, gyro, grips, and haptics, without Steam running
Apple	Second-generation Siri Remote / Apple TV Remote—including clickpad cursor control, side buttons, and iPod-wheel-style edge scrolling
8BitDo	Zero 2 and Micro with dedicated layouts and corrected raw d-pad input, plus Pro 2, SN30 Pro, SN30 Pro+, Ultimate, Lite, Lite 2, Lite SE, and many others

That is only the first-class list. Any standard controller recognized by macOS's GameController framework can work out of the box. If macOS does not expose a useful mapping, ControllerKeys can read the raw HID device and apply a bundled copy of the SDL GameControllerDB. The current bundle contains 314 macOS mappings, including models from Logitech, PowerA, Hori, Razer, SteelSeries, GameSir, Amazon Luna, Google Stadia, and many smaller brands.

There is an important distinction here: a DualSense, Steam Controller, Siri Remote, or 8BitDo Micro gets device-specific handling for its unusual controls. A generic SDL fallback controller gets its standard buttons, sticks, and triggers mapped automatically. I would rather make that boundary clear than pretend every obscure gamepad has a gyroscope or touchpad it does not physically contain.

What can a controller button do on macOS?

A button can send a key or keyboard shortcut, hold a modifier, click or drag the mouse, type or paste text, launch an app, open a link, switch profiles, run a shell command or JavaScript, send an HTTP webhook, control OBS over WebSocket, or output a virtual MIDI control change. Macros chain those actions with delays.

Tap, double-tap, long-hold, repeat, chords, and ordered button sequences are separate triggers. Profiles can switch automatically with the frontmost app or the connected controller. The sticks can control the pointer, scrolling, WASD, arrow keys, or eight custom directions. DualSense and DualShock 4 owners can also use the gyro as a mouse and split the touchpad into four independently mappable regions.

That feature list sounds excessive until it is attached to a real workflow. These are the five where the controller has earned a permanent spot on my desk—or on somebody else's.

1. Video editing from the couch

Map a stick to scrolling or bind its directions to J, K, L, and the arrow keys, depending on the editor. Put cut, trim, ripple delete, undo, and markers on the face buttons. Hold L2 for color controls and R2 for audio. A macro can handle the multi-step actions, such as exporting the current range.

The advantage is not that a controller replaces every editing surface. It is that common timeline work becomes comfortable from a couch, standing desk, or any position where a keyboard full of memorized chords is awkward.

2. OBS scenes without a Stream Deck

ControllerKeys speaks OBS WebSocket directly and can import Stream Deck V2 profiles. Buttons, chords, and macros can switch scenes, toggle sources or filters, start or stop recording, and mute audio. The optional stream overlay shows controller input inside an OBS capture.

The use case that surprised me was a physics professor at Arizona State running 200-student hybrid lectures with a DualSense. OBS scene switching goes on the face buttons, slides on the shoulders, and the touchpad becomes a cursor. The controller also has a laser-pointer overlay and a ready-made Google Slides / PowerPoint profile. Unlike a wired control deck, it can travel around a lecture hall.

3. Use an Xbox or PS5 controller as a Mac mouse

For a Mac mini connected to a TV, one stick moves the mouse and the other scrolls. A trigger can slow the pointer for precise clicks. The on-screen keyboard supports d-pad navigation and touchpad swipe typing, while the app bar, media controls, command wheel, and directory navigator cover the things I would otherwise get up to find a keyboard for.

ControllerKeys can also hand the controller-driven pointer, keyboard events, and mapped actions from one Mac to another over the local network or Tailscale. It is essentially Universal Control for the controller sitting in your hands.

4. Anki with a game controller

Medical students found ControllerKeys on their own and became one of its clearest audiences. Put Again, Hard, Good, and Easy on four buttons and review cards without hovering over a keyboard. That matters when the same four actions happen thousands of times.

I wrote the full setup up separately and included a prebuilt AnKing profile: Anki on a Game Controller.

The tiny 8BitDo Zero 2 and Micro are especially good here. ControllerKeys has dedicated layouts for both, including a raw-input fix for d-pads that macOS can misread.

5. Everyday Mac macros

This is the boring one I use most. Window snapping on the d-pad, tap to paste a text snippet, double-tap for a shell command, long-hold to switch apps. Four face buttons already hold twelve actions before adding a chord or layer.

The same system works for presentation controls, music production through virtual MIDI, smart-home HTTP requests, scripts that inspect the frontmost app, or app-specific shortcuts that activate only when Final Cut Pro, Photoshop, a browser, or a terminal is in front. Realtime mode skips the advanced-trigger delay for simple key mappings when latency matters.

I wrote more about why controller chords stay usable when keyboard shortcuts do not in Every Shortcut Within Reach.

The honest caveats

Bluetooth pairing is still Bluetooth pairing, and occasionally macOS will make that annoying. ControllerKeys also needs Accessibility permission to generate keyboard and mouse events; Automation permission is requested only for features that need it. The source is public for inspection, but it is source-available under PolyForm Noncommercial 1.0.0—not permissively licensed open-source software.

There is a learning curve. The first hour with a blank profile is remapping, not productivity. Community profiles and setup guides make that easier, and configuration history lets you undo a bad import or destructive edit.

ControllerKeys requires macOS 14.6 or later. The full app is free to try for 14 days with no account, then a one-time license is $19.99. Install it with Homebrew:

brew install --cask nsevent/tap/controllerkeys

Or download the latest notarized DMG from GitHub. The ControllerKeys website has videos, controller-specific guides, and the full feature list; the public source is available if you want to inspect it or build your own noncommercial copy.