DEV Community: Kirill Lukyanov

Lunar Fasting: an intermittent fasting app that puts your Apple Health activity on the lunar calendar

Kirill Lukyanov — Sun, 04 Oct 2026 16:34:20 +0000

Intermittent fasting has one simple rule: eat inside a window, don't eat outside it. The rule is easy, keeping it is not. Some days the window holds effortlessly, other days you break by lunch and have no idea why. I wanted an app that doesn't just tick a timer but shows me, from my own data, which days are easier and which are harder.

That's how Lunar Fasting came about. It went live on the App Store on October 2, 2026: 157 days from the first commit, 28 builds, 656 automated tests and one App Review rejection. Below: how to pick a fasting interval, what the app does, and the two features it was really built for.

Fasting intervals: which one to pick

"16:8" means 16 hours without food and an 8-hour eating window. The longer the fast, the stricter the regime. The app supports six protocols:

Protocol	Fast	Eating window	In real life	Good for
12:12	12 h	12 h	Dinner at 8 pm, breakfast at 8 am — just no night snacks	Beginners
14:10	14 h	10 h	Dinner at 7 pm, breakfast at 9 am	A gentle next step
16:8	16 h	8 h	Eat from noon to 8 pm	The most popular one, the default
18:6	18 h	6 h	Eat from 1 pm to 7 pm, two meals	When 16:8 feels easy
20:4	20 h	4 h	Late lunch and early dinner in one short window	Experienced, for a while
OMAD	23 h	1 h	One meal a day	The strictest, only deliberately

The app is not a doctor: with diabetes, pregnancy, eating disorders or any chronic condition, talk to a doctor before you start.

My advice: start with 12:12 or 14:10 and move up when the current step stops taking effort. You can switch protocols any time, and past days won't be recolored — each day is judged against the goal that was active when it ended.

Fasting without a "start" button

Most fasting trackers have a timer you start and stop by hand. Forget to tap it and the day is lost. Lunar Fasting doesn't store fasting windows at all: they are derived from logged meals. Log breakfast and dinner, and the app knows how long you went without food.

A few rules came out of this, each pinned by tests. A 2 am snack honestly breaks the fast instead of stretching it. If you forgot to log yesterday's dinner, you don't get a 40-hour "record" — you get "no data". Log a meal retroactively and the whole chain recalculates.

Why lunar days, not calendar dates

A lunar day runs from one moonrise to the next, about 24 h 50 min. There are roughly thirty of them in a lunar month. Most lunar calendars compute them with a mean formula and are off by up to half a day. Lunar Fasting computes moonrise astronomically for your location and uses true new moon instants (Meeus), not averages.

To be clear: I don't claim the Moon affects appetite or how much you move. Science hasn't shown that. The app doesn't promise — it checks, on your own data.

Calories from a photo

Snap your plate and a vision model splits it into items — side dish, cutlet, salad — each with its weight in grams. Add a text hint for ambiguous dishes ("buckwheat with mushrooms, no oil") and accuracy goes up noticeably.

One deliberate decision: the model never computes the total. It only returns item names, grams and kcal per 100 g; the app does the arithmetic. Small models are surprisingly bad at mental math, and this way every number is visible and editable.

Recognition runs either on-device via Apple Intelligence (no network, no key, the photo never leaves the phone) or through your own key for OpenAI, Gemini, Qwen or DeepSeek, stored in the Keychain and sent straight to the provider. "Auto" mode tries on-device first. Meals are written to Apple Health too.

The main feature: your activity on the lunar calendar

On first launch the app pulls a year of activity from Apple Health — steps, active energy, workouts and stand hours — and keeps it updated, re-syncing the last week each time because watch data arrives late.

Four numbers become one activity index from 0 to 100. Each metric is normalized to a daily target and capped, so overachieving doesn't inflate it:

Component	Daily target	Weight
Steps	10,000	35%
Active energy	500 kcal	30%
Workouts	1	20%
Stand hours	12	15%

Without an Apple Watch, workouts and stand hours are almost always zero and the index would cap at about 65. So in statistics the app drops components you have no data for and renormalizes the weights.

Calendar days and lunar days don't line up, so each lunar day gets a weighted value from the two calendar days it overlaps, proportional to time. The charts show your average index for each of the thirty lunar days and each moon phase — your own year of movement, not someone's theory.

A forecast for the lunar month

The forecast is an additive model, and the app shows each day's breakdown:

Baseline — your mean index with a 45-day half-life, so recent weeks weigh more.
Weekday effect — 7 and 29.5 are incommensurable; without this axis, the weekly rhythm would leak into a fake lunar signal.
Recent trend — the last two weeks vs. baseline, decaying over the horizon.
Moon phase and lunar day number — hierarchical, and only if your history actually shows it.

The last part matters most: lunar effects go through empirical-Bayes shrinkage. With few observations they shrink to zero, so with no lunar pattern in your data the forecast honestly falls back to baseline, weekday and trend. There's an uncertainty band that widens with the horizon and a confidence level: the forecast appears after 21 days of history, medium confidence from 60 days, high from 180. With 60+ days the app also backtests itself: it hides the last two weeks, predicts them and compares the error with a naive "same as average" forecast.

Coming in 1.1: Google Health

If you wear a Google or Fitbit band with an iPhone, its data reaches Apple Health poorly: workouts go missing, calories and heart rate disagree, steps double. Lunar Fasting 1.1 adds a direct bridge: sign in with Google, and the app pulls workouts, steps, distance, active energy and heart rate from the Google Health API and writes them to Apple Health — deduplicated via HKMetadataKeySyncIdentifier, with Google's echo of Apple Health data filtered out. Band activity then feeds the index and forecast just like Apple Watch data.

One caveat: Google requires OAuth verification and a security audit for health scopes. Until then the feature runs in testing mode, capped at 100 users, so 1.1 ships it to a limited group first.

Free vs. Pro

Free: six fasting protocols, meals and manual calories, water, weight, daily ratings, lunar calendar, stats for steps, water, weight and calories, CSV export. No account, no server.
Pro: activity index, monthly forecast, calories from a photo. Weekly or yearly subscription with a 3-day free trial.

iPhone and iPad, iOS 17+, English and Russian. Get it on the App Store.

Would you trust a forecast that openly tells you when it has nothing to say?

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

Kimi K3, DeepSeek and GLM free from NVIDIA: I tested the claim and here is the catch

Kirill Lukyanov — Thu, 01 Oct 2026 09:42:31 +0000

A claim is going around: NVIDIA hands out a free API key for Kimi K3, DeepSeek V4.1 Flash and two flavours of GLM 5.3 — no credit card, fifteen minutes. I went through it myself. The models are real, the free tier is more generous than the reposts say, and there is one catch the headline leaves out: a phone number check that does not cover every country.

What NVIDIA gives away

NVIDIA Build is NVIDIA's catalog of hosted open models. The API is OpenAI-compatible: same /v1/chat/completions request, you only swap the base URL and the key. As of October 1, 2026, integrate.api.nvidia.com/v1/models lists 81 models, including the four most interesting open-weight releases of this autumn.

The part most reposts get wrong is the money. New accounts used to get roughly 1,000 credits, and people still quote that number. Credits are gone. NVIDIA's own account verification dialog now says "Unlimited API requests without daily limits". What is limited is the rate: threads on the NVIDIA developer forum converge on about 40 requests per minute per key, and a forum moderator stated in July that the limit depends on the model, use case and overall traffic and cannot be officially raised on the free tier.

40 RPM is 57,600 requests a day if you hammer it nonstop. For prototyping, a personal agent or evaluating a model on your own tasks, that is effectively unlimited. For production, NVIDIA points you to paid options: partner endpoints or self-hosted deployment.

The four models

All four are mixture-of-experts models, and all four ship with a 1,048,576-token context window.

Model	API ID	Total params	Active per token	Highlights	License
Kimi K3	`moonshotai/kimi-k3`	~2.8T	not stated	Long-horizon agentic coding, tool use, image input; thinking always on	Modified MIT
GLM 5.3	`z-ai/glm-5.3`	753B	~40B	Text, reasoning, tool calling	MIT with a clause for >$10B-revenue resellers
GLM 5.3 Flash	`z-ai/glm-5.3-flash`	320B	18B	Text + images, tools, structured output, thinking budget	MIT
DeepSeek V4.1 Flash	`deepseek-ai/deepseek-v4.1-flash`	552B	8B prefill / 16B decode	Multimodal, reasoning effort adjustable 1–100	MIT

Source: model cards on build.nvidia.com.

For coding I would start with Kimi K3 — it is the reason for the hype, and running it yourself takes a rack you do not have. Free access on someone else's GPUs is the only sensible way for most of us to try it. GLM 5.3 Flash and DeepSeek V4.1 Flash are for fast, cheap calls where you do not need the smartest answer.

The catch: phone verification

Sign-up itself is smooth: email, password, NVIDIA Developer Program account. No card, as promised. But on the API keys page you get a modal — "We'll need to verify your phone number" — and no key until you enter a one-time SMS code. NVIDIA frames it as fraud and abuse protection.

The country list is not global. Russia is not on it at all; under the list NVIDIA says it is "rapidly expanding worldwide availability". Kazakhstan is listed, but in my attempt with a Kazakh number the "Send Code to Phone" button never became active, and the page showed no error. I could not confirm whether Kazakh numbers go through.

I did not try to get around the check and would not recommend it: virtual numbers and borrowed SIMs violate the terms, and a key obtained that way can be revoked along with the account. So "fifteen minutes, no card" is true only if your phone number is from a supported country.

First request

If your number is supported, the first call takes a minute. Any client that lets you change the base URL works, including coding agents.

export NVIDIA_API_KEY="nvapi-..."

curl https://integrate.api.nvidia.com/v1/chat/completions \
  -H "Authorization: Bearer $NVIDIA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/kimi-k3",
    "messages": [{"role": "user", "content": "Explain Swift async/await in three sentences"}],
    "max_tokens": 1024
  }'

Swap model for any ID from the table. One Kimi K3 detail: thinking is always on, and in multi-turn chats or tool calls you must send back the full previous assistant message, including reasoning_content and tool_calls, or it loses the thread.

