DEV Community: Kirill Lukyanov

iPhone Duo: What Apple's 'Boring' Keynote Actually Means for iOS Developers

Kirill Lukyanov — Mon, 14 Sep 2026 14:28:34 +0000

Apple's September keynote felt like "nothing interesting": a slightly faster Pro, a slightly pricier Pro, new watches, new earbuds, and a foldable that looked almost exactly like the leaks. For buyers, that's a fair summary. For iOS developers, it's the opposite — the evening quietly delivered the biggest layout change since the iPhone X notch, and the clock on it runs out on October 23.

The day before the event I published 13 predictions with probabilities. Here's how they did, what was actually shown, and — the part I really care about — what the iPhone Duo's inner display means for your code.

Scorecard: 11 out of 13

Probabilities were set on the morning of September 9, before the stream, and haven't been touched since. Anything below 50% means I was betting against the event.

Prediction	My odds	What happened	Result
A foldable iPhone is shown	95%	Shown — iPhone Duo	✓
It's called iPhone Ultra	55%	It's called iPhone Duo	✗
Foldable starts at $2,000	85%	$1,999 for 256 GB	✓
Touch ID instead of Face ID on the foldable	75%	Touch ID in the side button	✓
No telephoto on the foldable	70%	Main 48 MP + ultra wide; 2x is a crop of the main sensor	✓
No base iPhone 18	90%	Moved to spring 2027	✓
A20 Pro on 2 nm in all three iPhones	90%	All three	✓
iPhone 18 Pro gets at least $100 pricier	70%	$1,199 / $1,299 — exactly +$100	✓
Variable aperture on the Pro main camera	65%	Yes, plus manual aperture and shutter	✓
Ceramic Apple Watch Series 12	70%	Ceramic finish in the lineup	✓
AirPods 5 with a new H3 chip	65%	H3, $129 / $149 — ANC on both models	✓
Home hub is shown (bet against)	35%	Not shown	✓
Something not in any leak (bet against)	30%	Front camera under the foldable's inner display	✗

Brier score: 0.118 (answering 50/50 on everything scores 0.25). I missed exactly where I warned I would: specs leak for months because thousands of factory workers know them, while the name is known by about twenty people who stay quiet. And I got cocky betting against a surprise.

What was announced

Device	US price	Pre-order	Available
iPhone 18 Pro	from $1,199	Sep 12	Sep 18
iPhone 18 Pro Max	from $1,299	Sep 12	Sep 18
iPhone Duo	from $1,999	Oct 16	Oct 23
Apple Watch Series 12	from $399	now	Sep 18
Apple Watch Ultra 4	from $799	now	Sep 18
AirPods 5	$129 / $149	now	Sep 18
iOS 27, macOS Golden Gate & co	free	—	Sep 14

The good: a foldable whose two displays share (almost) the same proportions, so content scales instead of reflowing; Split View on an iPhone for the first time; a real variable aperture; 45 hours of video on the Pro Max; ANC in the $129 AirPods; and Apple Reference Image, which signs sensor data so a photo can later be proven to be a photo — arguably the most underrated announcement of the night.

The not-so-good: +$100 on the Pro and +$300 on the 1 TB tier, price bumps on older models; Siri AI ships in beta, English-only, with daily usage limits and "expanded access for a fee in the future" (and not at all on iPhone in the EU or mainland China); the iPhone 18 Pro display is unchanged apart from a narrower Dynamic Island; the Duo is eSIM-only and doesn't support Apple Pencil Pro.

Not shown: the base iPhone 18, the home hub, HomePod mini, Apple TV, any Mac — and, for developers, the iOS 27.1 SDK.

The new screen in numbers

For 19 years the iPhone has been a tall, narrow strip: 1.5 on the original, 2.17 on today's Pro Max. Every mobile layout we write grew up inside that strip. The Duo's inner display breaks it.

	iPhone 18 Pro Max	Duo, outer	Duo, inner
Diagonal	6.9″	5.4″	7.6″
Pixels	1320 × 2868	1398 × 2034	2670 × 1878
Points (w × h)	440 × 956	466 × 678	890 × 626
Density	460 ppi	460 ppi	430 ppi
Aspect ratio	2.17	1.45	1.42
Size classes (portrait)	compact × regular	compact × regular	regular × regular
Supported orientations	honored	honored	ignored

Three takeaways:

1.42 is roughly √2 — the A4 paper ratio. Fold such a sheet in half and each half keeps the same shape. In Split View the inner display splits into two panes of roughly 445 × 626 points, each almost the shape of the outer display. Two apps side by side each get an "outer screen". That's hardware designed with software in mind.
The open Duo is wider than tall. It's not a phone turned sideways — it's the new default posture. The Dynamic Island sits vertically on the side, so safe-area insets are asymmetric, and with the 27.1 SDK vertical bars move to the left edge.
16:9 video loses. At 890 points wide a video is 890 × 501, leaving 125 points of black — a fifth of the screen.

How the Duo shows your app if you do nothing

Built without the iOS 27 SDK: a familiar phone-sized window in the middle of the inner display, surrounded by black. A postcard in a giant frame.
Built with the iOS 27 SDK: wider, but part of the screen is still empty.
Built with the iOS 27.1 SDK: edge to edge, toolbars and tab bars move to the left. This is the native look — and the SDK for it isn't even in beta yet.

What to grep for this week

The good news: almost all of this is stuff Apple has asked us to do for years. The bad news: iPhones were always narrow, and plenty of codebases quietly relied on it. The Duo is still an iPhone, but inside it's regular × regular, like an iPad.

In your code	Why it breaks on Duo	Replace with
`UIScreen.main.bounds`, hardcoded widths	Two differently shaped screens, the app moves between them live	Your view's geometry (`onGeometryChange`), screen via `UIWindowScene`
Interface orientation checks	The inner display ignores supported orientations	`horizontalSizeClass` / `verticalSizeClass`
`userInterfaceIdiom == .phone` as "narrow screen"	Duo is an iPhone with regular × regular and Split View	Layout by size class, not by device type
Symmetric safe-area insets	The Dynamic Island is on the side	Handle each inset and margin independently
`UIRequiresFullScreen` in Info.plist	No longer prevents resizing from iOS 27	Support live resizing
A hardcoded "Sign in with Face ID" label	Duo has Touch ID in the side button	Branch on `LAContext.biometryType`
One window per app	Split View opens multiple scenes, new windows only on the inner display	Support multiple scenes and handle refused requests

Biometrics is the easy one:

import LocalAuthentication

func biometryLabel() -> String {
    let context = LAContext()
    _ = context.canEvaluatePolicy(.deviceOwnerAuthentication, error: nil)
    return switch context.biometryType {
    case .faceID:  "Sign in with Face ID"
    case .touchID: "Sign in with Touch ID"
    case .opticID: "Sign in with Optic ID"
    default:       "Sign in with passcode"
    }
}

Layout isn't rocket science either if you're on SwiftUI — NavigationSplitView collapses to one column in compact width and expands on the inner display:

struct RootView: View {
    @Environment(\.horizontalSizeClass) private var hSize

    var body: some View {
        NavigationSplitView {
            SidebarList()
        } detail: {
            DetailView()
                .padding(hSize == .regular ? 32 : 16)
        }
    }
}

Apple's "Preparing your app for iPhone Duo" material also names foldable-specific APIs: onHingeChange / UIHingeInteraction for hinge states and angle, ArrangementView / UIArrangementViewController for two-pane layouts around the fold, reservedRegion on GeometryProxy / UIView to keep controls off the fold, CameraCaptureAccessory for a preview or teleprompter on the outer display, and AVCaptureDeviceDirectionCoordinator — because camera position is no longer camera direction.

Two easy-to-miss extras: StandBy on the Duo runs on either display even when not charging, so apps without widgets or Live Activities simply don't exist there. And health apps should expect a lot more data — Series 12 and Ultra 4 sample heart rate every five seconds all day.

The next six weeks

Sep 14 — iOS 27 ships. Its SDK (already in RC) decides whether your app resizes.
Sep 16–17 — Apple group labs on iPhone Duo; Q&As on Sep 23.
Xcode 27.1 beta — iOS 27.1 SDK and a Duo simulator you can open, close, rotate and partially fold.
Oct 23 — iPhone Duo ships on iOS 27.1, and people who paid $1,999 start opening your app.

Bottom line

If you own an iPhone 16 Pro or 17 Pro, you could have skipped this keynote. If you write iOS apps, this is the busiest autumn since 2017, when the iPhone X taught everyone the words "safe area". This time the lesson is that an iPhone can be wider than it is tall, that size classes on a phone aren't a formality, and that one window per app is no longer a given. The keynote was boring precisely because everything important in it was for Xcode, not for the store window.

How many UIScreen.main references are in your project?

Originally published at klukyanov.ru.

The Keynote Without Tim Cook: My Bets on What Apple Announces Today

Kirill Lukyanov — Wed, 09 Sep 2026 10:37:49 +0000

Today at 8pm Moscow time, Apple is holding its first fall keynote in fifteen years without Tim Cook on stage — and, if the leaks hold up, its first-ever foldable iPhone reveal. I'm writing this before the event starts. Not another leak roundup — there will be a hundred of those today — but my own predictions, with probabilities attached, so I can come back after the dust settles and check where I was wrong.

A new person on stage — and it matters

On September 1, 2026, Tim Cook moved into the role of Executive Chairman, and John Ternus became Apple's CEO. Cook spent fifteen years in the role and leaves with the company valued around $4.6 trillion. Today's keynote is Ternus's first major public appearance in the new job.

His background matters here. Ternus has spent twenty-five years at Apple, trained as a mechanical engineer, and most recently ran hardware engineering — Apple Watch, AirPods, Vision Pro, and the Mac's move to Apple silicon all passed through his hands. He's not a finance guy or a marketer; his whole career has been about how the physical object works.

And here's the coincidence that's hard to ignore: his first keynote is the one where Apple, for the first time in its history, shows a foldable phone. A hinge, a 4.5mm folded body, a panel rated for 200,000 folds — that's exactly the kind of engineering problem Ternus grew up solving. If Apple timed the leadership handoff to land on the most "hardware" launch of the decade, the timing landed well.

The practical takeaway: expect hardware today, not services. I wouldn't bet on a big subscription or ad-platform announcement closing out the evening.

My bets: thirteen predictions with probabilities

This is the part the whole piece was written for. The probabilities are mine — not a betting line, not analyst consensus — based on how many leaks agree, how many independent supply-chain sources confirm a given spec, and Apple's long habit of surprising everyone specifically on names and prices.

Read it like this: 90%+ is essentially locked in — only a real surprise changes it. 60-80% is likely, but I wouldn't be shocked by the opposite. Below 50% and I'm leaning against it.

Prediction	Probability	Why
Foldable iPhone is shown today	95%	Confirmed across independent supply chains, and the "Surprise and shine" slogan is clearly about this. You don't build hype this size for a camera bump.
It's called iPhone Ultra	55%	The name that shows up most often in leaks, but naming is the one thing Apple keeps secret until the end. "Fold" was on the list too.
Foldable starts at $2000+	85%	Two OLED panels, a titanium hinge, a new frame. Leaks consistently land on $2000 for the base and $2500+ for higher storage.
Touch ID instead of Face ID on the foldable	75%	4.5mm folded simply doesn't leave room for a TrueDepth module. A side button is the only way out.
No telephoto on the foldable	70%	Thickness beats periscope optics. Leaks consistently show two cameras: wide and ultra-wide.
No standard iPhone 18 today	90%	Every major source confirms the affordable line is pushed to spring 2027. Apple is splitting the lineup across two seasons.
A20 Pro on a 2nm process across all three iPhones	90%	The 2nm jump is the year's biggest hardware story — no reason to split it by model.
iPhone 18 Pro prices go up at least $100	70%	Rumored at $1199/$1299. The new process is expensive, but Apple has held Pro pricing before, so a freeze isn't off the table.
Variable aperture on the Pro's main camera	65%	Long-rumored and fits the "pro" narrative, but a moving mechanical part in a thin body is easy to slip a year.
Apple Watch Series 12 gets a ceramic case option	70%	It's been in the lineup before and shows up in leaks, but Apple has delayed such variants to spring before.
AirPods 5 with a new H3 chip	65%	Follows the usual refresh cycle, and two versions (with/without ANC) is plausible. Easy to get overshadowed by the foldable though.
A smart home hub with a 7-inch display	35%	Delayed twice already, tied to a new Siri. I'm betting against a proper reveal sharing the stage with the foldable.
Something not in any leak at all	30%	Recent years' leaks cover almost everything. But a new CEO's first keynote is exactly the moment to keep one card up your sleeve.

If I had to compress it into one line: I'm nearly certain about the hardware and nearly unsure about names and prices. Specs leak months in advance because thousands of people on factory floors know them. Names and prices are known by maybe twenty people, and they don't talk.

The foldable iPhone: the night's biggest bet

For eight years the foldable phone market existed without Apple. Samsung shipped seven generations, Chinese makers got the crease nearly invisible, and Apple stayed silent. Today, apparently, the silence ends.

What the leaks say: a book-style fold like the Galaxy Z Fold, a ~5.5-inch outer display and ~7.8-inch inner one. 4.5mm unfolded, about 9mm folded. A 5400-5800 mAh battery, A20 Pro chip, 12GB of RAM. Two rear cameras, no telephoto. Two colors: silver-white and deep indigo. MagSafe included. Starting around $2000.

What interests me most isn't the thinness record — it's the Face ID compromise. If Apple really is going back to a fingerprint sensor in a button, this is the first flagship in eight years where biometrics take a step backward. A company that built half its interface — unlocking, Apple Pay, password autofill — around Face ID is accepting a different method because physics leaves no other option. For a company that usually delays a product rather than back off its own standard, that's a real concession.

And that's the real question behind the price. Selling a $2000 device with no telephoto and no Face ID is harder than it sounds. The pitch has to be the screen itself — email, a spreadsheet, and a messaging app side by side, real multitasking, unfolding in one motion. If Apple spends today's demo on real use cases instead of millimeters of thickness, the product could take off. If the whole story is a thinness record and hinge materials, it's a very expensive toy for enthusiasts.

iPhone 18 Pro: an evolution you'll pay more for

Next to the foldable, the regular Pro models look boring — and that seems deliberate. Design barely changes from the 17 Pro. What changes is what's inside: the A20 Pro on a 2nm process (roughly 18% faster, 30% more efficient), a variable aperture main camera with a Samsung three-layer stacked sensor, LTPO+ display, a bigger battery in the Pro Max (~5567 mAh), new colors (dark cherry, light blue, silver — no black, if the leaks hold), and a $100+ price bump landing around $1199/$1299.

The variable aperture is the most interesting bit. Every computational trick of recent years — portrait mode, night mode, background blur — has been software compensating for optics too small to fit in a phone. A mechanically variable aperture is a step in the other direction: not estimating a shot, but actually capturing it. For anyone who shoots seriously on a phone, that's a bigger deal than another megapixel bump.

What won't be shown today — and why that matters more

The most underrated story of this fall isn't what gets announced, it's what doesn't. There's likely no standard iPhone 18 today — the affordable models are moving to spring 2027.