My take

The offer itself is great: four of the strongest open models of the season, no payment, no daily cap, standard API. If your phone number qualifies, it is the easiest way to try Kimi K3 without renting hardware. Just know that "no card, fifteen minutes" quietly skips the phone step — and that step is where some of us stop.

Originally published at klukyanov.ru.
Shorter weekly write-ups (in Russian) — on Telegram.

Listen to your coding agent instead of reading it: how I save my eyes

Kirill Lukyanov — Tue, 29 Sep 2026 18:42:49 +0000

My working day at the computer used to be code and documentation. Now there's a third stream, and it turned out to be the biggest one: the agent's replies. Claude Code reports every step, explains what it changed, asks clarifying questions and sends summaries. All of it is text, and all of it is read with your eyes, in small terminal font.

By evening you feel it physically. So I put together a pair of my own macOS apps. The first one, SafeYourEye, makes sure my eyes actually get rest. The second one, PromtsMaker, takes part of the load off them: the agent talks to me by voice, and I answer by voice too. Here's how it works for me and how to set it up in ten minutes.

The agent writes more than I can read

With an agent your eyes don't get a break, they work harder. It writes the code, but I read its reports, check diffs and answer questions. Instead of typing text I read it, constantly, in small portions, switching between windows.

Yet most of what the agent writes doesn't need a screen. "Starting", "tests are green", "found two places where this is used, fix both?" can simply be heard. You need the screen for diffs and code; for status and questions, voice is enough.

Hence two fixes: don't let your eyes work without breaks, and move to audio everything that doesn't have to be read.

Half one: SafeYourEye keeps the breaks

Everyone knows the 20-20-20 rule: every 20 minutes, look at something about 20 feet away for 20 seconds. Almost nobody follows it, because 20 minutes fly by at work. Here's what the app does:

Timer. Counts a work session (5 to 60 minutes) and shows a break window with a 20-second countdown. A window is harder to dismiss than a banner.
Idle detection. Walk away from the computer and the session doesn't burn: time without keyboard and mouse isn't counted as work.
Distance and light. Using the camera, it hints when you sit too close to the screen or the room gets dark. Frames are processed on the Mac itself and never leave it.
Vision checks. Four self-checks on one screen, with history and a PDF export for your doctor. Not a diagnosis, a way to notice a trend.

With an agent the timer turned out to be especially useful. While the agent runs a long task I don't sit staring at the terminal, I take the break. The SafeYourEye window and the agent's summary often arrive at about the same time.

Half two: PromtsMaker gives the agent a voice

PromtsMaker started as a prompt editor: dictate a thought, the app cleans up the text and adds project context. You don't have to use prompts at all, though. Since version 1.4 the app has a bridge to the agent, and that alone is worth installing it for.

Inside PromtsMaker runs a local MCP server. Claude Code connects to it like to any other tool, and the agent gets a mouth and ears:

say — speak a short line during the work: "starting", "build passed";
ask_user — ask by voice and wait for a spoken answer: the app starts dictation itself and returns the transcript to the agent;
report_result — read the summary aloud, while details (diff, command output) stay as text in the panel;
wait_for_prompt — pick up a new task I dictated in PromtsMaker, without copying it into the terminal.

The agent has one rule: don't read walls of text. One or two sentences aloud; a long result only after "read it all?". Without that rule the first version of the bridge honestly read everything.

I run the bridge live with Claude Code and OpenCode. The protocol is standard, MCP over HTTP, so any agent that can connect MCP servers over HTTP should work. Codex CLI supports such servers, but I haven't tested it with the bridge myself yet.

What it looks like on an exercise bike

My favourite scenario. A long task: rewrite a module, run the tests, fix whatever breaks. No reason to watch it in the terminal.

Dictate the task into PromtsMaker as a normal sentence. The app strips the "umm"s and fixes terms using the project glossary. Sending it to the agent is ⌘⏎, no window switching.
Get on the bike. The screen is far away; I don't need to read it.
The agent works and talks. Short updates are spoken, and I know where it is without looking.
The agent asks, I answer by voice. At a fork it asks out loud, the app starts dictation, I say the answer, the agent continues.
The summary is spoken. If it's clear, I dictate the next task right away. I look at the diff later, in one pass, instead of in bits for an hour.

Double benefit: my eyes rest on the far distance instead of the terminal, and my body moves while the agent does work that needs only a couple of spoken answers from me.

Eyes or ears: what moved where

What's happening	Before	Now	Who helps
Give a task	Type or paste into the terminal	Dictate, ⌘⏎	PromtsMaker
Know which step the agent is on	Watch terminal output	A short spoken line	PromtsMaker, `say`
Answer a clarifying question	Read it, type an answer	Hear it, answer by voice	PromtsMaker, `ask_user`
Get the result	Read the whole report	Spoken summary, details as text	PromtsMaker, `report_result`
Review diff and code	Eyes	Eyes, in one pass at the end	—
While the agent works long	Sit at the screen and wait	Break or exercise bike	SafeYourEye
Don't overstay at the screen	Hope you remember	Break window every 20 minutes	SafeYourEye
Sat too close, room got dark	Don't notice	Camera hint	SafeYourEye

The code I always review with my eyes, and that's fine. Tool names are for the agent; users never need to know them.

How to set up the same pair

Both apps are for macOS and are in the Mac App Store. PromtsMaker is free (macOS 14+). SafeYourEye runs on macOS 13+, it's free to download, with full features in a Pro subscription ($2.99/month or $19.99/year).

Install SafeYourEye and set the session length. You can skip camera access: distance and blink hints turn off, the timer keeps working.
Install PromtsMaker and open your project folder in it.
Enable the agent bridge. The app starts the server on 127.0.0.1 only, generates an access token and shows a ready-made connect command.
Connect Claude Code with that command. It looks like this (the app picks the port, the token is added as an Authorization header):

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

Tell the agent "wait for tasks from PromtsMaker". On first connect it stores the bridge rules in its own memory; you don't need to add instructions to project files.
Allow speech recognition when macOS asks. Better do it right away: the agent's first voice question otherwise waits on the system prompt, and you can't answer until it's dismissed.

What's next: read any reply with one key

The bridge works when the agent decides to say something. But sometimes the session runs in a plain terminal, without the bridge, and you'd rather listen to the reply than read it. For that, the next PromtsMaker update adds a global hotkey: it reads the latest Claude Code reply for the project in the open tab, and pressing it again stops. The app strips Markdown first, so you don't hear asterisks and hashes.

It already works in my dev build and will ship in the next App Store version.

Originally published at klukyanov.ru.
Shorter weekly write-ups (in Russian) — on Telegram.

Fitbit Air and iPhone: why your band's data gets lost on the way to Apple Health

Kirill Lukyanov — Mon, 28 Sep 2026 09:30:09 +0000

I wear a Google Fitbit Air on my wrist and carry an iPhone. Sounds like a normal combo. In practice it's two health worlds that barely understand each other: the band counts steps, heart rate, sleep and workouts, the Google Health app shows all of it, but Apple Health — where every other iPhone app gets its data — receives only part of it, and not always in the right shape.

I ran into this as a developer: one of my apps builds activity analytics on top of Apple Health, and with the band's data the analytics started to lie. Here's what's actually broken, why it's hard to fix, what the paid bridges on the App Store cost, and how I built my own.

Two "Health" apps that refuse to be friends

Apple and Google store health data in fundamentally different ways. Apple Health (HealthKit) lives only on the phone: an encrypted on-device database with no cloud API. Google Health is the opposite — a cloud service: the band sends data to the phone, the phone sends it to your Google account, and that's where it lives.

To move data from one world to the other you need a program that runs on the iPhone, downloads data from Google's cloud and writes it into Apple's local store. Nobody else can do it: Google's cloud can't reach the database on your iPhone, and Apple only lets apps on the device itself write to it.

For years Google simply didn't ship such a program. When HealthKit launched in 2014, Fitbit said outright it had no plans to support it, and Fitbit owners with iPhones lived on third-party utilities for a decade. Only in August 2026, in version 5.05, did the Google Health app learn to write to Apple Health itself. Problem solved? Not quite.

What gets lost on the way

The official sync works, but with losses. On my own data:

Workouts go missing. Some workouts recorded by the band never show up in Apple Health, although they're in Google Health.
Calories and heart rate don't match between the two apps for the same day.
Duplicates. The same steps and calories land in Apple Health twice and inflate the daily total.
Some metrics don't transfer at all, e.g. heart rate variability (HRV) — even the coverage of the update admits it.

If you only glance at steps, that's cosmetic. But fitness apps, food diaries and training plans read Apple Health and draw conclusions from an incomplete, partly doubled picture.

Why it's hard to do right

Different data models. In HealthKit a workout is a single object with calories and distance inside. In Google's model it's a set of separate points: an exercise segment, per-minute calories, per-minute distance. Copy everything as-is and calories inside a workout are counted twice.
The echo. Google Health also reads Apple Health (iPhone steps, Apple Watch workouts), uploads them to Google's cloud, and they come back as "Google data". A bridge that can't tell its own records from the echo grows duplicates on every sync.
The locked phone. Apple Health's store is encrypted while the iPhone is locked, so nothing can be written. Background sync works in fits and starts, and long history imports die when the screen turns off.
Old paths are closing. Many cheap bands have been writing to Google Fit for years. Since May 1, 2024 new developers can't sign up for its APIs, and they shut down at the end of 2026. The replacement is the Google Health API, which has its own strings attached (see below).

Paid bridges on the App Store and what they cost

All of them are free to download and charge via in-app purchases. US App Store prices as of September 28, 2026:

App	Subscription	Lifetime	Rating
Fitbit Sync To Apple Health (Syncfit)	$4.99–9.99/mo, $19.99–39.99/yr	$59.99	4.6 (19,688)
Fitbit to Apple Health Sync (myFitnessSync)	$5.99–9.99/mo, $9.99/wk, $39.99/yr	$39.99–59.99	4.3 (29,189)
Power Sync for Fitbit	auto-sync $1.99/mo, $7.99/yr (daily totals only)	$14.99	4.2 (15,642)
Power Sync: Fitness to Health	$5.99/wk, $10.99/mo, $19.99–24.99/yr	—	4.5 (12,888)
Fitbit to Health Sync Solver	$9.99/wk, $39.99/yr	$59.99	4.5 (3,250)
Fitbit Sync to Health App	$9.99/wk, $19.99/mo, $39.99/yr	$59.99	4.1 (1,628)
Fitbit to Apple Health Sync · (StepsApp)	Pro: $4.99 or $19.99	—	4.3 (374)