That breaks a decade-plus ritual: September used to mean the entire lineup, base to Pro Max, all at once. Now the year splits in two. Expensive models in fall, mass-market ones in spring.

The logic makes sense. A fall keynote stops being six devices competing for attention — the expensive models get the whole stage and head into holiday sales without internal competition. The mass-market iPhone gets a quiet spring window all to itself with no news cycle competing for headlines.

For buyers, the downside is real: if you just want a good new iPhone without the "Pro" label, tonight doesn't concern you — wait until spring. And the price gap widens: the cheapest new iPhone now arrives six months after the most expensive one, and September's lineup starts at $1200-plus.

Watches, earbuds, and the home

Everything else tonight is background noise, and that's telling too.

Apple Watch Series 12 — no design change, new processor, a returning ceramic case option, and reportedly continuous heart-rate monitoring throughout the day. That last part is the genuinely interesting one: continuous measurement instead of spot checks is a meaningfully different quality of health data.

Apple Watch Ultra 4 — same processor, incremental improvements. An upgrade for first-gen Ultra owners.

AirPods 5 — H3 chip, better sound, lower latency, in ANC and non-ANC versions. Splitting into two versions is a way to occupy a lower price tier without touching the Pro line.

A smart home hub with a 7-inch square display, camera, and video calling is the shakiest bet of the night. It's tied to a new Siri, and Siri has been rocky for Apple the last couple of years. I'm betting it doesn't get a proper showing today.

Separately: iOS 27, iPadOS 27, macOS Golden Gate, watchOS 27, tvOS 27, and visionOS 27 are expected to release September 14. Preorders likely shift from the usual Friday to Saturday, September 12 — September 11 isn't a day Apple opens sales on. Retail availability is expected September 18.

What this means if you write iOS code

If you build for iOS, tonight leaves you work for the fall. A foldable screen isn't "just another size" — it's several new states your app has to handle honestly.

Two genuinely different screens in one device. 5.5 inches outside and 7.8 inside are different size classes entirely — compact phone outside, near-tablet inside. Anything laid out for a single fixed-width column will look stretched on the inner display. Adaptive size classes — the thing many teams have skipped for years because "iPhone is always compact" — suddenly matter.

Live transitions between states. Users will unfold the device mid-interaction. That's a runtime geometry change with state preservation: unfinished text input, scroll position, an open navigation screen. This is where anything that stores state in the view hierarchy instead of the model breaks.

Biometrics. If Touch ID really is back, any code or copy that hardcodes Face ID assumptions will show users something untrue. Check the biometry type on-device — never assume it.

App Store screenshots. A new form factor means a new set of storefront assets. Anyone shipping an app will need another screenshot pass by spring.

The good news: almost all of this is fixed by doing what was already considered best practice — not nailing your layout to fixed sizes, and keeping state separate from the view. The bad news: far fewer apps do this cleanly than people like to think.

What I'd bet on myself

If I had exactly one bet for tonight, I wouldn't put it on the foldable — that's nearly a lock already. I'd bet that the real drama turns out to be pricing, not hardware.

Almost everything about tonight's devices is already known technically. What's not known is how much Apple will actually charge for the first foldable, and whether it will simultaneously raise Pro prices. $2000 for the foldable plus $100 on top of Pro would make this the most expensive September in the company's history — and it'll be announced by someone who's run Apple for nine days.

That's what to watch for at 8pm: not the millimeters of the hinge, but the pricing slide, and how confidently it gets delivered.

All figures above are rumors and leaks as of the morning of September 9, 2026, and the probabilities are my own personal estimate, not analyst consensus. I'll come back to this piece after the keynote and count how many bets landed.

Originally published at klukyanov.ru.

The Local LLM Weight Classes, September 2026: What Actually Fits on Your Machine

Kirill Lukyanov — Sun, 06 Sep 2026 07:17:55 +0000

A $20,000 Mac Studio buys you the same number of tokens as $20,000 of cloud API credit. The difference is that the cloud hands them over on demand, and the Mac needs fourteen years of uninterrupted generation to produce them.

That number is the reason I stopped sorting open-weight models by benchmark score and started sorting them by what physically fits. Here is the September 2026 snapshot — with a date stamped on it, because half of these figures will be stale by December.

The map changed, and it moved east

By May 2026, Chinese models accounted for roughly 61% of all tokens routed through OpenRouter. That share grew on a market that quadrupled in the same period — the router went from about 5 trillion tokens a week in April 2025 to more than 20 trillion by April 2026.

On Hugging Face the picture is starker. Qwen crossed one billion cumulative downloads and passed Llama. There are over 200,000 Qwen-tagged models on the hub, and roughly 40% of every new LLM derivative created there is built on a Qwen base.

Vendor	Share of routed tokens
Xiaomi (MiMo)	~21%
DeepSeek	~17.6%
Anthropic	~15.4%
Google	~13% (down from 37%)
Meta	<1%

Meta invented open weights as a competitive strategy in 2023. In September 2026 its routing share is under one percent. More on that below.

The ranking, for context

Current aggregate standing of open-weight models (BenchLM, September 2026):

#	Model	Vendor	Index	Context
1	Qwen3.8 Max	Alibaba	72.4	1M
2	GLM-5.3	Z.ai	68.5	1M
3	Qwen3.8-27B	Alibaba	68.4	262K
4	GLM-5.2	Z.ai	68.2	1M
5	GLM-5.3-Flash	Z.ai	66.1	1M
8	Kimi K2.7 Code	Moonshot	65.4	256K
13	MiniMax M3	MiniMax	63.9	1M

Look at row three. Qwen3.8-27B is a dense 27-billion-parameter model under Apache 2.0, and it sits four index points behind the leader. The leader is a 2.4-trillion-parameter network you cannot run anywhere except a server rack. Third place fits inside a single gaming GPU.

That collapse — from "the good models are unreachable" to "four index points" — is the actual story of the year.

Weight class 1: laptop, 8–16 GB

Model	Weights (Q4)	Fits in	Good for
Phi-4-mini	~3.5 GB	8 GB, CPU-only	logic, math, weak machines
Gemma 4 E4B	~6 GB	16 GB (~12.5 GB with full 128K context)	best generalist at 16 GB
Qwen3 8B	~6 GB	16 GB comfortably	chat, document work
Qwen3 14B	~9 GB	12–16 GB VRAM	code, refactoring

The trap everyone falls into: model weight is not total memory use. Gemma 4 E4B at full 128K context roughly doubles its footprint, from ~6 GB to ~12.5 GB. If your math says "just barely fits," it doesn't — the KV cache grows with the conversation and you will hit the wall mid-task.

Weight class 2: workstation, 24–64 GB

This is where the interesting thing happens.

Qwen3.8-27B in Q4_K_M needs 16.5–19.5 GB of weights plus about 1.5 GB of runtime overhead. That fits entirely inside an RTX 3090 or 4090 — cards that are plentiful on the used market. Native vision-language, 262K context, Apache 2.0 with no conditions attached. The base repo pulled 415,000 downloads within days of the August 14 release.

On Apple Silicon, a 64 GB Mac mini M4 runs it at roughly 7 tokens/sec. Not fast, but usable for non-interactive work.

Also in this class: Qwen3-Coder-Next 80B-A3B (sparse MoE, 3B active — the most realistic self-hosted coding model in the current lineup) and gpt-oss-120b at ~65 GB in MXFP4.

If you buy one machine for local inference, buy for this class. 32 GB is the floor, 48 GB is the working sweet spot, 64 GB is where you stop negotiating with your own context-length settings.

Weight class 3: one big machine, 96–512 GB unified

Sparse MoE models need enormous memory but only read a fraction of it per token. That maps almost perfectly onto Apple Silicon: a huge memory pool with bandwidth that is modest by datacenter standards but irrelevant when your bottleneck is capacity.

Apple refreshed the Mac Studio on August 25: M5 Ultra, up to 36 CPU cores, 80 GPU cores, and up to 512 GB of unified memory (the 512 GB configuration ships in late October). The 96 GB base is $5,499; the 256 GB upgrade adds another $4,000.

Model	Size	Speed	Memory
DeepSeek V4 Flash (284B-A13B)	2-bit	~39 tok/s	128 GB (M5 Max)
gpt-oss-120b	~65 GB MXFP4	~43 tok/s	96 GB+
Llama 3.3 70B	~42 GB Q4	~14 tok/s	96 GB
Llama 4 Maverick 400B	~220 GB Q4	~12 tok/s	512 GB

Most of those figures are engine estimates — the machines have only just started shipping. The DeepSeek V4 Flash number is the exception: 39 tok/s on a 128 GB M5 Max is community-reported from real hardware. For a 284-billion-parameter model sitting on a desk, that is genuinely good.

Weight class 4: rack only

Kimi K3 from Moonshot AI: 2.8 trillion parameters, 896 experts with 16 activated per token, 1M context, weights published July 27, 2026. Formally, download and run. Practically:

MXFP4 weights are 1.56 TB — no single GPU and no single 8-GPU node holds them
realistic serving is a multi-node cluster with 1.6 TB+ of aggregate GPU memory; production recommendations run to 64+ accelerators
the floor for FP8 on 80 GB H100-class cards is about 40 GPUs, roughly five nodes
at $2–4 per GPU-hour, an always-on 40-GPU deployment runs $60,000–115,000 per month in compute alone, before networking, storage, staff, and power

Alongside it sit Qwen3.8-Max (2.4T total, 95B active; text weights opened August 12) and GLM-5.3 (753B total, 40B active; released August 14 — same base as GLM-5.2 with scaled-up post-training).

The sparsity trap. Kimi K3 activates 104B of 2.8T parameters per token. It is tempting to size your memory for 104B. Don't: the router can call any of the 896 experts at any moment, so the entire model must be resident. Sparsity saves compute, not memory.

What the same models cost in the cloud

Model	Provider	In / out per 1M tokens
GLM-5.3	AkashML	$1.17 / $3.96
GLM-5.3	Together	$1.40 / $4.40 (149 tok/s)
GLM-5.3	GMICloud	$1.40 / $4.40 (29 tok/s)
GLM-5.3	Venice	$1.75 / $5.50
Kimi K3	Makora	$2.55 / $12.75
Kimi K3	Together	$3.00 / $15.00
Kimi K3	Morph (Fast)	$6.00 / $22.50
Qwen3.8-Max	DeepInfra	$2.00 / $6.00
Qwen3.8-Max	Together	$2.50 / $6.25
DeepSeek V4 Pro	DigitalOcean	$0.87 / —
DeepSeek V4 Pro	Azure (US)	$1.91 / —
DeepSeek V4 Flash	DigitalOcean	$0.068 / —
DeepSeek V4 Flash	Cloudflare	$0.44 / —

Three things in that table cost real money.

Identical weights, wildly different prices. Kimi K3 spans 2.35× between cheapest and most expensive host. DeepSeek V4 Flash spans 6.5×. Same model, different hardware and margin.

Identical price, different service. Together and GMICloud both sell GLM-5.3 at $1.40/$4.40. Together delivers 149 tok/s; GMICloud delivers 29. That is 5.1× slower for the same money — the difference between "works" and "unusable" in anything interactive.

Advertised context ≠ served context. GLM-5.3 markets a 1,048,576-token window. IO Net and Reka serve it at 262,144 — a quarter. DeepInfra serves Qwen3.8-Max only in its native 262,144 window while Together offers the full 1,010,000. And DeepInfra caps DeepSeek V4 Pro output at 16,384 tokens against an advertised 384,000 — 4.3% of the marketing number. Verify the endpoint before you architect around long context.

The break-even math

A 512 GB M5 Ultra Mac Studio runs about $20,000 (one top configuration is orderable today at $18,299). Call its throughput 10–15 tok/s on a large MoE model.

GLM-5.3 costs $4.40 per million output tokens in the cloud. So $20,000 buys 4.5 billion output tokens.

At 10 tok/s running 24/7 with no idle time, the machine produces 864,000 tokens per day. To generate 4.5 billion it needs more than fourteen years. Push it to 40 tok/s and you still need three and a half years of continuous, never-idle generation.

General break-even estimates converge on 2–3 million tokens per day over a twelve-month horizon. That is a small company's sustained pipeline, not one engineer's usage.

The rule that follows: if you are calculating savings, don't buy. If you are calculating risk — data that cannot leave your perimeter, work without connectivity, the fear that the model your product depends on changes its behavior or price next quarter — buy, and stop running the spreadsheet.

Five stories from this year

The one-bit trillion-parameter model

Kimi K3 is 1.56 TB natively. Community dynamic GGUF quantizations got almost comical: the 1-bit build occupies 594 GB and retains 78.9% of quality, the 2-bit build (861 GB) reaches 90.4%, and the smallest (TQ1_0) is 509 GB. A 2.8-trillion-parameter model compressed roughly threefold and still working at four-fifths strength.

Except 509 GB is still a $20,000 machine, to run 79% of a model you can rent for $2.55 per million input tokens. Pure sport — and admirable as such.

Meta invented the strategy and lost it

Meta released Llama 5 on June 30 — 600B parameters, 5M context, genuinely competitive at the top for the first time in a while. But three months earlier, on April 8, it shipped Muse Spark, a closed model, and that is the flagship.

The lesson isn't about Meta. It's that openness stopped being anyone's strategy and became a property of the market: it is now sustained by whoever needs share, not by whoever believes in it.

"Open" covers three different legal regimes

Apache 2.0 — Qwen3.8-27B. Do anything, including commercial. No conditions.
MIT — DeepSeek V4 checkpoints. Same freedom.
Conditional — the Qwen3.8-Max License and Kimi K3's custom license carry conditions for large MaaS operators and commercial products. Read them before signing a customer contract, not after.

And universally: open weights are not open source. None of these vendors ship training data or the training recipe. You get an artifact you can run and fine-tune, not one you can reproduce.

An open model beat a closed one on a public benchmark

GLM-5.2 scored 62.1% on SWE-bench Pro against GPT-5.5's 58.6%. Not "nearly caught up" — ahead. With two caveats that matter more than the number.

Public benchmarks leak. Contamination, metric overfitting, and harness effects are all real, which is why everyone reports SWE-bench Verified (500 hand-curated tasks confirmed solvable with correct tests) and LiveCodeBench (contamination-resistant) in 2026.

And if the benchmark's harness, timeouts, repo size, and review process don't match yours, the score is a signal, not a decision. Your own eval on your own tasks remains the only ground truth.

The bottleneck turned out to be memory, not compute

The usual assumption is that compute is the constraint. In 2026 it's HBM: Chinese domestic output is capped around 250,000–300,000 high-end packages for the year. Logic manufacturing was solved; memory wasn't.

The same pattern shows up at consumer scale. What's interesting about a 512 GB Mac Studio isn't speed, it's capacity — which is exactly why MoE models landed on it so well.

And one prediction that aged badly: after DeepSeek-R1 shipped in January 2025, Nvidia dropped 17% and lost roughly $600B in market value, on the thesis that cheap models would crater compute demand. By September 2026 Nvidia is worth $5.14 trillion, up 50% year over year. Cheap tokens didn't reduce demand — they multiplied it.