The typical price is $39.99/year or $59.99 lifetime. The Fitbit Air costs about $100, so you're asked to pay almost half the band's price again just to get its data onto your iPhone properly. Weekly $9.99 plans add up to roughly $520 a year — five times the band.

One caveat matters more than price: nearly all of these are built around the Fitbit / Google Health account. If your band writes to the old Google Fit, a bridge may not see its data. Test on the free trial before paying for a year.

How I built my own bridge

I didn't want to pay for a bridge, but my app's analytics had to be fixed, so I wrote the sync myself: the app pulls data straight from the Google Health API and writes it into Apple Health. (Turn off Google's own sync in that case, so you don't have two sources of the same thing.) The core work took one day; the interesting part is the pitfalls.

API. Google Fit REST is closed to new developers, so it's the Google Health API v4 (dataTypes/{type}/dataPoints). All its scopes are classified as Restricted — more on that below.
Sign-in without a secret. Google officially expects a web-server client with a client secret, and you can't ship a secret inside an iOS app. An iOS client with PKCE via ASWebAuthenticationSession worked — no backend, no Google SDK. Tokens live in the Keychain.
Dedup the Apple way. Every HealthKit sample gets HKMetadataKeySyncIdentifier like gh:<type>:<point id> plus HKMetadataKeySyncVersion. A repeated sync replaces the record instead of adding a new one.
Echo filtering. Points that came into Google from Apple Health (platform HEALTH_KIT) are skipped, otherwise you get a loop.
Whole workouts. Workouts are built with HKWorkoutBuilder with calories and distance inside, and per-minute calories/distance that fall into the workout window are dropped so the day doesn't count them twice.
History in chunks. Fresh days first, then history from newest to oldest: workouts and sleep up to a year, steps and calories 90 days, heart rate 30. Progress is stored per metric, so an interrupted sync resumes where it stopped.
Keep the screen on. During a manual sync the idle timer is disabled, and if the phone gets locked anyway the user sees a clear hint instead of a database error.
Format surprises. 64-bit numbers arrive as strings, distance comes in millimeters and sits somewhere other than the docs suggested — the first parser version crashed on a real response. The mapper is covered by tests on trimmed real data.

The main limitation isn't technical. Until the app passes Google's OAuth verification and a third-party security audit, the feature runs in testing mode: at most 100 users, and the Google sign-in expires every 7 days. Fine for personal use, not for everyone. The paid bridges above prove the path is passable — it just takes weeks and money.

What to do right now if you own a Google band

Turn on the official sync in Google Health: add Apple Health in the connections settings. It's free, and for steps and sleep it's often enough.
Set source priority in Apple Health: open a metric → Data Sources & Access → Edit, and put the band above the iPhone so phone and wrist steps don't add up.
Compare a week of workouts in Google Health and Apple Health. No differences — you need nothing else.
If workouts go missing and they matter, pick a bridge from the table — but start with the trial and check your data.
Keep one bridge. Official sync plus a paid app at the same time is the shortest path to duplicates.

What's next

The sync already works in my test build, and I'm going to ship it as a separate app — just the Google Health → Apple Health bridge, nothing else. No name yet: Google verification comes first. I'll write about it when it's out.

Originally published at klukyanov.ru.
Shorter weekly write-ups (in Russian) — on Telegram.

Which AI Subscription Should You Pick for a Task: a Benchmark Table (September 2026)

Kirill Lukyanov — Tue, 22 Sep 2026 11:23:10 +0000

Yesterday SpaceXAI shipped Grok 4.7 with a benchmark table in which Grok 4.7 wins. Three weeks ago OpenAI shipped GPT-6 Astra with a table in which Astra wins. Anthropic did the same with Claude Fable 5.1. None of these tables is fake — but every one of them was put together by the team that ships the model.

So before renewing my own subscriptions I did the boring thing: pulled numbers from eight sources into one matrix. Three independent leaderboards — Artificial Analysis, Vals AI and Arena (blind human voting) — plus the launch posts from OpenAI, Anthropic, Google and SpaceXAI, which, put side by side, check each other surprisingly well.

Snapshot date: September 22, 2026. Every number below is labeled as independent or vendor-reported.

The lineup: six models, four subscriptions

The only rule: the model must be available in a regular paid plan an individual can buy.

Model	Released	Subscription	Price / month
Claude Fable 5.1	Sep 1	Claude Pro / Max	$20 / $100–200
Claude Opus 5	before Sep	Claude Pro / Max	$20 / $100–200
GPT-6 Astra	Sep 3	ChatGPT Plus / Pro	$20 / $200
GPT-5.6 Sol	before Sep	ChatGPT Plus / Pro	$20 / $200
Gemini 3.8 Flash	Sep 2	Google AI Pro / Ultra	$19.99 / $250
Grok 4.7*	Sep 21	SuperGrok	$30

* At launch Grok 4.7 is available in Cursor, Grok Build and the API; SpaceXAI hasn't yet confirmed it in the SuperGrok consumer docs. Check before paying.

Left out on purpose: Meta Muse Spark 1.3 (free in the Meta AI app — not a subscription), Claude Mythos 5.1 (gated to verified security and life-science programs), and open-weight models like DeepSeek, Qwen, Kimi and GLM — they get their own article.

Why you shouldn't take a launch table at face value

Not because vendors lie. Because the same benchmark can be run several ways, and every vendor picks the way that flatters them. Four examples from September alone:

ARC-AGI-3. OpenAI reports 99.9% for GPT-6 Astra — in a harness that preserves reasoning state between steps. In the neutral harness everyone uses, Astra scores 62.7%.
HealthBench Professional. SpaceXAI's table gives Claude Fable 5.1 62.1%. The length-adjusted independent leaderboard gives the same model 56.6% — a gap larger than first-to-third place.
OSWorld 2.0. OpenAI lists Claude Opus 5 at 70.2%. Anthropic lists the same model at 39.6% — in "strict" mode. Both are correct; they're just not comparable.
CursorBench. SpaceXAI uses v4.0, Anthropic uses v3.2. Fable 5.1 scores 51.8% and 73.4% respectively.