Bonus: prices went up for the first time. DeepSeek raised V4 Flash from $0.14/$0.28 to $0.44/$1.32 at peak (half that off-peak). If your unit economics assume today's price, assume it can triple.

What I would pick

Laptop: Qwen3 8B or Gemma 4 E4B. Private document work, offline, anything that cannot leave the machine.
One workstation: Qwen3.8-27B in Q4_K_M. If you want a single local model for everything, this is it — Apache 2.0, multimodal, third in the world ranking.
Code and agents: GLM-5.3 via API. Best open coding results, sane price, decent throughput on Together.
High volume, low cost: DeepSeek V4 Flash. Its structural edge is cache pricing — if your pipeline re-reads the same context (RAG, an agent with a fixed system prompt) it wins by a wide margin.
Maximum quality: Qwen3.8-Max via cloud. Locally, forget it — that's a rack.

One rule on top of all of it: don't pick a model against a benchmark, pick it against a constraint. Answer honestly which binds harder — gigabytes, dollars, latency, or the requirement that data never leaves your perimeter. The model then chooses itself, and it usually isn't the one on the top line.

Open weights stopped being a compromise. They became inventory: a warehouse where everything is free, and the only question is what you can physically carry out.

All figures as of September 6, 2026. Sources: BenchLM open-weight ranking, the Digital Applied provider census for pricing and served context, Data Gravity for market share, Apple Newsroom for Mac Studio specs.

Originally published at klukyanov.ru.

Renting GPUs for Crypto: I Did the Math on Self-Hosting GLM-5.2

Kirill Lukyanov — Sat, 05 Sep 2026 12:35:00 +0000

The same GPU node, running the same model, will quote you a token price that varies by a factor of 350. What decides it is not the rental rate.

I went through both sides of the crypto GPU rental market — renting your card out, and renting someone else's to host an open model — and carried the arithmetic all the way to dollars per million tokens. The workload is GLM-5.2: open weights, 753B parameters, released June 2026. Exactly the case decentralized GPU networks exist for.

All prices are as of September 2026.

Side one: renting your card out

A verified RTX 4090 on Vast.ai grosses about $6/day. That looks great — $180/month from a card that would otherwise gather dust.

Then the deductions start. The card draws 450W, which is 10.8 kWh/day around the clock:

Electricity rate	Per day	Gross minus power
$0.06/kWh	$0.65	$5.35/day
$0.08/kWh (Texas, Midwest)	$0.86	$5.14/day
$0.15/kWh	$1.62	$4.38/day
$0.30/kWh (Germany, UK)	$3.24	$2.76/day

Still respectable — but only because that table quietly assumes 100% utilization. It doesn't work that way.

Published reviews converge on a different figure: about $52/month net, after electricity, depreciation and platform fees, at typical load. Work that backwards and real utilization is around 40%, not 100. Two thirds of the time the card sits waiting for a tenant while continuing to age in your apartment.

The demand side is the actual risk here. In Q1 2026 Akash averaged 334 GPUs on the network with 84 actually working, and available capacity contracted by more than 57% quarter over quarter.

Payback: an RTX 4090 costs roughly $1,800. At $52/month net it pays for itself in 35 months — longer than the card survives in sellable condition under round-the-clock load.

So renting your GPU out is not passive income. It is converting depreciation into cash. The card loses value either way; the only question is whether it does so silently or hands you fifty dollars a month on the way down. Buying hardware specifically to rent it out is close to guaranteed loss. Renting out hardware you already own, on a 6–8 cent tariff, is reasonable.

Side two: renting someone else's to host GLM-5.2

GLM-5.2 is a 753B-parameter Mixture-of-Experts model, ~40B active per token, 78 layers, native 1M-token context. Open weights — that's the whole point of the exercise.

"Open weights" does not mean "fits anywhere":

Precision	VRAM needed	What that means
FP16/BF16	1,488–1,642 GB	two 8-GPU nodes minimum
FP8	~744 GB	8×H200 (1,128 GB) — production config
INT4 / Q4	372–411 GB	8×H100 80GB (640 GB) with KV headroom
2-bit dynamic	239–241 GB	quality tradeoff, experiments only

Renting a whole node:

Configuration	Per hour	Per month 24/7
8×H200, conventional cloud	$26.48	$19,330
8×H100 PCIe, conventional cloud	$23.12	$16,878
8×H100 on Akash ($2.09/card)	$16.72	$12,206
8×H100 at spot ($1.49/card)	$11.92	$8,702

The savings are real, and worth stating plainly: decentralized networks genuinely run 55–70% below the hyperscalers. The same H100 that Azure charges $6.98/hr for on-demand goes for $1.47–1.49 at io.net and Vast.ai. Akash lists H100 PCIe at $2.09, SXM5 at $2.69.

Case closed, seemingly. Except we haven't reached the token yet.

Token price: where it all flips

The hourly rate tells you nothing about the cost of work. Only one thing matters: how many tokens the node emits per hour.

For speed I use vLLM's benchmarks: a DeepSeek-class MoE (671B total, 37B active — nearly GLM-5.2's twin in shape) sustains 2.2k tokens/second per H200 in a production-like deployment. That's the best published result, after kernel work and Dual Batch Overlap; a year earlier it was around 1.5k.

Here's the caveat that headlines drop: that is aggregate throughput under high concurrency, not one user's response speed. vLLM publishes no per-user metric in that post.

Regime	Tokens/s	8×H200	8×H100 Akash
Node fully saturated	17,600	$0.42 / M	$0.26 / M
Single user, batch 1–2	~50	$147 / M	$93 / M

For comparison, Z.ai's official API for the same model: $1.40 per million input tokens, $0.26 cached input, $4.40 per million output.

So a saturated node delivers tokens 10× cheaper than the API — that's where the triumphant headlines come from, and they aren't lying. The same node under a single developer delivers tokens 15–33× more expensive than the API. The gap between two rows of one table is 350×.

Break-even: how many agents it takes

Working back from $4.40 per million output tokens:

Configuration	Must sustain	Roughly
8×H200 ($26.48/hr)	1,672 tok/s	~33 continuous streams
8×H100 Akash ($16.72/hr)	1,056 tok/s	~21 continuous streams
8×H100 spot ($11.92/hr)	753 tok/s	~15 continuous streams

And that is around the clock, no weekends. A node you shut down at night loses two thirds of its output.

Apply that to a solo developer. Even with heavy agentic work you land near 5M output tokens and a few hundred million input tokens a month. On the API with caching: about $82/month. Your own node on Akash for the same month: $12,206.

That's roughly 150×. No DePIN discount closes a gap like that, because the gap isn't about discounts.

The circle closes

Rent out an RTX 4090: $52/month net at realistic load.
Rent a 8×H100 node for GLM-5.2: $12,206/month at Akash pricing.
To fund one rented node you would need to rent out 235 RTX 4090s — about $420,000 of hardware, in your apartment.

The market looks symmetric: supply on one side, demand on the other, a token in between. In practice the two sides are three orders of magnitude apart.

What crypto actually changes here

What it genuinely gives you. Access to hardware with no contract, no legal entity, no KYC. Per-minute billing with no quarterly prepayment. A supplier stake instead of a reputation system — those 200 IO per chip that burn on misbehavior. Geographic spread that three hyperscalers don't offer.

What it doesn't. No SLA. No guarantee the 8×H200 you need is free at the moment you need it — remember Akash's 84 working GPUs and −57% capacity in a quarter. And critically, no fast interconnect. That 2.2k tokens/s per card was measured on an InfiniBand cluster. Sharding an MoE model across heterogeneous machines over ordinary internet is not remotely the same regime — and multi-node serving is the one scenario where self-hosting beats the API at all.