Three rules I now apply: independent rankings beat vendor tables even when they have fewer rows; always check who is missing from a table (Grok 4.7's chart has no GPT-6 Astra); and a number without its mode (max, xhigh, with tools, strict) is not a number.

Independent rankings: a tie at the top

Artificial Analysis Intelligence Index: Fable 5.1 and GPT-6 Astra — 53 each, Opus 5 — 51, GPT-5.6 Sol — 47, Grok 4.7 — 46.
Vals Index (finance, legal research, code migration, medical documentation): Fable 5.1 68.8%, Opus 5 67.2%, Astra 66.6%, Gemini 3.8 Flash 62.3%, Grok 4.7 60.2%.
Arena Text (blind voting, Sep 13): Fable 5.1 1498, Opus 5 and Gemini 3.8 Flash 1493 each — within the confidence interval. Arena Code is a different story: Astra 1800, Fable 1758, Opus 1687.

If you're picking one subscription "for everything", Claude and ChatGPT are effectively equal right now. The decision comes down to the tasks where they diverge — and there are plenty.

The full matrix: 6 models × 19 tests

Leader of each row in bold. "—" means the model wasn't tested or the result isn't published. I = independent, V = vendor-reported.

Task · test	Fable 5.1	Opus 5	GPT-6 Astra	GPT-5.6 Sol	Gemini 3.8 Flash	Grok 4.7	Source
Overall · AA Index	53	51	53	47	<46	46	I · Artificial Analysis
Professional tasks · Vals Index	68.8	67.2	66.6	—	62.3	60.2	I · Vals AI
Blind chat · Arena Text	1498	1493	—	—	1493	—	I · Arena
Code, blind · Arena Code	1758	1687	1800	—	—	—	I · Arena
Terminal agent · Terminal-Bench 4.0	55.8	52.3	57.7	37.3	19.1	38.0	V · OpenAI, Anthropic
Long-horizon SWE · DeepSWE v1.1	70.0	74.0	—	72.7	73.7	71.0	V · Google, SpaceXAI
In-editor coding · CursorBench 4.0	51.8	—	—	41.7	—	46.3	V · SpaceXAI
Clinical reasoning · HealthBench Pro	56.6	—	63.4	60.5	—	56.7	I · aggregated leaderboard
Medical coding · Vals MedCode	#7	63.6	#23	—	—	—	I · Vals AI
Legal agent · Harvey LAB	6.7	—	—	2.5	—	19.6	V · SpaceXAI
Legal research · Vals Legal Research	—	55.3	#21	—	—	—	I · Vals AI
Electrical engineering · EEBench	56.4	—	—	39.4	—	64.0	V · SpaceXAI
Documents · GDPval-AA (Elo)	1853	1824	—	1711	—	—	V · Anthropic
Multi-hour office work · AA Briefcase	1678	—	—	1487	—	1657	V · SpaceXAI
Computer use · OSWorld 2.0	—	70.2	72.6	65.7	—	—	V · OpenAI
Research math · FrontierMath T4	87.8	73.2	97.6	83.0	—	—	V · OpenAI
Expert knowledge · HLE with tools	65.0	63.6	57.2	—	—	—	V · Anthropic, OpenAI
Grad-level Q&A · GPQA Diamond	93.7	93.7	96.0	94.6	95.3	—	V · OpenAI
Images & documents · MMMU Pro	90.6	89.9	—	—	—	—	I · Vals AI
API price, $ / 1M tokens (in / out)	10 / 50	—	10 / 50	4 / 20	0.75 / 3.75	2 / 6	V · price lists

Percentages unless noted; Elo and indices in points. For Terminal-Bench, Fable 5.1 uses Anthropic's figure (55.8); SpaceXAI's max-effort run shows 57.9. For HealthBench, the length-adjusted version is used; SpaceXAI's table shows 62.1 for Fable 5.1.

What it means, task by task

Coding depends on what you call coding. If the model works alone in a terminal, it's a tie between Astra and Fable. If you sit next to it in the editor, Fable leads on real Cursor sessions. If you need a lot of code cheaply, Gemini 3.8 Flash is within four points of the leaders on DeepSWE at roughly 1/13 of the token price.

Medicine: ChatGPT for clinical reasoning, Claude for documentation. Astra tops HealthBench Professional (an OpenAI-built benchmark — worth keeping in mind). On medical coding and scribing, independent Vals AI puts Opus 5 and Fable 5.1 first. None of this replaces a doctor: even the leader meets physician criteria in fewer than two thirds of hard cases.

Law and electrical engineering: the only rows Grok wins. 19.6% on Harvey's Legal Agent Benchmark vs 6.7% for Fable; 64.0% on EEBench vs 56.4%. Both numbers are SpaceXAI's own. On independent legal research, Opus 5 leads.

Office work: Claude for documents, ChatGPT for clicking around. Fable leads GDPval-AA and AA Briefcase; Astra leads OSWorld 2.0 and Vals CUA-bench.

Math: Astra by a mile — 97.6% on FrontierMath Tier 4, ten points ahead. But on Humanity's Last Exam with tools, Fable (65.0%) beats Astra (57.2%).

Task → subscription cheat sheet

Task	Model	Plan
Pair-coding in the editor	Fable 5.1	Claude Pro / Max
Autonomous coding agent	Astra or Fable 5.1	ChatGPT or Claude
Lots of code, low budget	Gemini 3.8 Flash	Google AI Pro
Clinical questions	GPT-6 Astra	ChatGPT Plus
Medical documentation	Opus 5 / Fable 5.1	Claude Pro
Legal research	Opus 5	Claude Pro
Legal agent work, circuits	Grok 4.7	SuperGrok (once confirmed)
Reports, spreadsheets, decks	Fable 5.1	Claude Pro / Max
UI automation	GPT-6 Astra	ChatGPT Plus
Math	GPT-6 Astra	ChatGPT Plus / Pro

What I actually use

Two subscriptions, and this table didn't change them. Claude for code — I build iOS and macOS apps and spend most of the day in the editor with the model, which is exactly where Fable 5.1 leads. ChatGPT Pro for everything else — images for my site, calculations, tasks where the model has to finish the job on its own.

The main takeaway: in 2026, "which AI is the best" is the wrong question. The top three differ less than the same model does across modes. You don't pick the best model — you pick the right one for the task.

Next up: the same task-by-task table for open-weight models you can run locally — where they've already caught up with the $20 subscriptions, and where they're still a year behind.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

Yandex open-sourced an 80B model trained from scratch: what's inside and where it wins

Kirill Lukyanov — Mon, 21 Sep 2026 08:45:41 +0000

Yandex just open-sourced a language model it trained entirely from scratch — no borrowed weights, no initialization from Qwen or Llama. It's called AliceAI-Foundation-80B-A3B-Base, it's on Hugging Face under Apache 2.0, and it's a surprisingly interesting release if you care about MoE architecture or non-English models.

Here's what's inside, where it actually wins, and where the benchmark table deserves a second look.

The short version


Parameters	80B total, 3B active per token
Architecture	MoE: 512 experts, top-10 routed + 1 shared
Layers	48 — hybrid Kimi Delta Attention + gated attention (3:1)
Context	262,144 tokens
Training	~18T tokens, from scratch
Languages	Russian, English
License	Apache 2.0 (commercial use OK)

It's a base model — not instruction-tuned, not a chatbot. Yandex calls it experimental: a testbed for the architecture of its upcoming unified reasoning model, which will power agentic features in its Alice AI assistant.

Compared to Yandex's previous flagship (Alice AI LLM, 235B, October 2025), it's almost 3x smaller overall and 7x smaller in active parameters — and, per the technical report, beats it on facts, math, code and long context.

80 billion parameters, three at work

Every token is routed through 10 of 512 small experts plus one shared expert that's always on. You get the knowledge capacity of an 80B model with roughly the per-token compute of a 3B one.

The attention stack is the other notable bit. Three out of every four layers use Kimi Delta Attention — a linear attention variant that folds history into a fixed-size state instead of keeping a KV entry for every past token. Only every fourth layer is classic (gated) attention. In practice that means 262K context without the usual KV-cache blowup — exactly the bottleneck you hit with "read this whole contract" or "understand this repo" workloads.

Benchmarks: where it wins and where it doesn't

Yandex compared base versions against open models in the same weight class and above. A selection from the official model card, including rows where it loses:

Benchmark	AliceAI 80B-A3B	Qwen3.5 35B-A3B	Nemotron-3 Super 120B-A12B	DeepSeek-V4 Flash 284B-A13B
WikiWebFacts (Yandex's own)	86.5	62.4	72.8	83.2
HardMultiQA (Yandex's own)	67.9	47.2	54.5	65.4
EduBench Russian	74.2	42.9	44.0	67.7
ExpertFactsQA Law	49.6	27.9	24.3	40.5
MATH-500	91.1	81.9	84.8	80.7
LiveCodeBench v5-6	50.5	50.4	50.4	38.1
BigCodeBench	48.3	43.5	48.8	49.1
TriviaQA	79.0	71.4	89.8	89.4
MMLU-Pro	66.8	63.2	69.9	66.5
LongMemEval 128k	64.6	55.6	64.8	68.0

The pattern is clear. Anything that needs knowledge of the Russian-speaking world — language, law, school curriculum, local facts — it beats models 4x its active size. That's the training corpus talking. Math is strong too: HMMT Feb 2026 at 96.9 (pass@32) vs 87.9 for Qwen3.5.

On English trivia and general knowledge (TriviaQA, MMLU-Pro), the bigger Nemotron and DeepSeek lead. No magic: 80B parameters can't hold as much about the world as 284B.

Can you run it locally?

3B active sounds laptop-friendly, but all 80B have to sit in memory: ~160 GB in bf16, roughly 45 GB at 4-bit by my estimate. So in theory it's 64 GB Mac territory — and Apple Silicon is where MoE models shine, since you only read a small slice of weights per token.

In practice, not yet. The official recipes are transformers and vLLM on NVIDIA GPUs (the example uses four), and the KDA layers need the flash-linear-attention kernels. I couldn't find GGUF or MLX quants on release day, and non-standard attention is exactly what tends to delay llama.cpp support by weeks.

Caveats

It's a base model. It continues text; it doesn't chat. Instruction tuning is on you (or on Yandex's own future releases).
The two most impressive benchmarks are Yandex's own. To their credit, WikiWebFacts and HardMultiQA were published alongside the weights with evaluation protocols — anyone can re-run them. Until someone does, I'd weight third-party benchmarks more.
It's not a frontier model. This is a compact model winning on data and architecture, not a GPT or Claude competitor.

Still, a fully in-house model with a permissive license, open benchmarks and a detailed tech report is a genuinely useful foundation for anyone building products in Russian — especially in legal, education and reference use cases where its lead is largest.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

Best Ollama Models for Coding, Writing and Medicine (September 2026)

Kirill Lukyanov — Sun, 20 Sep 2026 07:27:42 +0000

A 0.9-billion-parameter model beats a 27-billion one — as long as you hand it a scanned document instead of a conversation. That single fact is why "top 10 local models" lists are useless: they rank by size, and size is not what you pick a model by.

I spent a weekend going through the Ollama library sorted by task rather than by parameter count. Here is what the landscape looks like at the end of September 2026, and — more importantly — the three rules that will still hold when every name below has been replaced.

Rule 1: read the tag, not the name

Sort the Ollama library by newest and the top rows are deepseek-v4.1-flash, glm-5.3, kimi-k3, minimax-m3. All four carry a cloud tag.

That means ollama run ships your prompt to someone else's servers. It is a great way to try a model that would never fit on your machine. It is not local inference, and if you came here for privacy or offline work, those rows get crossed out first.

Rule 2: specialisation beats size on its own turf

The clearest example of the month is glm-ocr: 0.9B parameters, 2.2 GB on disk, and the top spot on OmniDocBench V1.5 at 94.62. Feed it a messy invoice with nested tables, footnotes and formulas and it holds. A general-purpose 27B vision model does not — nobody trained it for document structure.

The right pipeline is boring and effective: glm-ocr turns the document into structured text, then a general model reasons over that text.

Rule 3: the benchmark is not your task

SWE-bench, the number everyone quotes, measures fixing a bug in an unfamiliar repository from an issue description. That is very different from "write me this function" and nothing at all like "explain what this code does". A high SWE-bench score on a model you keep around for autocomplete tells you close to nothing.

Coding

Qwen3.8-27B landed on 14 August: 27.78B dense parameters, Apache 2.0, 17.7 GB in the Ollama build, a 256K context window, vision included. Qwen reports 73.0 on Terminal-Bench 2.1 (up from 63.4), 61.7 on SWE-bench Pro, 90.3 on LiveCodeBench v6 and 84.3 on OSWorld-Verified, up from 63.9. Its Artificial Analysis index went up 14 points over the previous generation on an identical architecture — all of it from post-training.

If 18 GB of weights is out of reach, the choice is between two smaller ones:

Model	What it is	Speed	Strength
`qwen3.8:27b`	dense 27B, vision, 256K	~7 tok/s on a Mac mini M4	terminal agent, long tasks
`devstral-small-2:24b`	dense 24B from Mistral, vision	139.2 tok/s	responsiveness, multi-file edits
`qwen3-coder:30b`	MoE, 3B active of 30	90.6 tok/s	quality per gigabyte

Those throughput numbers come from Artificial Analysis on provider hardware — at home they will be lower, the ratio is what matters. One detail most reviews skip: Devstral's context costs roughly twice as much memory, about 5 GB per 32K tokens versus 3 GB for the MoE Qwen. On a machine where RAM is tight, that decides it.

Agents: Meta is back, and that is the surprise of the month

Three weeks ago Meta was the cautionary tale of open weights — the company that invented the strategy, down to under one percent of tokens on OpenRouter. Today muse-glimmer sits in the Ollama library: 30B parameters, Apache 2.0, 18.2 GB, 128K context, and over two hundred thousand pulls in three weeks.

The model card is refreshingly unambitious: tuned for "tool use, long tasks, and failure recovery". Not smartest — the one that finishes. Meta reports 75.5 on MCP Atlas, 51.2 on SWE-Bench Pro and 94.7 on AIME 2026.

That framing is the actual lesson. An agentic task is not one answer, it is a hundred in a row. A model that is right 90% of the time but never notices its own mistake loses to one at 85% that catches and redoes it.

Next to it sits NVIDIA's nemotron-3.5-lightning (11 August): 30B total, 3B active, interleaved Mamba-2 and MoE layers, 51.56 on SWE-bench Verified, 75.44 on GPQA Diamond, 81.94 on MMLU Pro. The headline 1,200 tokens per second is a provider-hardware measurement, not a laptop one — but the architecture is genuinely built to emit tokens fast.

Writing: the honest answer is still "not locally"

On EQ-Bench Creative Writing v3 the top of the board is closed: Claude Opus 5 at 2121 Elo, GPT-5.6 Sol at 1963. The best open-weights score belongs to Kimi K3 at 2071 — a 2.8-trillion-parameter model that needs a multi-node cluster. "Open" in the same sense an operating system's source code is open to someone without a chip fab.

What does work locally is working text: email, summaries, tightening a paragraph, turning a call transcript into structure. The pick there is gemma4, with 25.3M pulls the most downloaded model in the library.

A Russian-language test from May on an RTX 5070 Ti ran Gemma 4, Qwen 3.6 and Qwen3-Coder through twelve practical tasks. Gemma 4 in fast mode scored 12/12, Qwen 3.6 got 9/12. And a finding worth more than any index: turning thinking mode on made instruction-following worse — 11/12 instead of 12 for Gemma, 7 instead of 9 for Qwen.

Medicine: the one area where a specialised model is mandatory

Start with the boundary, not the models. Open medical models ship under the Health AI Developer Foundations terms, and Google says plainly that they are not clinical grade and require task-specific validation. This is a building block for a developer, not a patient-facing chatbot and not a second opinion.

Within that boundary they are genuinely useful. medgemma1.5:4b is 3.3 GB with a 128K context and vision; version 1.5 added whole-slide histopathology, longitudinal imaging, anatomical localisation and document understanding. It scores 89.6% on EHRQA and turns a lab report into structured JSON at 91.0 macro-F1. The text-only medgemma:27b reaches 87.7% on MedQA. For broad health conversations graded by physicians, gpt-oss-120b leads open models on HealthBench at 0.576 — but that is 65 GB of weights.

The realistic use for a private person: put your own records into readable shape, merge several documents into one table, prepare questions for an appointment — all on your own machine, without shipping medical data into someone's cloud.

Retrieval: embeddings matter more than the generator

The most common mistake in a homegrown RAG setup is spending all the memory on a big generator and grabbing whatever embedding model came first. It works the other way round: if retrieval returns the wrong chunks, the model on top will confidently summarise the wrong thing.

Model	Size	When
`qwen3-embedding:0.6b`	0.6 GB	best quality per gigabyte, tunable dimensions
`qwen3-embedding:8b`	4.7 GB	maximum quality, 70.58 MTEB multilingual
`bge-m3`	1.2 GB	multilingual corpora, hybrid dense+sparse, 8K context
`embeddinggemma:300m`	0.6 GB	high-volume indexing
`nomic-embed-text`	0.3 GB	simplest start, 86M pulls

The Qwen3-Embedding family lets you set the vector dimension anywhere from 32 to 1024, which is a direct saving on your vector store — you choose the trade-off instead of inheriting it.

For the generator on top, something modest does the job. IBM's granite4.2 (3B/8B/30B, Apache 2.0, 128K) was tuned for exactly this: RAG, tool calls and structured JSON output.

The table

Sizes below are not approximations — I pulled them from the Ollama registry manifests, so this is the sum of layers you will actually download, as of 20 September 2026. In memory it will be more, by the size of your context.

Task	Model	Command	Size
Terminal agent, long coding tasks	Qwen3.8-27B	`ollama pull qwen3.8:27b`	17.7 GB
Fast coding assistant	Devstral Small 2	`ollama pull devstral-small-2:24b`	15.2 GB
Coding on tight memory	Qwen3-Coder 30B-A3B	`ollama pull qwen3-coder:30b`	18.6 GB
Tool-using agent	Muse Glimmer (Meta)	`ollama pull muse-glimmer:30b`	18.2 GB
Many small steps, speed matters	Nemotron 3.5 Lightning	`ollama pull nemotron-3.5-lightning:30b`	25.4 GB
Writing, editing, email	Gemma 4	`ollama pull gemma4:12b`	7.6 GB
Same on weak hardware	Gemma 4 E2B	`ollama pull gemma4:e2b`	7.2 GB
Medical documents and imaging	MedGemma 1.5	`ollama pull medgemma1.5:4b`	3.3 GB
Medical text only	MedGemma 27B	`ollama pull medgemma:27b`	17.4 GB
Scans, PDFs, tables, formulas	GLM-OCR	`ollama pull glm-ocr`	2.2 GB
Images on weak hardware	MiniCPM-V 4.6	`ollama pull minicpm-v4.6:1b`	1.6 GB
Search over your own documents	Qwen3-Embedding	`ollama pull qwen3-embedding:0.6b`	0.6 GB
Same, multilingual corpus	BGE-M3	`ollama pull bge-m3`	1.2 GB
Answers over documents, strict JSON	Granite 4.2	`ollama pull granite4.2:8b`	5.3 GB

What is deliberately missing

Translation. I meant to write that section, but the honest answer is that the best model in the niche is closed. Qwen3.8-LiveTranslate, released 19 September, does simultaneous interpretation at 2.3 seconds of lag across 60 input languages — API only, no weights. Locally there is nothing but general models that translate "fine".

Ornith-1.5. Sizes of 9B, 35B and 397B, 256K context, a self-improvement loop that generates its own training tasks, three hundred thousand pulls in a month. The most interesting row in the library, and exactly why it is not in my list: there are no comparable independent numbers yet.

What I actually run

On a 16 GB MacBook: gemma4:12b as the generalist, plus glm-ocr and qwen3-embedding:0.6b for documents and search over my own archive. Everything heavier is a different machine or a rented endpoint.

If I had to keep exactly one model forever, it would be Gemma 4 at whatever size fits. Not because it wins benchmarks — it does not — but because it does what you asked instead of what it found more interesting. Twenty-five million pulls is a lot of people arriving at the same conclusion independently.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

Running Flux locally on a Mac: install, commands and two models compared

Kirill Lukyanov — Sun, 20 Sep 2026 05:55:52 +0000

People write about local image generation in one of two ways. Either "it installs in three clicks, why pay for anything," or "it doesn't work on a laptop." Both are equally useless when you're sitting in front of an empty terminal and just want a picture out of it.

So here's the manual instead. Every command below was actually run on this machine, every number comes from the log of a specific run: Apple M5, 16 GB of unified memory, macOS 26.5, stable-diffusion.cpp build master-650.

We'll install two models from the same family, and the difference between them is the whole point. Flux.1-schnell draws a frame from scratch out of text. Flux.1-Kontext-dev takes a finished picture and changes exactly what you asked for, leaving the rest alone. Different jobs — one doesn't replace the other.

Why keep a model on your own machine

An honest list of exactly three reasons, because there is no fourth one.

Free. There is no spend counter at all. Trying thirty variations of a scene costs you time and nothing else. That changes behaviour: with a cloud API you think before you press enter, locally you just run batches in the background.
Offline. No internet needed at any point once the weights are downloaded. Planes, cabins, dead VPNs, corporate networks that block everything — the model doesn't care.
Private. The picture never leaves your machine. This is the one argument the cloud cannot beat: NDA material, someone else's mockups, internal screenshots.

And now the part these articles usually skip. Local will not be faster than the cloud. In an earlier benchmark on identical prompts, local Flux produced a frame in 172 seconds and GPT Image in 167 — and the cloud model was visibly better at composite scenes. Local wins on cost, autonomy and privacy. Not on speed, and not on quality.

Step 1. Build the engine

xcode-select --install
brew install cmake

git clone --recursive https://github.com/leejet/stable-diffusion.cpp ~/Tools/stable-diffusion.cpp
cd ~/Tools/stable-diffusion.cpp
mkdir build && cd build
cmake .. -DSD_METAL=ON
cmake --build . --config Release -j

Two places where people trip.

--recursive is mandatory. The ggml compute core is a submodule; without it the build dies on missing headers. Already cloned without it? git submodule update --init --recursive.

-DSD_METAL=ON is what turns the GPU on. The .cpp suffix in the project name is misleading — it reads like "the CPU version, therefore slow." It isn't. The first line of the log says:

ggml_metal_device_init: GPU name: MTL0 (Apple M5)

The GPU does the work. The CPU gets a separate and fairly humiliating job: cleaning up after what's broken in Metal. More on that below, and it's the most important section here.

Step 2. Download the weights

Flux is not one file. It's four, and all four are required.

File	Size	What it does
`flux1-schnell-Q4_K_S.gguf`	6.3 GB	the diffusion model itself
`t5xxl-Q4_K_M.gguf`	2.7 GB	T5 text encoder — parses long phrasing
`clip_l.safetensors`	235 MB	second text encoder, CLIP
`ae.safetensors`	320 MB	VAE — turns the result into pixels

Two encoders is a Flux architecture thing: CLIP gives the general mood of the prompt, T5 reads the wording word by word. That's also where its strength comes from — you write long descriptive English sentences, not comma-separated tags.

mkdir -p ~/Tools/sd-models/flux && cd ~/Tools/sd-models/flux

curl -L -C - -o flux1-schnell-Q4_K_S.gguf \
  https://huggingface.co/city96/FLUX.1-schnell-gguf/resolve/main/flux1-schnell-Q4_K_S.gguf

curl -L -C - -o t5xxl-Q4_K_M.gguf \
  https://huggingface.co/city96/t5-v1_1-xxl-encoder-gguf/resolve/main/t5-v1_1-xxl-encoder-Q4_K_M.gguf

curl -L -C - -o clip_l.safetensors \
  https://huggingface.co/comfyanonymous/flux_text_encoders/resolve/main/clip_l.safetensors

curl -L -C - -o ae.safetensors \
  https://huggingface.co/second-state/FLUX.1-schnell-GGUF/resolve/main/ae.safetensors

About the VAE: the obvious place to get it would be the official Black Forest Labs repo, but it's license-gated and returns 401 without a token and an accepted agreement. Hence the second-state mirror — same file, byte for byte.

The gotcha that costs you an evening

curl can break in the middle of a large file and exit with code 0. The file looks complete, the GGUF header is there, and the model simply won't load. The error you get is unhelpful:

read tensor data failed

Check the size against the header the server sends:

URL=https://huggingface.co/city96/FLUX.1-schnell-gguf/resolve/main/flux1-schnell-Q4_K_S.gguf
EXPECTED=$(curl -sIL "$URL" | awk 'BEGIN{IGNORECASE=1} /^content-length:/{l=$2} END{print l+0}')
ACTUAL=$(stat -f%z flux1-schnell-Q4_K_S.gguf)
[ "$ACTUAL" -eq "$EXPECTED" ] && echo "OK" || echo "TRUNCATED: $ACTUAL of $EXPECTED"

-C - resumes from where it broke, so re-running loses nothing. If your connection drops regularly, add --speed-limit 51200 --speed-time 30: that pair kills a dead connection after half a minute instead of hanging on a 30-minute timeout.

One more thing that isn't about the tooling: don't generate while the weights are downloading. The model pushes memory into swap, and under swap the network on this machine dies — HuggingFace starts serving kilobytes per second, which then gets blamed on "bad internet."

Step 3. The first picture

~/Tools/stable-diffusion.cpp/build/bin/sd-cli -M img_gen \
  --diffusion-model ~/Tools/sd-models/flux/flux1-schnell-Q4_K_S.gguf \
  --vae        ~/Tools/sd-models/flux/ae.safetensors \
  --clip_l     ~/Tools/sd-models/flux/clip_l.safetensors \
  --t5xxl      ~/Tools/sd-models/flux/t5xxl-Q4_K_M.gguf \
  -p "A vintage green enamel mug standing on a weathered wooden windowsill, warm morning light, a rainy blurred street outside the window, photorealistic, 50mm lens, shallow depth of field, no legible text anywhere" \
  --cfg-scale 1.0 --sampling-method euler --steps 4 \
  -W 1024 -H 1024 --seed 42 \
  --vae-on-cpu --diffusion-fa \
  -o ~/Desktop/first.png

Two flags you must not touch.

`--cfg-scale` stays at 1.0

The 7.0 that floats around every Stable Diffusion tutorial turns the picture into coloured noise here. Schnell is a distilled model: it was trained to hit the target in a handful of steps without a guidance mechanism. At 1.0 that mechanism is effectively off, which is the correct mode.

Same root cause for the second surprise: negative prompts do nothing. Not "work poorly" — they physically don't participate in the computation. "No people in frame" has to become "an empty street."

`--vae-on-cpu` is the most expensive thing I know about this stack

Without it you get a blank white frame. Not an error, not a crash — a white rectangle, and the log cheerfully says:

save result image (success)

Flux's VAE decoder returns NaN on Metal and the result silently collapses. You can spot it instantly by file size: a broken PNG is about 17 KB, a live one is 450 KB and up (mine came out at 1.7–1.9 MB). If you see seventeen kilobytes, don't rewrite the prompt and don't re-download the weights — just add the flag.

The flag moves decoding to the CPU. That isn't free: on a 1024×1024 frame the CPU VAE costs about 58 seconds, and those 58 seconds are in every single picture no matter how many steps you run.

How many steps you actually need

The common "put it on twenty steps for more detail" advice is not just useless for schnell, it's actively wrong. Three runs, same prompt, same seed, only the step count differs:

Steps	Sampling	VAE on CPU	Total	Incl. loading weights
1	26.4 s	57.3 s	84.2 s	99 s
4	105.2 s	58.9 s	164.5 s	185 s
8	210.6 s	59.0 s	270.0 s	284 s

Three things fall out of this table, none of them obvious up front.

A step costs exactly 26.3 seconds, linearly. No warm-up: the first step costs the same as the eighth. So you can do the arithmetic in your head — 58 seconds plus 26 per step.

At one step, two thirds of the time isn't drawing. 57 seconds out of 84 is the CPU VAE, i.e. working around the Metal bug. On fast modes you're mostly paying to patch Metal, not to run the model.

Eight steps don't give you "the same, but better." They give you a different frame: different angle, different light, different street outside the window. For a distilled model the step count is another dimension of the scene, like the seed. So "let me add steps to fix that weird handle" doesn't work — you'll get a different mug.

Practical default: 4 steps for real work, 1 step for browsing ideas. One step in a minute and a half already gives a usable frame; run a dozen concepts that way, then re-run the good one at 4 steps with the same seed.

One more thing from the 8-step frame: the model decorated the buildings with shop signs whose letters are not letters. Flux renders plausible gibberish instead of text, and the more steps, the more eagerly. Put no legible text anywhere in the prompt — and if you genuinely need readable text in the image, a local model is the wrong tool.

The second model: editing a finished frame

Here's the reason to keep a second model on disk at all. A generator has a built-in limitation you can't prompt your way around.

Picture this: the frame came out well, you like everything, but you'd like the mug replaced with a cactus. Asking the generator for that is pointless — it will draw a new picture: different light, different window, different street. You can burn an hour on retries and never get the same scene back, because "the same scene" doesn't exist in its world.

Flux.1-Kontext-dev works differently: it takes a finished image plus an instruction about what to change. Same command as before with three differences — a different model file, a -r flag pointing at the source image, and a prompt in the imperative:

~/Tools/stable-diffusion.cpp/build/bin/sd-cli -M img_gen \
  --diffusion-model ~/Tools/sd-models/flux-kontext/flux1-kontext-dev-Q4_K_S.gguf \
  --vae        ~/Tools/sd-models/flux/ae.safetensors \
  --clip_l     ~/Tools/sd-models/flux/clip_l.safetensors \
  --t5xxl      ~/Tools/sd-models/flux/t5xxl-Q4_K_M.gguf \
  -r first.png \
  -p "Replace the green enamel mug with a small potted cactus in a terracotta pot, keep everything else exactly the same" \
  --cfg-scale 1.0 --guidance 2.5 --sampling-method euler --steps 8 \
  -W 1024 -H 1024 --seed 42 \
  --vae-on-cpu --clip-on-cpu --diffusion-fa \
  -o cactus.png

Kontext weights live separately, the encoders and VAE are reused — it's exactly one more file:

mkdir -p ~/Tools/sd-models/flux-kontext && cd ~/Tools/sd-models/flux-kontext

curl -L -C - -o flux1-kontext-dev-Q4_K_S.gguf \
  https://huggingface.co/QuantStack/FLUX.1-Kontext-dev-GGUF/resolve/main/flux1-kontext-dev-Q4_K_S.gguf

Same gated-repo trap here: the city96 Kontext build needs an accepted license and returns 401 without a token. The QuantStack mirror is open.

The mug became a cactus, and the street behind the glass, the frame, the raindrops, the windowsill planks and the light all stayed exactly as they were. None of those were mentioned in the prompt — the model understood it wasn't asked to touch them.

Parameter	schnell	Kontext
Source image	none	`-r file.png`
`--guidance`	unused	2.5
`--steps`	1–4	8–20
`--clip-on-cpu`	not needed	recommended
Prompt	describes the frame	says what to change

Kontext is not distilled — unlike schnell it's an ordinary model, so it wants both --guidance and more steps. Eight is the working minimum; complex edits are worth twenty.

--clip-on-cpu pushes the text encoders into regular RAM. Kontext's diffusion part is heavier, and on 16 GB that flag decides whether everything fits at once: it splits the load into 6.5 GB on the GPU and 3.5 GB in RAM instead of nearly ten in one place.

It preserves the scene, not the pixels

It looks like the model neatly cut out the mug and pasted a cactus. In reality the whole frame is re-rendered, just with the original in view. I measured the difference pixel by pixel:

Difference	Share of the frame
> 8 levels	81.8%
> 16 levels	33.6%
> 32 levels	11.7%

The "untouched" background is in fact touched — you just can't see it. Practical consequence: you cannot layer a Kontext result over the original, and you cannot use it to edit a photo where pixel authenticity matters. For an article cover it's irrelevant. For a document or someone else's photo it isn't.

What it costs in time

Editing is more expensive than generating, for an obvious reason: the model has to read the source image first, not just the text. One run, 1024×1024, eight steps:

Stage	Time	Where
Loading weights	14.9 s	disk → memory
Reading the source image	30.9 s	CPU, same VAE
Parsing the prompt	9.2 s	CPU
Sampling, 8 steps	469.2 s	GPU, 58.7 s/step
Decoding the result	51.0 s	CPU, forced
Total	561 s ≈ 9.5 min

Nine and a half minutes per edit is not "playing around." It's a go-make-coffee workflow, and you should plan around that.

The result is reproducible, though. I ran the same request twice: the first time the machine was thrashing and each step took two minutes, the second time memory was free. Both runs produced a byte-identical PNG. Machine load affects the time, not the picture.

Q4 vs Q6: are three gigabytes worth it

The file name tells you how hard the model was squeezed. Quantization stores weights at reduced precision: Q4 gives each number roughly four bits instead of sixteen, Q6 roughly six. Higher number, closer to the original, fatter file.

For Kontext the gap is three gigabytes, and on a 16 GB machine that isn't an abstraction. I ran both on the same picture with the same prompt and seed.

Quant	File	Memory for the model	Per step	Total, 8 steps
Q4_K_S	6.3 GB	9.8 GB	58.7 s	561 s
Q6_K	9.2 GB	12.6 GB	57.0 s	605 s

You can't tell the outputs apart by eye, and that's measurable, not a feeling:

SSIM — 0.983 out of 1.0
PSNR — 33.9 dB
1% of pixels differ by more than 16 levels; mean difference across the frame is 1.7 levels out of 255

For comparison, the edit itself changed a third of the frame. The difference between quants is thirty times smaller than the difference you asked for.

Speed, interestingly, is a wash too: 58.7 s/step for Q4 against 57.0 for Q6 is run-to-run noise, not an advantage. The extra three gigabytes don't slow the math down. They eat memory — and that's the real price.

So on 16 GB the answer is simple: take Q4. Three gigabytes of disk is the lesser problem; the worse one is that those same three gigabytes move the machine closer to swap. And swap on these models costs you multiples, not percentages: I left a second generation process running by accident, and a 58-second step turned into 142.

Cheat sheet

Two shell functions save you from retyping the long command:

FLUX=~/Tools/sd-models/flux
SD=~/Tools/stable-diffusion.cpp/build/bin/sd-cli

# generate from scratch: img "prompt" [steps]
img() {
  $SD -M img_gen \
    --diffusion-model $FLUX/flux1-schnell-Q4_K_S.gguf \
    --vae $FLUX/ae.safetensors --clip_l $FLUX/clip_l.safetensors \
    --t5xxl $FLUX/t5xxl-Q4_K_M.gguf \
    -p "$1" --cfg-scale 1.0 --sampling-method euler --steps "${2:-4}" \
    -W 1024 -H 1024 --vae-on-cpu --diffusion-fa \
    -o ~/Desktop/img_$(date +%H%M%S).png
}

# edit a finished frame: edit source.png "what to change"
edit() {
  $SD -M img_gen \
    --diffusion-model ~/Tools/sd-models/flux-kontext/flux1-kontext-dev-Q4_K_S.gguf \
    --vae $FLUX/ae.safetensors --clip_l $FLUX/clip_l.safetensors \
    --t5xxl $FLUX/t5xxl-Q4_K_M.gguf \
    -r "$1" -p "$2" --cfg-scale 1.0 --guidance 2.5 \
    --sampling-method euler --steps 8 -W 1024 -H 1024 \
    --vae-on-cpu --clip-on-cpu --diffusion-fa \
    -o ~/Desktop/edit_$(date +%H%M%S).png
}

And one habit that saves hours — check swap before starting a heavy model:

sysctl -n vm.swapusage

If it's full, don't hunt for speed by tuning steps and resolution. Let memory free up first. On 16 GB of unified memory the rule is blunt but accurate: either the model, or everything else.

What I actually use it for

Local Flux isn't a replacement for the cloud, it's a separate tool with its own niche. It's not faster and not better — it's free, autonomous, and it shows your pictures to nobody.

Drafts. Checking whether a cover concept reads at all — ten variants at one step each while the tea brews. The one that works goes to a cloud model for the final.
Edits. "Keep everything, just change this" requests go to Kontext, because a generator answers those with a new picture.
Anything that can't leave the machine. No alternative here.

Fifteen minutes to build, an evening to download, 17 GB on disk — and after that it just works, with no counter and no internet.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

Local generation on a Mac: where it is actually free, and where it costs two hours per second

Kirill Lukyanov — Fri, 18 Sep 2026 09:04:44 +0000

Two hours and fourteen minutes of compute for one second of video. That is not a joke about running things on the CPU — it is a number from a log.

I spent a week putting the whole local generation stack through its paces on a single machine: Apple M5, 16 GB of unified memory, macOS 26.5, a locally built stable-diffusion.cpp. Stills, editing existing frames, video. The goal was to find out where "just run it locally, it's free" is honest advice and where it stops being an option at all.

Every number below comes from the log of a specific run.

First, kill the CPU myth

Because of the .cpp in the name, stable-diffusion.cpp gets filed under "the slow CPU version". The first line of the log says otherwise:

ggml_metal_device_init: GPU name: MTL0 (Apple M5)

That is the ggml Metal backend. The work runs on the GPU. The CPU gets one job here, and it is a humiliating one: finishing what is broken on Metal. That happens twice in this article.

The second thing that shapes everything: on Apple Silicon, memory is shared. A model has no private VRAM — it takes system memory, the same pool your browser and editor live in:

total params memory size = 9959.28MB (VRAM 9864.71MB, RAM 94.57MB)
  text_encoders     3395.09MB (VRAM)
  diffusion_model   6469.62MB (VRAM)
  vae                 94.57MB (RAM)

Ten gigabytes out of sixteen for one model. Everything else on the machine splits the rest. Most of what follows grows out of that single fact.

Stills: works, and genuinely free

Flux.1-schnell, 4-bit quant, 1024×512, four steps:

Stage	Time	Where
Loading weights from disk	~15 s	disk → memory
Sampling, 4 steps	46.83 s	GPU, 11.70 s/step
VAE decode	24.36 s	CPU, not by choice
Total, launch to PNG	87 s

Ninety seconds per frame is a working pace. Not instant, but fast enough to iterate on composition without watching a billing counter. schnell is distilled — four steps is what it was trained for, cranking it to twenty buys nothing.

Now the trap that makes people conclude local generation is broken. One flag:

--vae-on-cpu

Without it, the Flux VAE decoder produces NaN on Metal and you get an empty white frame. The nasty part: there is no error in the log. It cheerfully prints save result image (success). You identify it by file size — a broken PNG is about 17 KB, a real one starts at 450 KB. The flag moves decoding to the CPU, and that is exactly the 24 seconds in the table above. A third of total generation time goes into working around a bug, and that is still the good news in this article.

The 29x memory cliff

Flux generates from scratch. Kontext, from the same family, edits: it takes an existing image and changes what you asked while keeping the rest. In practice it covers the one request a generator cannot serve — "keep everything, move this one thing." Ask a generator that and you get a new picture: different light, different furniture, different angle.

Then came the most instructive measurement of the week. Identical run — same model, same prompt, 768×432, eight steps, same flags — on the same machine:

Machine state	Per step	Eight steps
Swap at 8.5 GB of 9.2 (after a series of Flux runs)	445 s	~1 hour
Swap collapsed, 6+ GB free	15.36 s	~2 minutes

Twenty-nine times, with nothing changed but the state of memory. Once the model runs out of physical RAM, every step starts going to disk and stops keeping up.

The practical rule is dull but saves hours: check sysctl -n vm.swapusage before starting a heavy model, and if swap is full, let memory settle instead of tuning steps and resolution. I spent two days convinced Kontext was hopelessly slow. It was queuing behind its own swap.

Video: three walls in a row

Then I tried to animate finished frames locally — even rough drafts would do. I took the smallest sane video model available, deliberately one that fits in memory. Three walls followed, each behind the previous one.

Wall	What the log says	Way around
Quantized weights won't load	`invalid number of dimensions: 5 > 4`	official safetensors, 4.1 GB instead of 1.7
VAE fails on Metal	`unsupported op` in `WanVAERunner::_compute`	`--vae-on-cpu`
Denoiser fails on Metal	`unsupported op 'IM2COL_3D'`	none

Wall one: 5 > 4. A video model convolves over time as well as width and height, so its first convolution kernel is a five-dimensional tensor. In ggml, the maximum tensor rank is four — a constant in the library core, not a build option:

gguf_init_from_file_ptr: tensor 'patch_embedding.weight'
  has invalid number of dimensions: 5 > 4

I assumed a bad conversion and downloaded a quant from a different repository by a different author. Identical failure — which is the signal that the file is not the problem. Official safetensors load fine through a different code path, at the cost of size: 4.1 GB instead of 1.7, which defeats the point of quantizing.

Useful corollary: updating the engine for this error is pointless. The limit is architectural.

Walls two and three: two unsupported ops. The model loaded, then the VAE encoder died with unsupported op — fixed by the same --vae-on-cpu flag as Flux, for an entirely different reason. Then the denoiser died for good:

ggml_metal_op_encode_impl: error: unsupported op 'IM2COL_3D'

Before blaming an old build, go read the source — which I did. IM2COL_3D does not exist in the Metal backend of either the fork stable-diffusion.cpp builds on or upstream ggml inside llama.cpp: zero mentions in ggml-metal-device.cpp and ggml-metal-ops.cpp in both repositories. The operation the model cannot run without was simply never written for Metal. Not "misconfigured", not "needs an update" — absent.

The CPU fallback, priced

That leaves --backend cpu: compute everything on the processor, around Metal and its holes. I ran it to close the question with a number instead of an opinion. Minimal task: one second of video, 512×288, 17 frames, 8 steps.

Stage	Time
Reference encode (VAE)	77 s
Sampling, 8 steps	7728 s — 256 to 1079 s per step
Decode (VAE)	115 s
Total, one second of video	8027 s = 2h 14m

Note the spread: four to eighteen minutes per step, slower toward the end as the machine sinks deeper into swap.

The output was worse than the time. Composition drifted from the reference, objects disappeared and new ones appeared, there was almost no motion between first and last frame, and anatomy broke on limbs. Also worth knowing: in this mode the input image is a reference, not a locked first frame — the model treats it as a hint and owes you nothing. Locking first and last frames is a different mode that lives in 14B models, which is not a conversation you have with 16 GB of RAM.

Generation strangles your network

A side finding that first looked like a bad ISP. Downloading weights crawled at 2.5 KB/s, while the same link gave 1.6–3.3 MB/s on an idle machine. The culprit was local: a generation was running, swap was full, and the network died along with everything else.

Hence a rule that is not obvious until it bites: never run generation and downloads at the same time — chain them, weights first, compute second. And on downloading itself: hf download creates a new temp file on every broken attempt instead of resuming the old one, so on a flaky link it never finishes. After a series of attempts I had three stumps of one file: 0, 52 and 755 MB. What works is a resumable curl in a retry loop:

curl -sL -C - --speed-limit 51200 --speed-time 30 --max-time 600 -o "$F" "$U"

-C - resumes at the break, and --speed-limit with --speed-time kill a dead socket in 30 seconds instead of hanging in a half-hour timeout.

What "free" actually costs

No money, but it bills you in disk:

Family	On disk	Outcome
Flux (schnell, encoders, VAE)	9.6 GB	works
Flux Kontext (two quants)	16 GB	works
Video model (weights, encoder, VAE)	9.8 GB	computes nothing
Total	35 GB

Nearly ten of those gigabytes are a paid lesson: weights for a model that will not render a single frame on this machine. Plus the time to download them, plus two hours of fan noise for one second of garbage. For reference, that second costs roughly $0.10 (480p) to $0.23 (720p) in the cloud at public Seedance 2.5 pricing — and comes back usable.

Where I landed

Local: drafts and idea checks — composition, angle, "does the joke read". Ninety seconds a shot, no billing counter. The cover image of the original article was made exactly this way: local draft to approve the concept, paid generation for the final.
Local: editing an existing frame with Kontext. Two minutes for something a generator will not do at all.
Local: anything that should not leave the machine.
Paid: final quality. A 4-bit quant on 16 GB loses detail, and a cover is what people see before the text.
Paid: video, entirely. Not because local is more expensive, but because on this hardware local does not exist.

One direction I have not closed: MLX, Apple's tensor framework for unified memory. It runs outside ggml and its limits, the Flux port is mature, video ports exist but are raw. If I come back to local video on Apple Silicon, it will be through MLX, not through the path in this article.

If there is one line to take away: local generation is not a free replacement for the cloud, it is a different tool with its own domain. It covers drafts, iteration and privacy very well, and final quality and video not at all. Both slogans — "why pay for anything" and "it doesn't work on a laptop" — get in the way equally.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

Russia Just Started Selling Quantum Computers as Hardware, Not Cloud Time

Kirill Lukyanov — Wed, 16 Sep 2026 18:32:42 +0000

Yesterday's headlines all said the same thing: "Russia starts selling quantum computers." Technically true — for the first time, a Russian quantum computing effort isn't offering "cloud access," it's issuing an invoice and shipping hardware. But behind that headline is a much narrower and much more interesting story than "Russia catches up to Google."

What's actually being sold isn't a personal computer, or even a data-center server — it's a research installation the size of a walk-in freezer, priced like an apartment, built for "try real quantum hardware," not "solve a business problem faster than a classical machine." The details of what's in the box matter a lot more than the word "quantum" in the headline.

What's actually for sale

The seller is Quantum Park — a joint center of Bauman Moscow State Technical University and VNIIA (a Rosatom research institute), led by the same team (Ilya Rodionov's group) that shipped Russia's first batch of photonic chips back in July. The product line is called SnowDrop and comes in four configurations of superconducting quantum coprocessors:

Model	Qubits	Topology	Single-qubit fidelity	Two-qubit fidelity
SnowDrop 4QTCS	4	T-shaped	up to 99.96%	—
SnowDrop 8Q2TCS	8	T-shaped	99.927%	99.21%
SnowDrop 8QGCL	8	Grid	99.9%+	up to 99.55%
SnowDrop 10QGCL	10	Grid	99.9%+	up to 99.55%

The platform is marketed as scalable to 48 qubits — that's a roadmap, not what ships today. Every model comes as a complete kit: the quantum chip itself, a cryogenic readout system, a Russian-made ultra-low-temperature cryostat called YARANGA with control signal switching, qubit control electronics, and a software stack for running algorithms. They're not selling a chip — they're selling a turnkey lab.

The price: 170 million rubles, and the questions that go unanswered

Only one number is public: the entry-level platform with the 4-qubit processor starts at 170 million rubles (roughly $1.9M) — comparable, as several outlets pointed out, to a four-bedroom apartment in central Moscow. Pricing for the 8- and 10-qubit versions hasn't been disclosed. Given that more qubits mean tighter cooling and connectivity requirements, a higher price is a safe bet, but I won't put a number on it — there isn't one in any public source.

This isn't really a complaint about secrecy: per-unit price lists are rare for this class of hardware globally. IBM and Google don't publish quantum system pricing either — they negotiate contracts individually. But it does mean there's currently no way to compare "cost per Russian qubit" to "cost per IBM qubit" in any meaningful way.

Fidelity: the numbers are real, the bar is different

The most concrete thing in this release is the fidelity data, and it's genuinely good for a superconducting architecture: single-qubit gate errors under 0.2%, two-qubit gate errors under 1% on the best qubit pairs. For context, the widely cited threshold below which error correction can actually suppress accumulated noise rather than add to it sits around 99% two-qubit fidelity. So the claimed numbers are formally above that threshold — that's a real engineering result, not marketing rounding.

The catch: "operation fidelity" and "useful quantum computation" are different metrics. SnowDrop tops out at 4-10 computational qubits, and any algorithm with real error correction needs orders of magnitude more physical qubits per logical qubit. So "fidelity on par with world-class systems" is an honest claim about individual operations — not a claim that this machine is solving problems classical computers can't.

Where this sits globally

Compared head-to-head on qubit count, it's not close: IBM already has chips with over a thousand physical qubits in its fleet, Google demonstrated the 105-qubit Willow chip below the error-correction threshold back in late 2024, and IonQ has dozens of algorithmic qubits on trapped-ion hardware with a completely different physics and different strengths. Formally, the Russian lineup is two orders of magnitude behind at launch.

But the qubit-count race isn't the only metric, and it's often not the most honest one — D-Wave has thousands of qubits, but that's an annealing architecture for a narrow class of optimization problems, not universal gate-based computing like SnowDrop. Realistically, the Russian team isn't competing with 2026-vintage IBM and Google flagships — it's roughly where those companies were five to seven years ago: "the first reliably working, non-one-off superconducting gate-model computer in the country." For the domestic market, that's a real milestone. For the global race, it's an entry, not a claim to leadership.

Who this is actually for

The buyer list isn't hidden: universities, research centers, and companies that need infrastructure to develop and test quantum algorithms — not consumer or even typical enterprise users. Before this announcement, the only way to access a Russian quantum coprocessor legally was through the Bauman Octillion cloud platform: since July 2025, it's run over 103,000 hybrid quantum-classical algorithms, with more than 9,000 cumulative hours of uptime. Selling hardware is the next step for anyone who's outgrown queue time on a shared cluster and needs their own installation for continuous experimentation.

Bauman's rector, Mikhail Gordin, framed the project's logic this way: an engineering university's job isn't just to create technology, but to bring it to practical use. After further equipping Quantum Park, the team claims a production capacity of 10-20 multi-qubit installations per year — not mass manufacturing in the usual sense, but hand-built units for specific customers, which is normal for hardware at this level.

The takeaway: an infrastructure story, not a consumer one

Strip away the "Russia vs. the world" headline effect, and what's left is a modest but genuinely interesting story: the country now has a reproducible product, tested across 103,000 runs, with an actual price tag on at least the base version — not a one-off prototype in a single lab. For a university or R&D team with 170+ million rubles and a real need to run quantum algorithms on dedicated hardware instead of queuing for cloud time, this is a reasonable purchase. For the market broadly, it's a signal that after years of cloud-only access, Russia's quantum program has moved into a phase where it's willing to sell a physical product, not just demo prototypes.

I wouldn't read this as "a quantum laptop in five years," though. The path from 10 research qubits to something that actually beats a classical computer on a real business problem is measured in decades worldwide, and Russia isn't an exception here.

Originally published at klukyanov.ru.

Shorter weekly write-ups (in Russian) — on Telegram.

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.

DEV Community: Kirill Lukyanov

Lunar Fasting: an intermittent fasting app that puts your Apple Health activity on the lunar calendar

Fasting intervals: which one to pick

Fasting without a "start" button

Why lunar days, not calendar dates

Calories from a photo

The main feature: your activity on the lunar calendar

A forecast for the lunar month

Coming in 1.1: Google Health

Free vs. Pro

Kimi K3, DeepSeek and GLM free from NVIDIA: I tested the claim and here is the catch

What NVIDIA gives away

The four models

The catch: phone verification

First request

My take

Listen to your coding agent instead of reading it: how I save my eyes

The agent writes more than I can read

Half one: SafeYourEye keeps the breaks

Half two: PromtsMaker gives the agent a voice

What it looks like on an exercise bike

Eyes or ears: what moved where

How to set up the same pair

What's next: read any reply with one key

Fitbit Air and iPhone: why your band's data gets lost on the way to Apple Health

Two "Health" apps that refuse to be friends

What gets lost on the way

Why it's hard to do right

Paid bridges on the App Store and what they cost

How I built my own bridge

What to do right now if you own a Google band

What's next

Which AI Subscription Should You Pick for a Task: a Benchmark Table (September 2026)

The lineup: six models, four subscriptions

Why you shouldn't take a launch table at face value

Independent rankings: a tie at the top

The full matrix: 6 models × 19 tests

What it means, task by task

Task → subscription cheat sheet

What I actually use

Yandex open-sourced an 80B model trained from scratch: what's inside and where it wins

The short version

80 billion parameters, three at work

Benchmarks: where it wins and where it doesn't

Can you run it locally?

Caveats

Best Ollama Models for Coding, Writing and Medicine (September 2026)

Rule 1: read the tag, not the name

Rule 2: specialisation beats size on its own turf

Rule 3: the benchmark is not your task

Coding

Agents: Meta is back, and that is the surprise of the month

Writing: the honest answer is still "not locally"

Medicine: the one area where a specialised model is mandatory

Retrieval: embeddings matter more than the generator

The table

What is deliberately missing

What I actually run

Running Flux locally on a Mac: install, commands and two models compared

Why keep a model on your own machine

Step 1. Build the engine

Step 2. Download the weights

The gotcha that costs you an evening

Step 3. The first picture

--cfg-scale stays at 1.0

--vae-on-cpu is the most expensive thing I know about this stack

How many steps you actually need

The second model: editing a finished frame

It preserves the scene, not the pixels

What it costs in time

Q4 vs Q6: are three gigabytes worth it

Cheat sheet

What I actually use it for

Local generation on a Mac: where it is actually free, and where it costs two hours per second

First, kill the CPU myth

Stills: works, and genuinely free

The 29x memory cliff

Video: three walls in a row

The CPU fallback, priced

Generation strangles your network

`--cfg-scale` stays at 1.0

`--vae-on-cpu` is the most expensive thing I know about this stack