The uncomfortable part: the DePIN discount does not come from the token. It comes from the hardware being someone else's, already depreciated, sitting in a cheap electrical socket. Vast.ai delivers exactly that with no blockchain at all — and in these tables its $1.49 spot H100 came in below Akash's $2.09. The token is a settlement and collateral mechanism, not a source of savings.

What to actually do

You're solo or a small team. Use the API. $82/month versus $12,000 is not a case that rewards optimization. Self-hosting is justified by exactly one argument here, and it isn't economic: data that must not leave your perimeter.

You run 20–35 agents around the clock. Now the math is worth doing seriously, and DePIN pricing genuinely moves break-even down — from 33 streams to 21. Verify two things before committing: actual availability of the configuration at that moment, and the interconnect between nodes. Without InfiniBand or equivalent, the economics you came for fall apart.

You have idle hardware and a cheap socket. Rent it out. Just model 40% utilization rather than 100%, and treat the result as recovered depreciation, not income.

If you need privacy specifically. A Mac Studio M3 Ultra with 512 GB of unified memory ($10–15k) runs GLM-5.2 at 6.5–9.5 tokens/second. That's indecently slow, but it is the only way to hold a model this size in one box, with no rentals and no one else's data center. Workable for background processing under NDA; not for interactive work.

The takeaway

Decentralized GPU networks are neither a bubble nor a revolution. They're a working, fairly narrow tool with an honest 55–70% discount to hyperscalers and equally honest problems: unstable capacity, no SLA, slow interconnect.

But the main conclusion of this arithmetic isn't about crypto at all. It's that inference cost is determined by utilization, not by hardware price. Until that lands, any "rent vs API" comparison returns a random answer — you can demonstrate a 10× saving and a 30× overspend from the same price list with equal honesty.

A cheap GPU doesn't make a token cheap. What makes a token cheap is a queue of work for that GPU — and you still have to get the queue from somewhere.

Originally published at klukyanov.ru.

The Battery-Free Wi-Fi Button: How Backscatter Radio Actually Works

Kirill Lukyanov — Tue, 01 Sep 2026 19:04:48 +0000

A light switch with no battery, no wires, and no conventional electronics inside — just plastic, a gear, and Wi-Fi. It sounds like a pitch deck slide. It isn't.

The technology is called backscatter, it's twelve years old, it has measured numbers and shipping silicon, and this month the IEEE working group standardizing it puts its first draft to a vote. Here's how a device transmits data without having a transmitter — and the one detail that almost every popular explanation of this gets wrong.

Why ordinary Wi-Fi needs a battery

Start with a question that sounds trivial: why is Wi-Fi so power-hungry in the first place?

Moore's law has squeezed digital logic to absurdity. A microcontroller that counts button presses draws nanoamps and costs pennies. But a radio is not just digital. To get on the air, a device needs an analog chain: a frequency synthesizer to generate the 2.4 GHz carrier, and a power amplifier to push the signal into the antenna.

Those two blocks do not scale with Moore's law. Analog RF has barely gotten cheaper in energy terms over the same decades that digital got millions of times cheaper. That's why transmitting over Wi-Fi from a sensor still costs hundreds of milliwatts — and that, not some inefficiency in the protocol, is what keeps Wi-Fi out of the world of tiny sensors. BLE and ZigBee are thriftier, but they hit the same wall: they need their own oscillator too.

Which leads to the obvious question: what if you didn't generate a carrier at all?

A mirror, not a flashlight

The analogy that explains backscatter best is a signal mirror.

To send a light signal at night you need a flashlight: power source, lamp, the whole apparatus. In daylight, a small mirror is enough. It produces zero photons of its own; it only redirects someone else's light. A heliograph works exactly this way — the sun does the shining, the operator only changes the angle. The energy cost of "transmitting" is whatever it takes to move your wrist.

Radio works the same way. The air around us is full of other people's waves. Every object reflects them. The only question is whether you can control how it reflects — and turn that into data.

You can. An antenna reflects an incident wave differently depending on what's connected to it: shorted or open, impedance-matched or not. Put a single transistor switch between the antenna and ground, toggle it, and the reflected wave becomes modulated. One means reflect, zero means absorb. This is how passive RFID tags in badges and anti-theft labels work; backscatter is their direct descendant that learned to speak Wi-Fi.

The key point: what toggles is a digital switch at baseband, not an analog oscillator at 2.4 GHz. Somebody else makes the carrier. You only pay for the switching — and that's microwatts instead of milliwatts.

Three generations in three years

The technology came out of Shyam Gollakota's and Joshua Smith's lab at the University of Washington, and its history is a fight for range and throughput.

2013 — Ambient Backscatter. First demonstration of the principle: two devices talk to each other by parasitizing TV tower signals. No power source of any kind. It worked, slowly and at arm's length.

2014 — Wi-Fi Backscatter. First time a battery-free device connected to ordinary Wi-Fi infrastructure. Conceptually a breakthrough; practically modest: hundreds of bits per second at 2–4 feet.

2016 — Passive Wi-Fi. This is where it broke open. Instead of riding a narrowband side channel on top of someone else's Wi-Fi signal, Bryce Kellogg, Vamsi Talla, Gollakota and Smith figured out how to generate full 802.11b packets by reflection — packets that any existing receiver decodes. Any router, laptop, phone. No modifications on the receiving side.

Measured on their fabricated IC:

Metric	Value
Power at 1 Mbps	14.5 µW
Power at 11 Mbps	59.2 µW
Range	30–100 feet, including through walls
vs. existing Wi-Fi chipsets	10,000× lower
vs. Bluetooth LE and ZigBee	1,000× lower

To feel the scale: 14.5 microwatts is a level you can harvest out of thin air. Not figuratively — literally: that's roughly what you can pull off an antenna collecting ambient RF, or off a tiny photovoltaic cell under indoor lighting. The battery becomes unnecessary not because it was stretched thin, but because the energy required is now less than what's lying around for free.

The work was named one of MIT Technology Review's 10 Breakthrough Technologies of 2016 and took best paper awards at NSDI and SIGCOMM.

The part popular explanations get wrong

Here's the detail worth going to the primary source for.

Nearly every popular write-up describes the setup like this: "the router constantly emits radio waves, and the object reflects them differently." Intuitive, tidy, and wrong for Passive Wi-Fi.

The real architecture splits in two. The passive device handles only the digital baseband: coding, modulation, toggling the switch. Everything expensive in energy terms — the frequency synthesizer and the amplifier — is moved off the device onto a separate, plugged-in unit. That unit doesn't transmit data. Its only job is to radiate a single-frequency tone, a flat unmodulated signal that nearby passive tags reflect.

So there are three participants, not two: a plugged-in tone source, the passive tag, and an ordinary receiver (router or phone) that ends up reading the packet. One source serves every tag in range, so the economics work — but nothing works without it. The router sitting on your shelf today does not emit that tone.

This isn't pedantry about wording. That requirement for a dedicated tone source is exactly what kept the technology in labs for twelve years: it demands special equipment pre-installed in the room. As long as that's true, the story is about warehouses and industrial sites, not a button in your bedroom.

And that is precisely what's changing now.

Where things stand in 2026

Three separate threads converged over the past year.

Silicon. Canada's HaiLa shipped the BSC2000, a Wi-Fi-compatible connectivity RFIC operating in the ~40 microwatt range. The company's engineers are targeting single-digit microwatts for the third generation. That's a part you can design into a product, not an FPGA on a lab bench.

Research. In August 2025, Privitera, Ballo, Ahmed, Grasso and Alioto published a transmitter with neither a battery nor its own oscillator: it extracts the frequency directly from the incident wave through second-order intermodulation of a two-tone signal. The same incoming wave does three jobs at once — energy harvesting, data transmission, and motion detection. Reported sensitivity down to −19 dBm, consumption below one microwatt.

Standardization. The important one. Since March 2024, IEEE 802.11 has had Task Group bp writing an amendment called Ambient Power (AMP) — communication for devices running on harvested energy. This is not a hobbyist effort: chair from Sanechips, vice chairs from Qualcomm and Infineon, secretary from Ericsson, technical editor from OPPO.

The group's official milestones:

Milestone	Date
D1.0 ready for WG letter ballot	Sep 2026
D2.0 WG LB recirculation	Mar 2027
Initial SA ballot (D4.0)	Jul 2027
Final 802.11 WG approval	Jan 2028
RevCom and SASB approval	May 2028

That first row is this month. And at the July plenary the group demonstrated a Wi-Fi device communicating with an ambient power tag powered solely by that device's own RF emissions — the missing piece, with the tone source built into the access point itself.

In parallel, the cellular world is doing the same thing: 3GPP Release 19 standardizes Ambient IoT, where a "device 1" is a tag with roughly 1 µW peak consumption, backscattering a carrier wave supplied externally. OOK and BPSK modulation, indoor inventory and command use cases.

When both major wireless ecosystems independently write backscatter into their standards, it stops being a lab curiosity.

About that gear

One detail from the original demo still looks strange against all of the above: the mechanics. A tooth touches a contact, the signal distorts; no contact, no change.

It's honest, and rather elegant. Since transmission reduces to toggling a switch, the source of those toggles can be anything that opens and closes a circuit. A chip is optional. A gear turned by a finger closes a contact in a specific rhythm, and an encoded sequence goes out over the air. Not "Morse code for Wi-Fi" as a metaphor — a literal mechanical encoder.

Which generalizes nicely: the mechanism becomes the sensor. Water flow spins an impeller, so water is flowing. Wind turns a vane, so there's wind. A lid rotates, so the jar was opened. No electronics in the measurement path at all, energy from motion, communication from reflection.

So why isn't it in your house yet

The honest answer: the problem isn't physics, it's infrastructure and economics.

The physics was solved a decade ago and has only improved since. But for a battery-free button to work in an ordinary apartment, the access point itself has to supply the tone — which means it has to be in the standard and in the firmware of routers people actually buy. That's what 802.11bp is for, and that's why the date in its plan is May 2028, not "already".

Plus the unglamorous open questions: collision handling when there are hundreds of tags in a room; interference in an already-crowded 2.4 GHz band; how much range degrades in a real apartment with concrete and furniture rather than a lab hallway.

But the trajectory is clear. In twelve years this went from hundreds of bits per second at arm's length to shipping silicon and a draft standard. If IEEE holds its schedule, the first devices carrying a Wi-Fi logo and no battery compartment show up around 2028–2029 — not a revolution in a day, but a very quiet replacement of billions of batteries with nothing.

Originally published at klukyanov.ru.

I embedded an MCP server inside my macOS app so agents could talk back

Kirill Lukyanov — Mon, 31 Aug 2026 17:51:25 +0000

My dictation app for macOS was one-way. I would speak a thought into it, it would clean up the text, add the role and project context, and drop a polished prompt into the clipboard. Then came the humiliating part of the loop: switch to the terminal, paste, hit Enter, and read the output in small type.

The asymmetry was obvious from day one. Outbound: voice. Inbound: a wall of text. The app could talk to a human but couldn't listen to an agent; the agent could do the work but had no way to say anything back except print it.

That loop is closed now. The app runs its own MCP server inside itself, and Claude Code or OpenCode connect to it like any other tool. I dictate a task and it lands in the agent's session on its own. The agent works, and along the way it can ask me something out loud and wait for a spoken answer — and when it's done, it reads the summary aloud. Hands on the coffee, eyes anywhere.

Why the server lives inside the app

The obvious first design is the other way around: let the app spawn claude as a child process, write to stdin, read stdout. That's how dozens of CLI wrappers work.

That path is closed for me. PromtsMaker ships on the Mac App Store, which means App Sandbox, where Process and NSTask are forbidden outright. A sandboxed app cannot launch someone else's binary, and there is no entitlement that buys you out of it.

So the initiative in the protocol is inverted. The app stands up a local HTTP server on 127.0.0.1 and speaks MCP. The agent connects to it like it would to any MCP server and asks, on its own: "got a task for me?" One line:

claude mcp add --transport http promtsmaker http://127.0.0.1:8765/mcp

The app probes ports upward from 8765 and takes the first free one. A Network.framework subtlety worth knowing: NWListener only reports a busy port asynchronously through stateUpdateHandler, so starting the server has to be async throws rather than a quick synchronous check.

To the user none of this is visible — they dictate and press a button. But in the protocol it's the agent that asks and the app that answers, and the entire design downstream grows out of that inversion.

Four tools, and that's it

The temptation was to ship twenty. I resisted: the fewer tools you expose, the more reliably a model picks the right one.

Tool	What it does
`wait_for_prompt`	Long-poll for the next dictated task. Hangs up to 300s (55 by default), then returns `timeout` and the agent calls again. This is the heart of the loop.
`say`	Speak a short line out loud mid-task: "starting", "tests are green". Always audible — there is no toggle, that's the entire point of the tool.
`ask_user`	Ask a question by voice and wait for a spoken answer, up to three minutes. The app starts dictation, transcribes, and hands the answer back as a string.
`report_result`	The outcome: a short `summary` (read aloud) plus optional `details` — the full text that stays on screen.

No "read file" or "run command" tools — the agent already has those, and the app has no business duplicating them. In this design the app isn't the agent's assistant. It's the agent's mouth and ears.

Long-polling instead of a "check" button

The most interesting mechanic in the module lives inside wait_for_prompt. When the agent calls it and the prompt queue is empty, no HTTP response is written: the call suspends on a CheckedContinuation that goes into a dictionary of waiters. The moment I press "Send to agent," the action reaches the store, the store pulls the right waiter out and resumes it — and the dictated text flies out through that very HTTP request still hanging open.

If nothing happens within 55 seconds, the waiter resolves with timeout, the connection closes, and the agent immediately calls again. Turning the bridge off needed explicit care: bridgeToggled(false) has to resume every pending waiter across every project at once, or flipping the switch leaves agent sessions hanging forever.

The same construct backs ask_user — except it resolves on my spoken answer, or on cancel.

Who trusts whom

A server inside your app is a hole exactly as big as you make it. What stands between it and the world:

Loopback only. The listener comes up with requiredInterfaceType = .loopback; the port is never exposed outward. Exactly one new entitlement was needed: com.apple.security.network.server.
Bearer token. On first enable, 32 bytes from SecRandomCopyBytes, base64url-encoded, stored in UserDefaults. Without the Authorization header the server returns 401 even for tools/list. Rotation is a button, with confirmation.
Origin check. An empty header (a plain HTTP client, which is what agents are) passes; a non-empty one must start with http://127.0.0.1 or localhost, otherwise 403. That's the MCP spec's requirement for local servers — protection against DNS rebinding, where a page in your browser tries to reach your local port.

The rule that isn't in the code

The first live version of the bridge was unbearable. The agent dutifully called say — and started reading the output of git diff out loud. All of it. A speech synthesizer cannot skim.

The fix isn't code. The instructions string the server returns from initialize spells out an explicit policy: keep anything spoken to one or two sentences — a longer text is faster to read than to sit through. If the result is bulky, keep summary to one line, put the full text in details, and only read the details after asking via ask_user: "the result is long — read it all out?"

The code neither checks nor truncates any of this. It relies on the agent following the system text — and the agent does. That's a genuinely odd shift in engineering practice: part of the system's behavior now lives in an English paragraph rather than in branches, and you debug it by rewriting sentences.

Several projects at once

The first version kept a single state for the whole app — and fell apart the moment I opened two project tabs with an agent session attached to each: the second session clobbered the first one's prompt, question and result.

The routing key became project_path, the agent's working directory — the same identifier the app already uses to tell its own tabs apart. All four tools take it as an optional argument, and the prompt queue, in-flight prompt, pending questions and last result all split into dictionaries under that key. The conversation feed stayed shared across projects; each message just carries the folder name as a label.

Onboarding through the agent's memory, not a project file

One awkward seam remained: the agent has to know the rules of the loop — live inside wait_for_prompt, always pass project_path, don't read walls of text aloud. The obvious solution is to have the user paste an instruction block into CLAUDE.md or AGENTS.md. That is, redo it by hand in every new project.

Instead, instructions asks the agent, on first connect, to save that note into its own persistent memory — the loop, the project_path requirement, the speech-length rule. The next session in the same project already knows the rules, nothing needs pasting, and the project's own files stay clean of clutter about a tool only one developer uses.

What broke during live acceptance

452 unit tests being green (about forty-five of them written specifically for the bridge: HTTP byte parsing, the JSON-RPC router, the reducer, side effects) guarantees nothing about a live run. Acceptance against a real Claude Code produced a plot twist you don't invent at a desk.

The very first ask_user on a fresh machine starts dictation — and runs straight into the macOS system alert "Allow access to speech recognition". While that alert sits there waiting for a human, the question's timeout is ticking. The agent, meanwhile, is patiently waiting for an answer that physically cannot arrive. It's a one-time story — the permission is granted once and forever — but on a clean machine your first encounter with the feature looks like "it doesn't work".

The bridge that finished writing itself

The best part is the one I didn't plan. The last round of work on this bridge was dictated through the bridge itself.

I was sitting there using the app, noticing rough edges, and saying them out loud: "the screen has grown, let me hide the panels I don't use" — and the agent built a settings window with four checkboxes. "The environment grid is truncating labels, move it to its own row" — and the agent reworked the layout. "I've got two tabs and two sessions and they're fighting" — and project_path routing appeared, the thing described above.

None of these were on a roadmap. All of them came out of live use, and every one reached the code by voice, without a single switch to the terminal. A tool that grows far enough to take part in its own development is a rare feeling, and in hindsight that's what the whole thing was for.

Where to try it

The bridge runs on my machine every day, but it isn't in the Mac App Store yet: the latest published version of PromtsMaker is 1.3, which shipped before this story. The bridge goes out in the next update, 1.4. I won't promise a date — Apple's review queue has been noticeably longer lately, and that part isn't up to me.

The app itself is free on the Mac App Store.

Originally published at klukyanov.ru.

Why Your Eyes Burn by Evening: Digital Eye Strain and the 20-20-20 Rule

Kirill Lukyanov — Mon, 24 Aug 2026 18:19:14 +0000

By the end of the day my eyes burn. The screen goes fuzzy for a second when I look up, focusing on something across the room takes longer than it should, and a dull headache creeps in around the temples. I used to write this off as "just tired." Turns out it has a name and a fairly simple mechanism behind it.

What computer vision syndrome actually is

Computer vision syndrome — digital eye strain, if you prefer the plainer name — isn't a diagnosis in the sense of "something broke." It's a cluster of symptoms that shows up after prolonged close-range screen work: dryness and burning, blurred focus when you shift your gaze to something far away, light sensitivity, headaches, and often neck and shoulder pain, because we unconsciously lean toward the screen and freeze in one position for hours.

Two things happen at once. First, your eyes hold focus on a near object for a long stretch — the ciliary muscle, which controls how the lens changes shape for near vision, stays tensed the whole time instead of periodically relaxing the way it would if your gaze wandered farther away now and then. Second, you blink noticeably less often while concentrating, so the tear film that keeps your eyes moist doesn't get replenished as frequently — hence the dryness.

Why a screen and not a book

Reading a book for hours also holds your focus at close range, but it strains your eyes less, and there's a reason for that. A screen emits light rather than reflecting it the way paper does, which creates more contrast against the room's ambient lighting, especially if the room is dimmer than the display. Glare from windows and lamps forces you to squint and refocus. And a laptop or phone tends to sit closer to your face than a book or a printed document would, simply because the screen is smaller.

There's also the nature of the work itself. Reading a book is a steady stream; working with software is a constant series of micro-refocuses between windows, tabs, and notifications. Your eyes keep re-adjusting, with almost no rest in between.

The 20-20-20 rule

Every 20 minutes of screen work, look at something roughly 20 feet (about 6 meters) away for 20 seconds.

The logic is simple: shifting your gaze to a distant object lets the ciliary muscle relax — it defaults to distance vision and only tenses up when focusing close. Twenty seconds is usually enough to release that tension without derailing your work for long. Ophthalmologists and optometrists like this rule specifically because it's so low-friction: no closing your eyes, no stepping away from the computer, no time cost — just look out a window or across the room.

What else actually helps

Blink rate. Blink frequency drops noticeably during focused work. Consciously blinking more often, especially while reading or typing, helps keep the tear film intact and prevents dryness.
Distance. Your monitor should sit an arm's length away, top edge at or slightly below eye level. A screen positioned too close keeps the ciliary muscle under constant tension.
Lighting. Screen brightness should roughly match the room's ambient light — not much brighter or dimmer, since either forces your eyes to keep readjusting. Glare from windows and lamps is worth eliminating before it becomes a problem, not after.
Text scale. If you're squinting to read something, that's extra strain you don't need. Bumping up the font size or interface scale is almost always cheaper than living with it.
Periodic vision checks. If you spend long hours at a screen, it's worth tracking your visual acuity and a few other basic metrics over time — not as a substitute for an actual eye doctor, but to catch a trend early and bring it up at your next appointment.

Why this is hard to keep up manually

Everything above sounds simple, and that's exactly the trap. The 20-20-20 rule only works if you actually follow it — and in the middle of a work session, 20 minutes disappears fast; you remember the break only after your eyes are already tired. Screen distance and room lighting are just as hard to self-monitor: you don't notice that you've drifted closer to the monitor over the last hour, and nobody's measuring lux with a light meter mid-sprint. And without a history of measurements, there's no way to tell whether the habits you're trying to keep are actually helping — there's simply nothing to compare against.

That gap — not "what to do" but "how to do it without constant self-monitoring" — is what pushed me to build an app instead of just setting a recurring alarm.

How I automated it in SafeYourEye

SafeYourEye is my macOS app, and it takes over exactly the manual parts from the list above:

Timer — the 20-20-20 rule with a configurable session length and idle detection, so the countdown doesn't keep running if you've stepped away from the computer.
Distance and light — the camera tracks how far you are from the screen and the room's ambient light level, and nudges you if you've sat too close or the room has gotten too dark.
Blink rate — a five-minute camera-based blink rate measurement, with a history across the day and a trend, not just a one-off number.
Self-check for vision — four checks on one screen: visual acuity via Landolt rings, contrast sensitivity, an astigmatism fan, and an Amsler grid, with a result history, trend, and PDF export to bring to an eye doctor. There's also a 90-second express mode.

All camera frame processing happens locally on the Mac through the system Vision framework — nothing is recorded or sent anywhere. The only things that leave the device are derived numbers, like a measurement timestamp and a blink-rate-per-minute figure.

What it is: a 20-20-20 timer with camera-based distance, light, and blink monitoring, plus a vision self-check.
Platform: macOS 13+, interface in Russian, English, German, and Chinese.
Privacy: all camera processing happens on-device; nothing leaves the Mac.
Where to get it: Mac App Store, $2.99.

Originally published at klukyanov.ru.