The official release opened up the “whole-suite app API.” Web search, file parsing, speech — capabilities that until then existed only inside the App — now work from the API by declaring a parameter. The pitch line is “reproduce the complete DeepSeek App, 1:1.”

That same evening, DeepSeek Harness shipped v0.2.2-rc.3. It added exactly one thing: import the conversation history sitting in the DeepSeek App into your workspace and keep talking.

One side pushes capability out. The other pulls data in. Neither is big news alone; together they say something. The vendor is disassembling its own App while the community stitches its own history back together.

I ran both on my machine. Some numbers don’t match the docs.

First, What They Actually Opened

What got opened is really two layers: parameter switches, and standalone endpoints.

Layer one is switches. In the existing Messages, Responses and Chat Completions APIs, declare the tool and it works: deepseek_web_search handles web search and deep-thinking search, deepseek_read_url reads a link, and file input and model safety each get a parameter.

The key is one line of documentation: search and fetching both happen server-side, the client executes no tools.

That line decides how you use it. You don’t write your own scraper and wire it to the model; you send one request and the server walks the middle steps for you.

Layer two is standalone endpoints. Search, Fetch, OCR, ASR and TTS can each be called on their own, without going through a chat model. Take that route and you are the one assembling the workflow.

Together, the official positioning is “turn the parameters on and you have the App.” I checked how much of that holds up.

One Call, Three Searches on the Server

I tried the simplest possible request against the Responses API: ask when Kotlin 2.5.0-RC ships and what’s in it, answer in three sentences.

The request body had three fields: model deepseek-flash, tool deepseek_web_search, one line of input.

The response came back at 6,969 bytes in 4.2 seconds. Not one answer — five content blocks in sequence: reasoning, search call, reasoning, search call, answer.

The first search block says kind: "deep_search". The model issued three queries on its own, mixing Chinese and English. One asked about the release date and features in Chinese, one used site:kotlinlang.org to pin results to the official site, and one went straight for the release announcement page.

Those three queries brought back 16 sources, each with url, title, snippet, site_name and published_at. I counted: official kotlinlang.org doc pages sitting alongside reposts on third-party forums.

That’s the real cost of “the server walks it for you.” You say one sentence; it searches three times behind your back.

You Pay Per Tool Execution

One field deserves its own section: server_tool_use. This call returned tool_search 3, tool_fetch 0, tool_image_search 0. Three searches, no fetches, no reverse image search.

The same usage block carries input_tokens: 11799 (4,608 of them cache hits) and output_tokens: 761 (433 of them reasoning tokens).

Of those eleven thousand input tokens, the overwhelming majority is the content of those 16 sources, not your question.

So when the docs say “tool call fees are charged on top of token fees,” the thing being counted is server_tool_use. You write one line of tool declaration in your code, the bill grows three lines of search fees, and you don’t control how many times it searches.

Five Standalone Endpoints, Tried One by One

If your use case doesn’t need conversation, calling the standalone endpoints is cheaper. I ran the three I could verify locally.

TTS was the cleanest. Send a Chinese paragraph plus a voice_id, get a wav back in 2.09 seconds. The default voice stella returns 276,524 bytes, 5.76 seconds, 24kHz; switching to tide gives 261,164 bytes, 5.44 seconds. Same text, male voice 0.32 seconds shorter than female.

ASR closed the loop on that wav. 1.2 seconds to return, duration_ms: 5760, matching the 5.76 seconds afinfo measured locally.

The transcript has a trap, though. What I said was “多字段的 value class 在字节码里就是一个普通类，没有 box-impl” — a multi-field value class is just an ordinary class in bytecode, no box-impl. What came back was “多字段的Value Class在字节码里就是一个普通类，没有Box应用.”

box-impl came back as “Box应用” — Box app.

This isn’t an ASR-specific defect. Anyone dropping English technical terms into Chinese speech recognition hits it: the model hears the sound and guesses the closest Chinese word. Write code comments by voice and that error walks straight into the repo.

For OCR I used a cover image I’d made myself: 2.29 seconds, 481 input tokens for 131 output tokens. Layout like “36.0 字节 / 次” (36.0 bytes per call) and “0 / 2 迁移开关” (0 of 2 migration switches) — decimal points, slashes and all — came back accurate, right down to the middle-dot separator.

Harness Added Exactly One Thing

That same evening dsh v0.2.2-rc.3 landed, commit 38a6a5c, by imccyu and winewill.

Two changes: a new experimental “DeepSeek chat import” plugin, and a fix for in-app updates failing on the Windows desktop build.

The second is a plain bug fix, nothing to unpack. The first is worth discussing, because it pairs with the API released that day: the official demo supports importing past conversations, and dsh turned that into a plugin.

The plugin is an optional layer — the release notes state plainly that shipped profiles don’t include it. You mount it by hand:

- insert:  # appended to the end of the profile's patch layer
    - id: deepseek-chat-import
      name: '@deepseek-ai/dsh-deepseek-chat-import'

Usage: click the upload arrow next to “New session,” pick a deepseek_data-*.zip, then pick the workspace that should receive the conversations.

The Upgrade Hit a Wall

I upgraded my everyday web profile first. npm install -g @deepseek-ai/dsh@0.2.2-rc.3, it installed 0.2.2-rc.3, I restarted.

The startup log flooded a screen:

disabling profile plugin row "storage-domain": Plugin
@deepseek-ai/dsh-storage-domain@0.2.2-rc.1 is incompatible with dsh 0.2.2-rc.3

storage-domain, plugin-market, cua, ui-cua, tool-plugin-market, cua-provider-registry — all six disabled. Same reason every time: the profile has rc.1, the main package is rc.3, the versions don’t line up.

Then the chain reaction: storageDomain can’t start, so workspaceRegistry goes pending, session-controller follows it into pending, and the plugin I actually care about sits in the list waiting on workspaceRegistry.

Nothing was broken about the plugin. It was held up by upstream. This is the other face of the “Everything is a Plugin” philosophy: the finer the composition, the further one version mismatch cascades through the whole stack.

A Clean Profile and It Runs

Rather than touch the dependencies of the profile I use daily, I spun up a fresh one from the official template: dsh --profile chatimport --from-default-profile web --port 3081, a different port so it wouldn’t collide with the original.

The new profile carries just two bundles, @deepseek-ai/dsh-base and @deepseek-ai/dsh-web-app. Clean. Add that insert block, restart, and the log shows no disabling lines and nothing pending.

The UI gained a button. I dumped every button on the page through the accessibility tree; the second one is called Import DeepSeek chats, 38 pixels square, right next to New session.

So the plugin is alive. The question becomes what to feed it.

Import Test: Three, Two, One Skipped

I don’t have a real export package, so I reverse-engineered the structure from the zod schema in the plugin source and built one.

A valid export ZIP needs three things: manifest.json with export_format_version: 3, a chat_session_index.json listing sessions, and one chat_sessions/{id}.json per session. The session file holds a message tree, each message carrying id, parent_id, role, status and fragments.

I built three sessions: a plain Q&A, one with web search and multi-round reasoning, and one designed to test filtering.

In the first version I made “content filtered” mean message status FINISHED with a CONTENT_FILTER fragment stuffed in. The result dialog said, flatly: Imported 3 sessions into the smoke-test-connectivity-f0b666d1b2bb workspace.

All three came through, including the one that should have been dropped. I went into the conversion source and found the check reads exactly one field: if (reply?.status === 'CONTENT_FILTER') then continue, with the counter increment as its own separate step.

The filter looks at the message’s own status, not the fragment type. I fixed that and rebuilt the package; the second dialog said Imported 2 sessions, followed by 1 conversation could not be imported.

Two in, one skipped. That matches the docs: “a question whose answer was withdrawn by content filtering is omitted along with the answer, and sessions with no other turn are not imported.”

Which confirmed something else: import the same package twice and the sessions duplicate. My workspace sidebar now shows five sessions, with the Kotlin one and the Flutter one each having two copies, and the filtered one still single. The importer keeps no record of what it has already imported.

Import Writes Locally; Only Chatting Touches the Model

Opening an imported session, the history is complete: my questions, my answers, the timestamps, rendered as 11/10 17:00, with 1 turns 1 steps at the bottom.

Then I sent a new question straight into that session to see whether it could keep talking. I got a red line: This turn failed, saying the deepseek-official provider route has no API key, to write one through the credentials service or export one in the startup environment, with a MISSING_CREDENTIAL code at the end.

The new profile has no credentials configured — that’s my environment. But the error itself proves something: import never called the model at any point, or it would have stalled here first.

The red “Injected context” line in the UI says the same thing: the history is already in context, there’s just nobody reading it. In the screenshot, that failed turn pushed the bottom stats to 2 turns 2 steps.

Two Roads, Two Different Problems

Put the two side by side and they answer different questions.

The whole-suite API answers “how do I build something that behaves like the DeepSeek App.” It wraps the dirty work — search, parsing, speech — and sells it to you: token fees plus tool fees, in exchange for not building your own retrieval and parsing.

Chat import answers “how do I stop losing what I’ve already talked through.” It has nothing to do with the model — pure local read and write, splitting a ZIP into session files and writing them into a workspace.

On my machine the first produces a result in four seconds, the second puts three sessions into the sidebar in one. But the first asks you to trust that its server searched three times on your behalf, and the second asks you to accept that importing the same package five times will write five copies.

Two things shipped the same day: one pushing capability out, one pulling history in. If you have to pick one to start with, it comes down to whether you’re short on capability or short on memory.

The JVM knows nothing about any of it. After compilation it only sees classes, methods, fields and bytecode instructions.

So I compiled a dozen of the common ones, one at a time, and opened them with javap to see what they turn into. The sorting came out clean: three are genuinely free, a few only save typing, and a few quietly charge you.

Start with the cleanest one

s?.length ?: -1, a safe call plus an elvis fallback.

Compiled, it is 8 instructions:

aload reads the parameter, dup copies it, ifnull jumps to the branch, call length, goto to merge, pop the leftover top of stack, push -1, return.

No object allocation, no extra function call, no try catch. It is an ifnull jump.

That is true zero cost. The bytecode from ?. and from hand-writing if (s != null) s.length else -1 is essentially identical.

But !! charges you

Same goal, convincing the compiler to trust me: s!!.length compiles to 5 instructions with an Intrinsics.checkNotNull static call wedged in the middle.

Every time execution reaches !!, it really does run a null check, and throws NullPointerException when that fails.

This is not a compile-time guarantee. It is one function call at runtime.

Ordinary parameters are more interesting. I wrote fun checked(s: String): Int = s.length, a non-null parameter type and a body that does nothing at all. Compiled, 6 instructions, and the first thing it does is Intrinsics.checkNotNullParameter(s, "s").

Which means the public entry point of every Kotlin function with a non-null parameter checks it first. !! is an explicit check, a non-null parameter is an implicit one, and in bytecode they are the same category of thing.

Extension functions and infix calls: pure rewriting

fun String.shout(): String compiles to a static method shout(String), with the receiver becoming the first parameter.

infix fun Int.plus2(other: Int) is also a static method, plus2(int, int).

operator fun plus(o: Op) is just an ordinary member method, plus(Op).

None of the three leaves a trace in bytecode saying it used to be syntactic sugar. The call site is a plain invokestatic or invokevirtual.

Zero cost, because they never changed the program’s structure. They are a different way of writing down the same method.

when compiles to tableswitch

when (n) { 0 -> ...; 1 -> ...; 2 -> ...; else -> ... } compiles to tableswitch, as long as the branch values are consecutive integers.

That is the fastest branch the JVM has: one table lookup and jump, no comparing cases in sequence.

Sparse values degrade to lookupswitch, which is a binary search underneath. Non-constant branches turn into a chain of if checks.

So when’s performance is entirely a function of which values you write, and the compiler guarantees nothing. Consecutive constants get you tableswitch. Anything else and it downgrades.

data class: ten methods

One data class Point(val x: Int, val y: Int) produces a 2111-byte class file and ten things:

two fields, a constructor, two getters, component1, component2, copy, copy$default, toString, hashCode, equals.

You wrote one line of source. The bytecode holds an entire class.

Two of those ten exist purely for destructuring. val (a, b) = point compiles to two componentN calls.

copy$default exists to serve copy with default arguments. Its signature is (Point, int, int, int, Object), where the third int is a bitmask telling it which parameters took their defaults.

object: one static field

object Singleton compiles to:

a public static final Singleton INSTANCE field, a private constructor, and a static initializer block.

A singleton is a class that locks itself down and holds its only instance in a static field. Writing Singleton.name in Kotlin becomes getstatic INSTANCE plus one method call in bytecode. No reflection, none of the lazy-initialization machinery.

Default parameters: one more method

fun greet(name: String, title: String = "engineer") generates greet(String, String) and also greet$default(String, String, int, Object).

That int is a bitmask: bit n set means parameter n took its default. The Object is a marker slot reserved for inline classes.

The call site decides what to do. Pass everything and it takes the normal method; miss one and it jumps to $default, which fills the gap and delegates.

I timed passing all of them against missing one, 5,000,000 iterations each, both landing between 8 and 9 milliseconds, the same as an ordinary five-parameter function. That overhead does not measure.

lazy delegation: one field plus one class

val text: String by lazy { ... } compiles to 1416 bytes:

a private final kotlin.Lazy text$delegate field, a getText() method, and a static method to hold the lambda.

Every read of text goes through getText(), which delegates to Lazy.getValue(). So a lazy property access always costs one more virtual call than a plain property.

A counterintuitive observation while I was in there. The docs list three LazyThreadSafetyMode values; I ran SYNCHRONIZED, PUBLICATION and NONE 5,000,000 times each, and differences like 5 milliseconds against 36 milliseconds flip from run to run. I could not measure a stable conclusion. At that level JIT behavior matters more than the mode itself.

So do not pick a mode off a blog post unless you have actually measured it on your own workload.

inline: saves objects, costs code

inline is the most interesting of the set because it cuts both ways: it removes one call and duplicates the code several times over.

I wrote an inline fun inlined(x: Int) and a plain function with an identical body, each called from six functions.

In the plain version the call sites hold nothing but invokestatic, and the body exists once in the bytecode.

In the inline version all six call sites have the body pasted in. Every useX method shows imul and ishl directly.

That is the essence of inline: one function call and a possible lambda object removed, paid for in duplicated code.

But how much does it actually save. I measured 1,000,000 higher-order calls with a lambda: the inline version allocates 0 B, the plain version 9,872 B.

9,872 out of a million is 0.01 B per call, 0.03% of that 36 B object.

Because JIT escape-analyzed the lambda away. On a modern JVM, the object overhead of a non-inline higher-order function basically does not exist.

The ironic part is that my inline example emitted a warning at compile time. The official docs say inline only matters for function-type parameters, and the compiler threw that sentence straight into the build output:

expected performance impact from inlining is insignificant. Inlining works best for functions with parameters of function types.

The compiler is telling you your inline is useless, and only worth it when a parameter is a function type.

The compiler talking you out of abusing inline is more honest than most technical blogs.

String templates still use StringBuilder

One left, and it was the most surprising.

"$name is $age years old, ${age * 2}" compiles to new StringBuilder with five appends and a toString.

Java has been on invokedynamic plus String Concat Factory since 9. Kotlin is a beat behind on this one.

I assumed it was a flag problem, so I tried -Xstring-concat=indy-with-constants, and the compiler warned: this flag does nothing with JVM target 1.8.

Because Kotlin’s default jvmTarget is 1.8, class file major version 52.

I tried all four combinations: target 1.8 is StringBuilder whether or not you pass the flag; target 21 needs no flag and becomes invokedynamic on its own, major version 65.

The deciding factor is jvmTarget, not the flag.

So which implementation your string templates get depends on what jvmTarget says in your build script. Most Android projects are still on 1.8 or 11, which means StringBuilder.

The tiers, after taking it apart

Once it is laid out, three tiers.

Genuinely free: safe calls, extension functions, infix calls, operator overloading. In bytecode they are ordinary method calls and jumps, not one instruction extra.

More code, no more time: data class, object, default parameters, when. The generated output looks alarming, but runtime behavior matches hand-written code.

Real cost: !! and the runtime check on every non-null parameter, lazy’s delegated call on every access, inline’s code duplication, and StringBuilder for string templates at a low jvmTarget.

And one more tier, “depends on config”: which string template implementation you get changes the moment you edit one line of jvmTarget.

The feeling I came away with is that “syntactic sugar” makes people assume the compiler will sort it out anyway. The compiler just faithfully translates what you wrote into instructions, and whether that is good or bad is entirely a question of what you wrote.

Last month, when Beta2 came out, I wrote up a changelog round covering release formats and a few changed defaults. This time I wanted to measure something I skipped last time: does it actually save memory?

After installing the compiler, the first thing I did was not write a demo from the docs. It was run javap and read what the compiler emitted.

The conclusion first: in the bytecode it is an ordinary class. Not a trace of inline anywhere.

First, confirm what the compiler accepts

Download kotlin-compiler-2.5.0-RC.zip, unzip it, and the version is kotlinc-jvm 2.5.0-RC, running on JRE 21.0.10.

The first step hit a wall. Write a value class VComplex(val real: Double, val imaginary: Double) and the compiler refuses:

the feature “full value classes” is experimental and should be enabled explicitly.

You need -Xfull-value-classes before it accepts anything. The docs say the feature is Experimental and must be enabled explicitly. All true, it just does not tell you what you will see once it is enabled.

Bytecode is more honest than the docs

I wrote two controls. One data class DComplex(real, imaginary), one value class VComplex(real, imaginary). Same fields, same types.

javap -p on VComplex: a private final double real, a private final double imaginary, a two-argument constructor, two getters, one toString.

That is all. No box-impl, no unbox-impl, and no packing of the two doubles into some other representation.

Now the single-field @JvmInline value class VUserId(val raw: Long), which looks completely different: constructor-impl(long), box-impl(long), unbox-impl(), hashCode-impl(long), equals-impl(long, Object), and every one of those methods takes a primitive long.

That is what inline means. The multi-field one is not it.

So does it save anything?

I measured allocation with ThreadMXBean.getCurrentThreadAllocatedBytes, 1,000,000 runs, looking at average bytes per run.

First round, reading fields off local variables: VComplex 9.3 B, DComplex 10.4 B. Both numbers are far below what an object should occupy, because JIT did scalar replacement and the object was never created at all.

That measurement does not hold up. So I moved them into an ArrayList, forcing the objects to exist.

VComplex into a List: 36.0 B per run. DComplex into a List: 36.0 B per run.

Identical. Zero bytes apart.

The 36 is easy enough to explain: a 16-byte object header plus 16 bytes for the two doubles. A clean integer.

So on the JVM, a multi-field value class saves not a single byte. The only size difference from the data class is in the class file: VComplex.class is 1,760 bytes, DComplex.class is 2,216 bytes, 21% smaller, and what is missing is copy and componentN.

Not even @JvmInline escapes

I measured the single-field control while I was at it. VUserId into a List: 28.0 B. DUserId as well: 28.0 B.

Again not a byte apart.

The reason is plain: once it goes into a generic container it has to be boxed, and once boxed it is an object, indistinguishable from an ordinary class.

So the claim that an inline value class is a zero-cost abstraction holds only at the layer of passing arguments directly. Put it inside a List, a Map, an Array<Any>, and the cost comes straight back.

This is not a 2.5 problem, it is the old rule of JVM generic erasure. It is just that a lot of people reach for value classes as a memory-saving tool.

What it saves is semantics

So what is a multi-field value class for?

It is for the idea that two instances with identical contents should not differ by identity. A data class == compares contents, but two instances are still two objects, each with its own reference, its own lock, its own place on the heap.

A value class removes that identity. You cannot rely on reference equality, which means you cannot use it as a lock and cannot use object identity as a cache key.

The price is no copy() and no componentN(). The docs mention copy vars coming later. Not yet.

I did measure deduplication and equals: setOf(a, b).size is 1 both ways, and toString prints VComplex(real=1.0, imaginary=2.0), the same as the data class.

So what it gives you is a constraint, not performance.

Where it really differs from a data class

I measured the equals edge cases too, because that is where surprises like to hide.

NaN against NaN: true for VComplex, true for DComplex. Negative zero against positive zero: false on both sides. Same behaviour as a data class, all of it following Double.compare semantics. No extra surprise, no extra trap.

Inheritance does have something new. A value class can implement a sealed interface, and a value object can join in:

sealed interface Resp
value class Found(val id: Int) : Resp
value object Unknown : Resp

Unknown::class.java.name prints Unknown, and the compiler resolves Found(1) is Resp to true outright, with a warning that the check is always true. Because a value class’s inheritance is fixed at compile time, there is no second possibility at runtime.

So the substantive differences from a data class are three: no copy(), no componentN(), no object identity.

The first two are subtractions. The third is the reason it exists.

Destructuring has a silent trap

The RC made only-syntax the default mode for name-based destructuring. I wrote about the trap last time, so here is harder evidence.

data class User(val username: String, val email: String), an instance of User("alice", "alice@example.com"), and then one line: val (email, username) = user.

The variable names and the property names are swapped. This is extremely common in production code. You type by position, not by name.

Default mode prints: email is alice, username is alice@example.com. Completely transposed.

Add -Xname-based-destructuring=complete, recompile the same source, not one character changed, and it prints: email is alice@example.com, username is alice.

Both modes compile. Neither reports an error. The runtime results are exact opposites.

There is a name-mismatch mode in between that does not change behaviour, only warns, and its exact wording is variable name ’email’ differs from accessed property name ‘username’, this code will change its meaning.

It does not say this is a bug. It says the meaning of this code will change. If you want to clear the mines early, this is the only mode you can use.

The migration flags are still missing in RC

The docs, in the migration section, say: starting with 2.5.20, unmarked single-field value classes produce a warning, 2.6 or 2.7 promotes that to an error, and until then you can use -Xinline-value-class-migration=warning and strict to prepare.

I tried exactly that. The compiler replied: flag is not supported by this version of the compiler. Neither one is accepted.

All three destructuring modes work, not one of the two migration flags exists. The docs are not wrong, they describe a state that is coming, but written on the RC page they read as available now.

Verify it yourself in two minutes

Do not take my word for it. The commands are below.

Download and unzip the compiler, write a minimal comparison file, compile with the flag, then open both classes with javap. Look for the -impl suffix and you know at a glance whether it is inline.

The allocation measurement is simple too, ThreadMXBean in two lines:

val mx = ManagementFactory.getThreadMXBean() as com.sun.management.ThreadMXBean
val before = mx.getCurrentThreadAllocatedBytes()
// 这里跑你的循环
val after = mx.getCurrentThreadAllocatedBytes()
println((after - before) / 循环次数)

One thing you have to watch: the local-variable scenario measures nothing. JIT eliminates the object entirely and both numbers come out at a dozen bytes or so. Put it in a collection and measure that, because that is what it looks like when the object is really created.

I fell into this on my first attempt and nearly wrote down the wrong conclusion, that both sides save memory.

What you can do before upgrading

Three things.

First, hang -Xname-based-destructuring=name-mismatch on your build and run it once. Zero behaviour change, pure checking, and the warnings it produces are the line numbers whose meaning will change later.

Second, if you are using multi-field value classes, work out whether you are after memory or after semantics. If it is memory, the measurements say you will not get it.

Third, do not put value classes on your list of performance optimizations. True zero cost only holds for single-field direct argument passing, and you have to write @JvmInline explicitly, because from 2.5 on the words value class no longer automatically mean inline.

As for full value classes themselves: experimental, gone the moment the flag is off, and production use will have to wait.

The one thing I most want to say after all this measuring: a type with value in its name is still an object on the JVM. If you want to save memory, you still have to look at where your data structures actually live.

I went to try it that same afternoon.

I got stuck on step one: the latest ffigen would not install in my project.

Nobody at Flutter got anything wrong. Out of preview means the approach is mature. Whether the Flutter version on my machine can install the newest package is a separate question. Stack the two together, though, and you get the first wall everyone hits on day one.

Stable in the announcement, errors at install

My machine runs Flutter 3.41.4 and Dart 3.11.1.

I put ffigen 23.0.0 in the pubspec and pub get failed outright, dumping a long dependency derivation: anything past ffigen 22 depends on code_assets, code_assets depends on hooks, hooks depends on record_use, record_use wants meta 1.19.0 or newer, and the Flutter SDK pins meta at 1.17.0. Six packages in a chain, broken at the fourth link, a full screen of errors, and the downgrade suggestion only on the last line.

That is where the chain snaps. The suggestion: install ffigen 21.

I changed the version to 21 and it went through immediately.

The version page on pub.dev lists 23.0.0, published October 6. Installable and newest are two different things.

So the first question is not how to use it. It is whether you can install it at all.

So drop a version

Whether ffigen 21 covers everything the announcement describes, I cannot tell from a version number. The official write-up is about the design trade-offs of the approach; nowhere does it state a minimum version.

But what I wanted to measure needs neither JNIgen nor Obj-C bindings. I wanted the most basic case there is: one piece of C, bound twice, one per side, to see which is less work.

C is enough. C is the only intersection where both sides agree.

Start with C both sides can use

I wrote 34 lines of C plus a 17-line header: four functions, deliberately in four different data shapes.

One is a pure computation: take an array, return the sum. This is the one that measures call overhead.

One returns a struct, and the struct carries a 64-byte inline char array. This is the shape that breaks things.

One writes a string into a buffer the caller hands over. Who allocates memory is exactly where the two sides disagree.

One returns a const char pointer.

All four ran at the C layer first, printing sum=10, value=-7 negative, filled:42, interop-lab 1.0. After both sides were bound, they had to reproduce that same set of values, not one character off.

Flutter: one yaml gives you every binding

On the Flutter side I wrote 15 lines of config and 34 lines of calling code.

The config is a single yaml: where the header is, which dart file to write, which functions and which structs to include.

It ran in 0.76 s and produced 457 lines of Dart.

Then dart run, and all four calls came back correct.

One detail here is worth stopping on.

Of those 457 lines, only 23 have anything to do with my interface. The other 434 are fallout from the Darwin system headers: my header includes stdint.h, ffigen expands all the way down, and out come pthread, mbstate_t and a long tail of internal structures they drag in.

Readable. Not much use.

KMP: a four-line def plus one task

The KMP side takes three things.

A def file, four lines: header path, compiler options, linker options, package name.

A gradle config, twenty-two lines: define the macosArm64 target, create the cinterop, point it at the def file.

And four expect declarations in commonMain with four matching actual implementations in macosArm64Main, forty-two lines.

cinterop generates in 1.4 s. Linking the executable takes 2.8 s in debug and 5.7 s in release.

The output matched the C layer and the Dart side exactly.

Four functions, three implementations, one set of outputs. Until that lines up, comparing anything else is meaningless. If the values do not even agree, timing the builds is a waste of time.

Build: KMP is four times slower and ten times smaller

Generating bindings: Flutter 0.76 s, KMP 1.4 s.

Compiling to something runnable: Dart AOT 1.3 s, KMP release 5.7 s. KMP is more than four times slower.

The artifacts flip it. The executable Dart compiles is 5.3 MB; the KMP kexe is 532 KB.

Ten times. Not because one is better optimized, but because of whether the runtime ships inside. The Dart binary carries the entire Dart runtime; KMP carries only the parts it uses.

The KMP debug build is 1.3 MB, also small, but that is because nothing was optimized, not because it is elegantly compact.

Runtime: even on plain calls, wide apart on structs

Twenty thousand runs each, averaged.

Plain function calls: Dart 0.095us, KMP 0.102us, a 7% gap that is basically noise. Struct returns: Dart 0.146us, KMP 0.349us, a 2.4x gap.

All four call shapes in one pass: Dart 56us, KMP 129us.

KMP starts faster, 22 ms across three runs. Dart gave 25, 25, 29.

So the gap is not global. It only shows up in a particular shape: pass an array, pass a pointer, take a string, and the two are equally fast. Make it return a struct by value and Kotlin pays for one extra CValue copy.

A debug build nearly made me write the wrong conclusion

I nearly got this wrong.

My first KMP measurement used a debug build. Struct returns came in at 9.817us against Dart’s 0.146us on the same case, and my draft already said “67 times slower.”

Then I thought about it: debug does not optimize, so holding it against AOT is not a valid comparison. I rebuilt in release and the same case dropped to 0.349us.

A 28x gap, all of it hanging on one optimization flag.

Had I published that, the conclusion would have come out exactly backwards, and it would have looked very convincing.

Five pitfalls against five

Five on the Flutter side.

One: the latest ffigen will not install, pinned out by the meta version, so you fall back to 21.

Two: write the entry-points in the config as a relative path and ffigen does not complain — it silently emits an empty bindings file. I saw a 229 B output at first and assumed my config was wrong. Absolute paths fixed it.

Three: for the inline char array inside a struct, ffigen generates an Array type with no cast method, so pulling the string out means reading it byte by byte.

Four: Char and Utf8 in the ffi package are two different extension types, and you have to convert back and forth between them.

Five: 434 of those 457 generated lines have nothing to do with you.

Five on the KMP side too.

One: on a first build the cinterop and compile tasks collide, so the first compile always fails with symbols not found. The second one works.

Two: the whole file has to opt in to ExperimentalForeignApi, and one annotation at the top of the file beats marking each method.

Three: ByteVar and IntVar live in kotlinx.cinterop, not in platform.posix. My first version imported them from posix and everything went red.

Four: a struct returned by value is a CValue in Kotlin/Native. You cannot touch its fields directly; you need useContents.

Five: after linking, the run fails because dyld cannot find the dylib. You need DYLD_LIBRARY_PATH, or an rpath of your own.

How the two sets of pitfalls differ

Same count, different nature.

Two of the Flutter five are silent: an empty bindings file raises nothing, and the version wall only stops you once, at pub get. You finish the code, it does not run, and you are left guessing what came out empty. All five KMP pitfalls are compile errors. You cannot dodge any of them, but you do not have to guess either: the errors are loud, and loud errors are faster to fix. The difference comes from when each side resolves its binding, one looking up symbols at runtime, the other fixing them at link time.

If what frightens you is a program that raises nothing and returns the wrong answer, the Flutter pitfalls hurt more. If what you dread is churning through builds, KMP costs you more.

Which one to pick

One target, inside the Apple ecosystem: KMP’s cinterop is less work. Bindings are fixed at compile time, the artifact is ten times smaller, and runtime cost is no worse.

Go cross-platform, especially to Android, Windows or JS, and the cinterop path ends. It exists only on targets Kotlin/Native supports; the moment you land on the JVM you are on the JNI stack instead.

ffigen, by contrast, is general: the same dylib, so or dll, only the load path changes with the platform.

This is the one thing I most want to say after all of it: these two are not substitutes at the same layer. cinterop is a compiler capability of Kotlin/Native; ffigen is a cross-platform binding generator. Racing them on speed is beside the point. What you are comparing is which path your project’s shape leaves open.

As for that version wall, the day you want to try the newest ffigen, check your Flutter version first. Do not write the pubspec and only then discover it will not install, the way I did.

I went to upgrade that same night. npm did not have that version at all.

Three places, three version numbers

GitHub Releases had dsh-v0.2.2-rc.2, published at 11:33 on the 11th. I tried to install it and npm returned notarget.

A quick look at dist-tags: both latest and next still pointed at 0.2.2-rc.1.

The desktop app was older still, sitting on 0.2.1-rc.2. So my machine was holding three version numbers at once and none of them was rc.2.

That is not a DeepSeek Harness flaw, every release process behaves this way. But it decides when you can actually use a new feature: either wait for npm to catch up, or switch the desktop app to the dev update channel, which is itself something rc.2 introduced.

So I reproduced it myself

Since I could not install it, I reproduced what DeepSeek Harness does on my own machine.

Worktrees, comparing by branch, slicing by file type: all of that is git commands underneath and has nothing to do with the client. I used my own repository, 21,711 files and 60,037 commits, as the target, with a 50-file repository alongside as a control.

Starting with the slowest step: creating a worktree.

Small repository: 32 milliseconds, three runs at 31, 32, 32.

Large repository: 1.5 seconds, three runs at 1.47, 1.49, 1.51. Rock steady. A 46x gap.

The checked-out worktree occupies 275 MB, but .git is shared, so the 840 MB repository was not copied again. That design saves a lot of disk.

1.5 seconds is not long, but if an agent creates a worktree on every edit, with network round trips, disk jitter and a pile of invisible waiting mixed in, that 1.5 seconds becomes a bet that could time out at any moment. The release notes say “relaxed the wait time for creating worktrees in large repositories,” and this 1.5 seconds is what that refers to.

Three review dimensions, all in milliseconds

I made two rounds of changes inside the worktree to simulate an agent at work: 40 files in the first round, 240 in the second, totaling 311 files and 28,458 lines against the main branch.

Then I compared along the three dimensions it describes.

Stats by branch: 65 milliseconds. Full body: 75. Grouped by file type: 29. Log by commit: 26.

All four are under a hundred milliseconds. Nothing at the git layer is slow.

Here is the counterintuitive part. A 28,458-line, 1.27 MB diff takes git only 75 milliseconds to compute. I expected it to dominate and it turned out to be the fastest thing in the room.

Pick the wrong baseline and you review nothing

I stepped on something here worth writing down.

My first comparison used git diff main...HEAD. Three dots means comparing against the merge base of two branches. It printed zero files.

The reason is simple: local main on that repository was far behind, so HEAD was itself an ancestor of main. The merge base resolved to HEAD, and comparing a commit against itself is of course empty.

Switching to origin/main...HEAD immediately gave 311 files.

Same repository, same branch, only the baseline changed, and it went from 0 to 311 files.

So the thing to be careful about with review-by-branch is not whether diff is fast, it is what the diff is comparing against. If the agent’s branch was cut from an old baseline, you will see considerably less than was actually changed, and nothing will warn you.

Three dots compare merge bases, two dots compare endpoints. That distinction rarely matters until review is automated, at which point it becomes the difference between seeing the change and not seeing it at all.

How to read those 28,458 lines

Since git is not slow, the slowness must be elsewhere. Split the diff by extension and the answer surfaces.

Python: 187 files, 12,468 lines, 43%. JSON: 52 files, 5,690 lines, 20%. TypeScript: 46 files, 2,647 lines. TSX: 12 files, 1,526 lines.

The interesting part is those 5,690 JSON lines. Lock files, contract snapshots, config exports, a fifth of the total line count, and under five percent of it needs to be read line by line.

The value of review-by-file-type is not tidier categorization. It is having a principled reason to skip an entire 5,690-line folder.

What a worktree saves is not disk

I assumed worktrees would eat disk space. Measured, that worry was unfounded.

Against 21,711 files and an 840 MB .git, the worktree occupies only 275 MB, because .git is shared and only the working tree gets copied out.

What those 275 MB buy is isolation: one repository can host several worktrees, each on a different branch, without interfering. Agent A edits code on feat-a while agent B edits elsewhere on feat-b, and each side has its own working tree and index.

A sandbox or a full repository clone costs you 840 MB of disk plus tens of seconds of copying. A worktree costs 1.5 seconds, and throws in branch isolation for free.

That is also why review is built on top of worktrees. The branch is there, the commits are there, the files are there, and whichever dimension you slice by, the raw material is already in place.

The bottleneck is context, not tooling

Put every stage’s number side by side and the conclusion is clear.

Creating a worktree: 1.5 seconds. Producing the diff: 75 milliseconds.

Hand that diff to a model and it is 1,268,059 characters, roughly 300,000 tokens.

What is 300,000 tokens? Mainstream models now carry context windows around 200,000, so this single change does not fit, before counting repository structure, the task description and your own question.

So when rc.2 says “reduced jank when viewing large changes,” what it is janking on is not git. It is the layer that renders this pile, feeds it to a model and puts it in front of a human. No amount of optimizing those millisecond figures helps, because the real ceiling is here.

Review by file type, by commit, by branch: three paths that are three ways of cutting. Cut it down far enough and only then can a model finish reading.

The one I could not test

rc.2 added two more things: named and multi-level SubAgent collaboration, and AgentTeam that can be enabled per session with shared members and a task panel.

I cannot reproduce that locally, because it is not a git-layer concern, it is orchestration. And rc.2 is not installable from npm, so all I have is rc.1, and running that would not show rc.2 behavior.

So I only write what I verified. That one is for people who can actually get their hands on it.

What you can do now

If your agent already works on branches, two things are worth changing today. First, give the worktree directory a fast disk. Most of that 1.5 seconds is disk I/O, and a spinning disk or a network volume makes it worse.

Second, read the stats before the body. 312 lines versus 28,458 is a 90x difference, and reading the former first can filter out half the files you do not need to open.

As for DeepSeek Harness rc.2, it is a matter of waiting for npm. Once you have it, the first thing worth doing is running worktree creation against your largest repository to see whether your machine takes 1.5 seconds or 15.

That number decides whether you let it branch freely, and whether your pipeline can run several agents editing the same codebase in parallel. A 1.5-versus-15-second difference on one machine ends up being the difference between “three agents at once” and “one at a time,” two entirely different architectural choices.

1.13.0-beta02 fixed it. Released November 4, 2026, with one line of release notes: Stroke(join = Round) and Stroke(miter = 0f) are no longer ignored.

I verified it locally, rendering a set of images with each version and comparing them pixel by pixel.

How to reproduce it first

You do not need to open a window. Compose desktop has ImageComposeScene: give it a size and a density, render the Compose tree into an Image, encode it as PNG.

A 360×300 canvas at density 2 produces a 720×600 image, enough to see the corners clearly.

Only two things change between runs: the dependency version, and the Stroke parameters.

Same code, two shapes

This first group is join = Round, width 30, with rounded caps as well.

On the left all three corners are sharp, with small spikes on top. On the right they are round and the spikes are gone.

The second group is miter = 0f, drawn as an acute-angled V on purpose. Left keeps the long spike, right gets cut flat.

By Skia’s rules, a miter limit of 0 means no spike at all: every join falls back to a bevel. In 1.12.2 that 0 was written for nothing.

Numbers are harder than pictures

I diffed the two images within each version against each other, then diffed corresponding images across versions.

In 1.12.2, the join=Round and join=Miter images are pixel-identical, identical in PNG byte count too, both 8,905 bytes, hashes matching character for character.

miter=0f and miter=4f are likewise identical, both 4,176 bytes.

Under 1.13.0-beta02, the same two comparisons differ by 1,619 pixels and 414 pixels respectively. The full image is 108,000 pixels, so the first is 1.5%.

All the difference sits at the tips of three corners, the magenta patches in the figure above.

Root cause: a setter that never runs

Compose’s Paint is a wrapper around Skia’s Paint. The properties look like this:

strokeJoin has a custom setter that writes through to the Skia copy on assignment. But property initialization does not go through setters. It only fills the Kotlin field.

So the wrapper says the default is Round while Skia actually holds Miter. The two sides diverge.

What makes it fatal is the next step. During drawing, before assignment there is a check: if the value equals the current field, skip. You write join = Round, the field already holds Round, the check passes, the setter is never called, and Skia never learns you changed anything.

miter = 0f is the same story. The field default is already 0f.

A side note on filterQuality: it has no setter at all, just a plain field, so changing it does not notify Skia either. This wrapper has more than one field like that. The ones that do not affect shape simply go unnoticed.

Tim Haywood filed the issue on YouTrack three months ago, CMP-10688, titled “incorrectly renders StrokeJoin.Round as Miter”. He laid out the root cause, the Skia source location, potential fixes, and even proposed deleting the Kotlin field and proxying directly to Skia.

Ivan Matkov fixed it. The PR is compose-multiplatform-core #3528, merged into release/1.13 on October 26, reviewed twice. Three months from issue to merge.

The fix is correcting the defaults

The PR is surprisingly small: change three defaults so they match Android.

strokeJoin from Round to Miter, strokeMiterLimit from 0f to 4f, filterQuality from Medium to Low.

After that, the wrapper’s field and Skia’s actual state agree. You write Round against a field holding Miter, the check fails, the setter runs normally, and the parameter goes through.

So this is not a drawing fix. It is reconciling books that were reporting the wrong numbers.

The control group’s zero says nothing else broke

My worry with a change at this level is that it drags something else off course. So I kept a control: join = Miter, compared across both versions.

Zero pixels differ. Not a single byte.

In 1.13.0-beta02 the round-versus-bevel changes land only on the affected path.

Why it took so long to be seen

I suspect three reasons stacked up.

First, the default join is already Miter. Most charts, icons and progress bars never pass this parameter. The shape comes out right, so nobody digs.

Second, where Round is passed explicitly, the result is merely “not round enough,” not something loud like a crash. A designer says “this corner looks a bit sharp,” and nine engineers out of ten suspect their own path before they suspect the framework.

Third, it only happens off Android. The same code is correct on a real device and spiky in the desktop preview, and people readily attribute that to the preview tool’s rendering rather than a framework bug.

Only non-Android is affected

The diff lands in compose/ui/ui-skiko/src/nonAndroidMain/. Android goes through android.graphics.Paint, whose defaults were already Miter, 4f, Low.

Which gives this bug an ugly property: you cannot see it on an Android device, but the moment you run desktop or iOS, it deforms. People writing cross-platform UI see a different shape on their own machine than everyone else does.

The third default I could not measure

filterQuality changed from Medium to Low, which in theory affects sampling quality on image scaling. I took a 256-pixel checkerboard, scaled it down to 40 and to 80, and scaled an 8-pixel image up to 320.

Three comparisons, all zero pixels different.

The reason is that drawImage carries its own filterQuality parameter and does not route through Paint. This change only matters if you construct a Paint yourself to draw. So it is a latent hazard, not an observable symptom.

I looked for a path where it shows and found none, so I wrote it down as it is instead of inventing a scenario for it.

What you should do now

If your project is on 1.12 or earlier and you use parameters like join = Round or miter = 0f that appear to do nothing, you are affected.

Two paths. Upgrade to 1.13.0-beta02 and accept that it is still pre-release. Or rewrite the shape so it does not depend on those parameters, drawing a rounded polyline yourself.

To find out whether you are affected, you do not need to read code. Write an ImageComposeScene, render the same shape twice, once with join = Round and once with join = Miter, and diff the two PNGs. Zero pixels different means you are affected; a few thousand means you are fine. That method worked well for my images and should work for any drawing bug where a parameter appears not to take effect.

One thing to know before upgrading: in 1.13, Paint() gained a precondition and constructing one directly throws No Compose UI graphics implementation is registered. Either create a scene first or go through the normal drawing path. I hit this on my first run and only got going after rendering one image to warm things up.

As for how long this had been sitting in the wild, I do not know. The issue was filed three months ago, and the code may be older. Bugs where “the parameter is written correctly but does nothing” can only be seen with pixel-level comparison.

Jake Wharton did not want to wait. In August 2026 he published “Compose & kotlinx.html”, describing a setup he assembled at home with Molecule: run Compose on the server, produce an HTML string, push it over SSE, and let Idiomorph merge it into the DOM on the client.

One line of his stuck with me. Client frameworks can fix having stale content, but “you can also solve a leaking house by moving to a different house.” It is a sharp remark, and it lands: replacing the whole rendering stack usually costs far more than fixing the one pipe.

I rebuilt it to see how far this homemade approach goes. Along the way I checked one thing: on the same push, with one line of client code changed, does the text in the input box survive.

The conclusion first: the survival rate goes from 0% to 100%, and the entire difference is three default values.

His pipeline is four stages

The data source is a StateFlow. Molecule runs a @Composable function as a state machine, kotlinx.html renders the result into a string, SSE pushes it to the browser, and Idiomorph merges it on the client.

The key part is that the server does not distinguish between “first render” and “subsequent push.” The same userList(users) function is called for both the initial page and incremental updates.

I built mine on Kotlin 2.4.21, Ktor 3.6.1, kotlinx-html 0.12.0, Molecule 2.2.0, Compose runtime 1.12.2, running on JVM 21.

One function, two call sites

This is the most comfortable part of the whole thing.

What you save is not just the template engine.

Initial page: appendHTML().div { userList(users) }.

Push: moleculeFlow(Immediate) { val users by Store.users.collectAsState(); fragment(users) }.

Both sides call the same function. No template, no JSON-to-view mapping layer, no “the frontend has to implement this again” problem.

One change, both places take effect.

Who owns the text in the input box

This is what I most wanted to verify.

The page has one input box. It is not in the StateFlow, it is purely browser state. I typed a sentence into it, then triggered a push, and watched to see whether it was still alive.

The first attempt used content.innerHTML = html. The text was gone. The reason is simple: the whole content area is rebuilt, the input box is new, the value is empty, and the caret position and any uncommitted IME candidates go with it. That is the classic cost of overwrite-style updates, and the first problem every frontend framework has to solve.

Switching to Idiomorph, I first used morphStyle: 'innerHTML'. The page did not move at all. No error. It just did not move.

Changing it to outerHTML still did not preserve it. It took a while to find that there is an ignoreActiveValue option, and it is off by default.

With it on, the text survived. But only in one case.

It protects focus, not every field

I ran each combination three times. The results were blunt.

With innerHTML, the field is cleared three out of three times regardless of where focus is. Morph without ignoreActiveValue clears it three out of three. With the option on but focus already moved to a button, still three out of three cleared.

Only one case survives: focus sitting inside that input box.

The reasoning is not hard: Idiomorph protects the currently active element. Other inputs get overwritten by the server HTML, and that <input> on the server has no value attribute.

In other words, this setup defaults to “form state belongs to the server,” and only yields on the one cell the user is currently typing into.

Jake’s original text says “form fields that haven’t changed are preserved.” That holds in the “user is typing right now” scenario. Outside it, it does not.

Connection count equals render count

I added a counter on the server to see how many times a composition ran.

Idle it is 0 — nothing renders if nobody subscribes. Open ten persistent SSE connections and it becomes 10. Change state once and it becomes 20. Those three numbers are the part of this experiment I most want people to see.

What that means: every data change requires the server to run the composition function once per connection. Ten connections, ten runs. A hundred connections, a hundred runs.

A single connection receives a 1,903-byte payload, about 42% of the full page, plus 97 bytes per extra user row. The whole block is pushed with no diffing; diffing is delegated entirely to the browser.

Memory showed no measurable difference. The JVM baseline sits at 147 MB, and going to fifty connections only reached 149 MB, which buries the overhead. Real load testing would have to look at per-connection thread stacks and GC pressure.

Latency has no story here

Locally end-to-end, from clicking the button to the DOM being updated: inner mode ranged 30 to 107 ms, morph mode 18 to 138 ms.

The two ranges overlap. Neither is clearly faster.

That makes sense: both paths go through SSE, both repaint the DOM once, and the only difference is the merge strategy.

So do not expect this to buy you performance. It buys something else.

What he calls productionization is mostly “don’t do this”

Jake wrote three points at the end. Here is how I read them.

One long connection, not one per content block. The pushed payload needs an envelope saying which part of the page this update touches. Multiple blocks sharing one connection lets the server render only once.

Use SSE, not WebSocket. SSE can ride HTTP/2 multiplexing, event names and payload are naturally separate, which makes a convenient envelope. And when the connection drops the browser reconnects on its own, so you do not write backoff retry logic.

The third is the vaguest and the most important: whether the composition function runs inside the connection or outside it. The former means one per user, the latter means one shared by everyone. The former is simpler, the latter is cheaper.

My experiment was the former, which is why ten connections meant ten renders. Doing it his way means first deciding whose state it is.

Four traps, three of them silent

First, the Molecule 2.x API changed. launchMolecule is now an extension on CoroutineScope returning a StateFlow; to get a Flow you switch to moleculeFlow(mode) { }. Code from older docs will not compile, which is at least friendly.

Second, Ktor’s SSE requires an explicit install(SSE). Writing only sse("/path") {} compiles, then throws Application plugin SSE is not installed at startup, buried among dozens of lines of boot log.

Third, Idiomorph’s morphStyle fails silently when wrong. If the fragment carries its own outer div you must use outerHTML. Write innerHTML and the page freezes. You assume the push never arrived, but it did.

Fourth, ignoreActiveValue defaults to off. Without it, morph and innerHTML are indistinguishable in this scenario.

Three silent failures cost me an afternoon.

My verdict

The approach works.

But the conditions are narrow.

Low-traffic internal pages, a few dozen users, no need for a frontend framework, written end to end in Kotlin. It is far less trouble than pulling in React, and what the server returns is readable HTML that still shows content when the network is down. For internal tools the payoff is real.

But the moment you hit “many users online, state changing frequently,” the N-connections-N-renders problem becomes a real defect. Jake himself warns about it at the end: multiplex, switch to SSE, decide whether composition runs inside or outside the connection.

He also says something more important: this is “a starting point for productionization,” not the finish line.

What I took from those four traps is a more general rule: any default that fails silently deserves a documentation check before you start working. This stack has three. Other stacks have their own. Molecule’s entry point changed without an error, Ktor’s missing plugin blows up only at startup, and Idiomorph’s broken morphStyle just leaves the page still. Each one quieter than the last.

If you are building internal tools, it is worth half an hour to copy this setup. If you are building a customer-facing product page, let a frontend framework handle it.

The official answer is that we do not. Jetpack Compose still has no built-in material like this. If you want a piece of glass in your UI that refracts and shifts color with whatever is behind it, you either write the shader yourself or you find a library.

AndroidLiquidGlass is one of those libraries. It is by Kyant0 and has 4,509 stars. Android is in the name, but the description positions it as Compose Multiplatform, and the main branch is literally called kmp.

I kept coming back to one question: for a visual effect that leans this hard on platform graphics, how much of it actually survives the trip to another platform?

Glass on Android is drawn with AGSL shaders. On desktop it is Skia. Two completely different graphics stacks, and when a single library tries to feed both, the usual outcome is that it works well enough with the effect dialed down.

So I did the dumb thing. I built a minimal Compose Multiplatform desktop project on this machine, added the library, got glass to actually draw on macOS, then took the effects apart one at a time.

The conclusion first: it runs, and the result is not a compromise. The whole library is 2,550 lines and the cross-platform adaptation is only 280 of them. The reason is in the source, and I will get to it.

First, what this thing actually is

The repo is Kyant0/AndroidLiquidGlass, 4,509 stars, 364 forks, Apache-2.0. Android is in the name, but the description says Compose Multiplatform Liquid Glass effect, and the main branch is kmp.

The library’s proper name now is Backdrop, with Maven coordinates io.github.kyant0:backdrop, latest version 2.0.1, published on August 26.

One line in the README is worth copying down: the library contains no high-level components, you build those yourself. What it gives you are effect primitives, not a button that falls out of a single call.

It is small, too. The desktop jar is 136 KB, and together with the 46 KB shapes library it depends on, the whole thing is under two hundred KB.

Three steps for a minimal project

Create a Gradle project, install the Kotlin 2.4.10 and Compose Multiplatform 1.12.0 plugins, then add the dependency:

implementation("io.github.kyant0:backdrop:2.0.1")

The code follows a single pattern. Remember that whoever gets sampled and whoever does the sampling have to be paired:

Background content registers itself as a sampling source with Modifier.layerBackdrop(backdrop), and the panel in front pulls from it with Modifier.drawBackdrop(backdrop, shape, effects).

I used a Canvas with four color blocks and a fine grid as the background, put a panel with a 26dp corner radius in front of it, and stacked vibrancy, blur, and lens in the effects. Open the window and the glass is there.

What it looks like

I split the four effects and ran one per cell, same background, same panel, only the effect stack changing.

The first cell gets the shape and nothing else, and you can see the grid through the panel perfectly sharp. That detail matters, because it means the library is not baking a blurred image ahead of time. It samples whatever is behind it, every frame.

The second cell adds 8dp of blur and the grid smears into one mass. The third stacks vibrancy on top and the colors get noticeably more saturated. The fourth adds lens, and that ring of water drop refraction starts to appear at the panel edge.

As for what vibrancy actually is, the official docs are refreshingly blunt about it. It multiplies saturation by 1.5, which is equivalent to colorControls(saturation = 1.5f).

It actually gives you five kinds of backdrop

The Backdrops page in the docs lists five, with the use cases split quite finely.

rememberLayerBackdrop is the common one. It records the content of a Composable as a sampling source, and it has to be paired with layerBackdrop.

rememberCombinedBackdrop merges several backdrops into one, for cross-region sampling like tab bars and sliders. rememberCanvasBackdrop does not depend on layout coordinates, so you can draw your own content onto an empty backdrop. emptyBackdrop draws nothing at all.

There is also rememberBackdrop, which lets you draw directly with custom commands.

The reason for splitting them this finely is that you cannot build the advanced effects any other way. Take the glass on a bottom tab bar. It needs to sample the content of the entire page, not just the small patch behind itself, and that requires compositing first.

This is where I think the library is more solid than its peers. It does not hand you one API to wrap around things. It pulls apart every edge of the sampling problem and hands those to you.

One gap you have to fill yourself

My first version ran on a light background and the panel came out almost white, with the text completely unreadable.

That is not the library’s fault. Glass is supposed to be transparent, so on a light background it is naturally light too, and white text naturally disappears. On iOS the system presses a layer of material in for you. This library does not handle that layer.

So you add it yourself. drawBackdrop has an onDrawSurface parameter, and I drew a 30% black layer inside it:

onDrawSurface = { { drawRect(Color(0x30000000)) } }

With that in place, both themes behave. Here is the light and dark comparison.

Why it runs on desktop

This is the part I most wanted to understand. The library is called Android and the implementation really does use android.graphics.RuntimeShader, so why can desktop draw at all?

The source makes it clear. The library splits into three parts. commonMain holds all the logic in 2,270 lines, androidMain is 146 lines and skikoMain is 134 lines, and those last two handle the landing on each platform.

The shaders are AGSL strings. On Android they go into the system RuntimeShader. On the Skia side they go straight into RuntimeEffect.makeForShader, because AGSL was a subset of SkSL to begin with.

Which means the whole glass shader from Android compiles as it is once you hand it to Skia.

Desktop, iOS, and wasm all take this skiko path.

The support checks for both sides are in the source too. Android needs SDK_INT >= 31 for RenderEffect and >= 33 for RuntimeShader, while both functions on the Skia side just return true, with no threshold at all.

Two things that do not go so smoothly

The first is in the docs but easy to miss: the lens effect requires that shape be a CornerBasedShape. I used RoundedCornerShape, so it was fine, but swap in a custom Shape and you have to handle it yourself.

The second is in the source and not mentioned in the docs: the Skia implementation does not support integer array uniforms. setIntUniform(name, values: IntArray) throws UnsupportedOperationException on desktop, while the Android side is fine. You will not run into this day to day, but the moment you write a custom shader you will.

A note on how the docs phrase things. The official API page says the effects are RenderEffect under the hood, in effect from Android 12, and anything involving RuntimeShader needs Android 13. That sentence does not hold in a desktop context. I ran lens on macOS with no trouble at all. It is written from the Android point of view, so do not read it as a platform limit.

Performance, and the edges I hit

On this M series Mac, two pieces of glass animating together held a steady 60 fps, right at the refresh rate. Nine pieces of glass on screen at once, each with an animated lens, dropped it to 58.7 fps.

So at this scale, the cost of the effect has not become the bottleneck.

On the build side, the first run with dependency resolution took 25 seconds, and after that the Gradle cache keeps it under a second.

I should explain the screenshots as well. macOS would not give me screen recording permission, so system level capture only picked up the wallpaper. I switched to the screenshot() that ships with SkiaLayer, writing the window contents straight to PNG, and the pixels are accurate.

Where the community stands

Those 4,509 stars are not for nothing. The effect genuinely grabs people. But the pace is what it is: commits stopped on August 26, and the docs site lists its last update as 5 months ago.

There are 40 open issues. The first entry in the official FAQ is why the effect does not work, and the answer is that you probably forgot layerBackdrop. The second is more direct, an Android SIGSEGV crash that blows up in RenderThread, and you have to follow a tutorial to patch around it.

It is a good library, but it is one person’s project, not an official component. Expect Compose Foundation levels of stability and you will be disappointed.

My take

If you want macOS flavored glass panels on Compose desktop, this library works today, at a cost of two hundred KB and twenty lines of code.

Just do not use it as a finished component. It gives you the effect. Interaction, accessibility, and light and dark adaptation are all your own work. Apple’s version looks good partly because the system deals with those corners for you.

I plan to try it in one of my small tools. What I really wanted to verify was that one thing. An Android native library, riding the shared bloodline between AGSL and SkSL, running on desktop like it belongs there.

Would you bring a personally maintained library into your cross-platform project for one visual effect?

Going from alpha to rc sounds like a milestone. I unpacked both versions and compared them. Conclusion: not a single byte changed.

The short version first

0.2.2-rc.1 was published at 17:20 Beijing time on November 4, 2026 (2026-11-04T09:20:32Z).

I ran a per-file md5 comparison against 0.2.2-alpha.3, which shipped on November 3, 2026. The scope was the top-level package, the six core sub-packages, and the underlying framework cordis. 290 files, all lined up and hashed.

Result: in every package, the only file that differs is package.json.

dist, src, locale, README, all identical. This is not “a small change”. This is zero change.

How I compared them

Three steps on the command line, no special tooling.

npm pack @deepseek-ai/dsh@0.2.2-alpha.3 and @0.2.2-rc.1 to pull one tarball each, unpack them into two directories, then hash every file by relative path.

The top-level package has 20 files, the six sub-packages have 30 to 60 each, cordis has 32. Every file with a matching name on both sides got hashed, and I only kept the ones whose hashes disagreed.

No additions, no deletions. Eight packages, eight changes, all of them in the version number and dependency range lines.

The only thing that actually changed

The code did not change. But every dependency version moved, and that is the only substantive act in this release:

In one sentence: strip the alpha suffix off the entire cordis family and promote it to release version numbers.

But there is a detail here worth spelling out. I also unpacked cordis 4.0.6-alpha.2 and 4.1.0 and compared those two. Of its 32 files, again only package.json differs. Which means even the framework layer was carried over as-is, with nothing but the house number changed. That is more interesting than the table above.

The “version number goes from alpha to stable” event had a change count of zero.

So what was the point of this release

A tag.

Before this release, latest pointed at 0.2.1-rc.5 and next pointed at 0.2.2-alpha.3. If you wanted the newest one, you had to type the full version number by hand.

After it, both latest and next point at 0.2.2-rc.1. That means npm i -g @deepseek-ai/dsh with no version number installs this one by default.

For a project this size that is not a small thing. The alpha line is the “we are willing to use it ourselves” marker. rc is the “you try it too, the interfaces are frozen” marker. Changing features is development. Changing the marker is a promise. This release did the latter.

The upgrade took under a minute

One command for the global install, npm i -g @deepseek-ai/dsh@0.2.2-rc.1, and once it finishes dsh --version says 0.2.2-rc.1.

The second command is not an upgrade, it is a profile fix. A lot of people skip this one. I skipped it last time:

dsh plugin --profile web add @deepseek-ai/dsh-cua-bundle@0.2.2-rc.1 @deepseek-ai/dsh-experimental-plugin-market-bundle@0.2.2-rc.1 @deepseek-ai/dsh-experimental-client-ui-agent-team@0.2.2-rc.1

pnpm came back with: resolved 62 packages, reused 41, downloaded 21, added 22, in 939 milliseconds.

After the install I ran a headless smoke test first, telling it to “answer with two words only: received”. It answered “received”, which means the profile boots, model routing works, and no plugin is stuck in a disabled state. That step is faster than looking at the UI.

Why run it again? Because a dsh profile is plugin layers stacked on plugin layers. Once you upgrade dsh globally, the plugins in the profile that are still pinned to alpha.3 no longer match the host program’s version, and the version check disables them at startup.

Last time, when I went to alpha.3, I only upgraded globally. Six plugin rows got shut off, storage-domain among them. Once that one died, the workspace, the session list, and the scheduled tasks all froze with it, the web app was effectively dead, and this command is what brought it back.

So my order is fixed now: global first, then profile, then verify. Skip a step and you are making trouble for yourself.

The one that never came back last time is back

The only leftover damage from the previous upgrade was ui-agent-team. Its version line is unusual, there was no package on npm that lined up with alpha.3, so it stayed disabled the whole time.

This time it has a matching version. In the plugin list that profile_ping reports after the install, all three of these are present:

@deepseek-ai/dsh-experimental-agent-team

@deepseek-ai/dsh-experimental-client-ui-agent-team

@deepseek-ai/dsh-experimental-tool-agent-team

dsh-storage-domain, the one that got disabled last round, is in the list too. On the plugins page the “Agent teams” toggle is on, and a new session’s title bar now carries an extra Agent team badge.

The installer printed one line that I think is worth recording verbatim: @deepseek-ai/dsh-experimental-client-ui-agent-team does not declare dsh.bundle, so it was installed as an ordinary dependency, not as a profile layer.

In other words it works, but its position in the system is not the same as those bundles. Vendors do not put this in the release notes. It flashes by once, in the install output.

Not everything in a profile is an official package

I took a look at the profile’s dependency list while I was there. Six entries.

Three bundles are on rc.1 now. agent-team-web-profile is still stuck on 0.1.6-alpha.2. The last two I installed myself, one from a local tgz, one straight from a GitHub repo.

Which tells you that a dsh profile is not a closed official bundle, it is a combination you assemble yourself. The upside is you can add whatever you want. The cost is that on upgrade you have to watch it yourself: which ones are official, which are pinned to a specific version, which are not on the official version line at all.

agent-team-web-profile is the example. It is the UI layer for agent-team, its version line is completely independent of the host program, and the host is on rc.1 while it sits on alpha.2. A package like that will not follow your upgrade. It goes its own way.

A quick sanity check

After the upgrade I opened a new session in the web app and sent one line: call profile_ping and paste the returned JSON back as-is.

Ten seconds and it was done. The response started with "profile": "web", "dshVersion": "0.2.2-rc.1", "plugins": [ followed by 212 plugin names.

Those 212 lines are what my profile actually contains right now, from cordis-plugin-timer all the way to dsh-plugin-profile-ping, which I wrote myself. If you want to confirm the upgrade really took effect, that one number is more reliable than any UI.

Incidentally the query itself cost 56.3K tokens, with an 86% cache hit and 3% of context used. The cost is the long plugin list, not the reasoning.

One lesson about checking versions

If you want to track dsh versions too, there is a trap to avoid: the latest tag on sub-packages lags.

Take dsh-experimental-client-ui-agent-team. Its latest is stuck at 0.1.5-alpha.2, alpha is stuck at 0.2.2-alpha.3, and the actual new version lives under next.

npm view <package> dist-tags and read all three tags together, not just latest. The main package’s latest is correct right now. The sub-packages’ are not.

My call

Is a release like this worth following? My answer is yes, but there is no rush.

Zero code change means risk close to zero. Upgrading or not upgrading will not break your environment. The real payoff is not in dsh itself but in the plugins that got promoted along with it: a package like ui-agent-team that spans version lines only gets released when the whole line moves to rc together.

On the flip side, if you have an alpha.3 that runs fine and no plugin is disabled, you do not need to touch anything this time. Wait for the 0.2.2 stable release and catch up in one go. There are no new features coming your way in the meantime.

When you upgrade, do you read the release notes first, or just unpack the tarballs and diff them yourself?

I read the repo before I installed the local build. Reading the source turned up one thing that surprised me more than any of its features: the editor in this “IDE” is read-only.

Line 110 of monacoSetup.ts says readOnly: true, with a hint string to go with it. I opened the UI and tried typing into it. Not a single character went in, and the file hash didn’t change.

This post is about that one thing: an IDE that won’t let you edit code, and what exactly it’s betting on.

It Isn’t the Next IntelliJ

The repo is at JetBrains/thinkrail, Apache-2.0, with a “JetBrains incubator project” badge on the README.

Their own description is one sentence: use pi to do vibe coding in this lightweight IDE, and it customizes itself around the way you work.

What’s pi? A third-party minimal agent harness, package name @earendil-works/pi-coding-agent, from the Earendil folks. Its philosophy is “no features, just primitives”. Sub-agents, plan mode, permission prompts, none of it is built in. You write your own extensions.

What ThinkRail does is wrap that command-line agent in a full interface: workspace, editor, diff, terminal, spec tree.

So what you’re looking at is a company of a couple thousand people writing a shell in TypeScript to wrap an agent that somebody else wrote. That’s a different road from the one IntelliJ took with its own kernel.

Installing It Means a 218 MB File

It comes in two shapes: a desktop installer, and a self-contained command line build.

I downloaded the CLI version. A single 218 MB file with a Bun runtime stuffed inside, so you don’t have to install node first. Running it looks like this:

./thinkrail --no-open --port 24242 <your repo path>

Open localhost:24242 in a browser and you get the full interface. There’s no account system of its own. Models come from pi’s config.

I was all set to go into settings and paste a DeepSeek key, and then the Providers page opened with a line already sitting there: DeepSeek, env key DEEPSEEK_API_KEY, connected.

It had read the connection pi already had configured in my shell environment. Zero setup.

I Gave It a Broken Repo

I prepared the test case on purpose: a small JS library that turns titles into URL slugs, with one of its two tests red because the implementation doesn’t handle punctuation.

The landing page has three options: write specs, start work directly, or work inside the project directory. I clicked the first one, which is its signature flow.

I kept the prompt restrained: write out the specs as things stand, don’t change any code yet.

After I hit create, the first thing it did was cut a real git worktree at ~/.thinkrail/worktrees/demo-repo/workspace-1, on a branch called write-slug-lib-specs. I went back to the main repo to check. main was still on the same commit, not a hair moved.

This step isn’t simulated. git worktree list shows two lines.

Six Minutes Seventeen Seconds, Three Files

When it finished I looked at the numbers: 6 minutes 17 seconds, 26 tool calls, 15 steps, with three spec_create, three file reads, and three file edits. It used 5.3% of a one million token context and cost 0.138 dollars.

It didn’t start writing right away. First ls to see the structure, read the README, read the tests, then it actually ran node --test, saw that red test, and only then started writing.

Three markdown files came out:

goal-and-requirements.md covers what the library is, who it’s for, and that for now it only does “lowercase plus spaces to hyphens”. architecture.md covers the single-module topology, with dependencies going only from tests to source. src/SPEC.md covers the slugify contract and its boundaries.

All three carry frontmatter, id, type, status: draft and parent, strung together into a graph. That’s not a format I taught it. It’s the fixed rule from the spec-graph skill pack it loads.

The most interesting part is how it handled that red test. It didn’t write “strips punctuation” down as a capability that already works. Instead it opened a separate section in the module spec called “Known limitation” and spelled it out: the test expects hello-world, the function returns hello,-world!, punctuation left as is.

When it was done it ran spec_validate itself. It passed.

What the Spec Graph Looks Like

The three files aren’t documents sitting side by side. They’re a tree with parent pointers.

The root is the goal document, the middle is architecture, the leaves are specs for individual modules. The right column in the UI is that tree. Click a node and the editor on the left renders the file, with Preview and Source views.

Their blog post “Spec-Driven Development” says the point is to let intent outlive the session. Close the chat and the code is still there, but the “why it’s written this way” usually disappears along with the chat. Specs keep that part around, and the agent reads the whole graph in at the start of every run.

This time I only had it write, not edit. When it does edit, it reads the same graph.

Then I Found the Read-Only Thing

After it finished I wanted to change a sentence myself, so I clicked into the Source view of src/SPEC.md, selected a line, and pressed a key.

Nothing. I assumed it was a focus problem, clicked a few times, then tried shoving text straight into the editable region with devtools. Same conclusion: input doesn’t go in, and the file hash on disk is identical before and after.

So I went back to the source for the answer, and it’s that readOnly: true from the top of this post. The UI even has a hint prepared, telling you to have the agent make the change.

Someone raised this on Hacker News, saying the chat panel is the lead actor in ThinkRail and the editor and file tree are supporting cast, that “you’re not even allowed to edit files by hand”.

I checked it, and it’s true. In fairness though: the terminal works. There’s a real PTY at the bottom, and nobody stops you from running vim in it. Only that Monaco panel is locked.

The problem is that this design swaps out the subject of “changing code”. In an old IDE, you and the agent each own half of that. Here the division of labor is clear: the agent writes, you review.

Why It Dares to Design It This Way

Because in its architecture, the IDE part was never the point.

The official architecture doc splits the system into three rings: the engine host, the protocol line, and the UI client.

The first ring runs in packages/server, using Bun to start an HTTP + WebSocket service with pi running in-process. The second ring is the versioned protocol in packages/contracts, the only coupling between the two ends. The third ring is apps/web, a React client that is mobile first.

“Mobile first” is not a figure of speech. The doc says so: the UI ships independently of the host, dials into a host over the network, and a phone can connect through Tailscale.

So from day one it never designed itself as a traditional IDE. It’s a remote panel for an agent host, and the desktop build just happens to wrap it in Electrobun.

The read-only editor isn’t a crippled editor. It’s the natural result of that architecture: the UI is only the observer and the approver, and the thing that actually does the work is the agent inside the host.

The Repo Itself

The codebase isn’t small: 1,493 TypeScript files plus 349 TSX files, 354,000 lines.

The stack is new too: Bun runtime, React 19, Monaco 0.57 with shiki, xterm 6, Tailwind 4, TypeScript 6.0.3, Astro for the site. The desktop shell isn’t Electron, it’s Electrobun.

Community numbers: 7,484 stars, 450 forks, 365 open issues. The repo was created on July 8, 2026, and it got there in under four months. That’s a fast pace.

Releases are dense too: 0.2.0 on October 18, 0.3.0 on October 29, 0.3.1 on November 1, and the nightlies are already at 0.4.0.

Two Things That Don’t Sound Good

First, telemetry is on by default. analyticsEnabled and analyticsConsentConfirmed are both true in config.json. That --no-analytics launch flag only turns off “additional usage data”, not the basic stats, so you have to go into settings to kill those.

Second, JetBrains’ AI strategy is a bit scattered right now. The two Hacker News threads together have over two hundred points and over two hundred comments, and the top voted one isn’t praise, it’s a complaint: Air and ThinkRail are both still half finished, while the AI Assistant that actually works well got pushed to the side.

I agree with that one. ThinkRail feels more like a bet, an experiment. JetBrains itself hangs the incubator sign on it.

My Call

If your first reaction is “what use is an IDE that won’t let you edit”, then it really wasn’t built for you.

It serves a different group: people already used to letting the agent do the work, whose main job is reviewing diffs and writing specs, moving forward one session after another. For them, being able to edit is actually a burden, because when you and the agent are fighting over the same file, the conflict can only be settled by self-discipline.

The answer it gives is physical isolation: one worktree and one branch per workspace, so the agent’s mess stays on its own branch, and you merge only after you’ve reviewed it.

I think that idea is more thorough than “add an AI button to the editor”. Its bet is that the IDE of the future is mainly for review, not for writing.

Whether the bet is right, check back in a year. As for this version, I’ll use it for small jobs. I won’t use it to replace IDEA.

When you write code these days, is that moment of changing a file still mostly your own hands, or has it already gone to the agent? If it’s the latter, this read-only design probably won’t bother you.

I run dsh daily, on 0.2.2-alpha.2 released October 28. My first instinct was not to paraphrase it. It was to try it.

So I opened a Creator mode session in my own web profile with a one-line request: write the smallest possible plugin, register a tool called profile_ping, and have it return the current profile name, the dsh version, and which plugins are installed in that profile.

Nine minutes later the tool was sitting in the plugin manager. I opened a new session, called it, and had the answer in ten seconds.

dsh has four modes

Open the web UI and there is a mode selector above the input box. It expands to four:

• Standard: writes code, looks things up, runs commands, good for most tasks
• PTC: everything Standard does, plus batches of tool calls you then filter, dedupe, count, or summarize
• Minimal: terminal and image reading only, for testing baseline capability
• Creator: in the official wording, customize dsh through conversation, letting the agent write plugins that add features or UI, or combine tools and prompts into a mode of your own

I picked the fourth.

It did not start by writing code

That was the most surprising part.

After receiving the request it loaded a skill package called cordis-plugin-development, then started inspecting the runtime.

The Trajectory panel on the right shows the sequence. It ran inspect providers to see what services exist, then query runtime to ask for the exact method signatures on Service.listService, and worked through the contracts for pluginManager, profileContext, and defineTool.

It even went and read the source of @deepseek-ai/dsh-app-boot to decide whether a plugin could import that package. It needed the dsh version, and the version only exists in the install directory’s package.json.

That reasoning step is worth more than the result. It first established that a profile-installed plugin cannot resolve packages from the install directory, then switched to the profileContext the runtime already exposes, reading the version itself from the installAnchor path.

What it produced

The output is a standard bundle package in the session workspace: manifest, patch, entry point, two locale files, an icon, and a README.

The line in package.json, "dsh": { "bundle": { "patch": "./cordis.patch.yml" } }, is how it introduces itself to dsh. The patch file is three lines, inserting a row with the id profile-ping.

index.js is 6.9 KB: it registers the tool, defines the parameter and output schemas, and writes a render function. The Chinese display name, “Profile 探针” (profile probe), it picked on its own.

I rejected it once

The install step calls plugin_manager with install_bundle, which raises an approval dialog stating that this writes changes into the profile and that installed Host code runs outside the sandbox.

I clicked Allow once.

Later it wanted to copy the packed tgz out of /tmp into Documents for safekeeping, and asked for approval again. I clicked Reject, because this was a temporary artifact I planned to clean up.

Its reaction is worth recording: it stopped, and said explicitly that the user declined the escalation, so it should not work around it and would just explain.

That rule is written in its skill package, not improvised by the model. The text: do not hand-write the profile’s package.json, do not run pnpm in the profile directory, install_bundle does those things.

It works

In a new session I said: call profile_ping directly and paste the raw output.

Ten seconds later it came back with Profile: web, dsh version: 0.2.2-alpha.2, Plugins (209):, followed by 209 package names. The one at the end of that list is the tool it just wrote.

The plugin manager’s installed list also gained a row: Profile ping, with icon, description, and its toggle switched on.

The rules are written into the skill package

I only read the skill document it loaded after the run, and then I understood why it moved the way it did. The document writes that the workflow has five steps, and the first is “deliver a working version first.”

The opening of the doc says: ship something that runs, then talk about how it looks. If a visual request names no destination, the default is the current web UI. Do not build a preview page, do not make several design variants, do not write screenshot scripts.

Then three prohibitions: do not hand-write the profile’s package.json, do not run pnpm in the profile directory, do not create packages under $DSH_HOME. Those all go through install_bundle, and a hand write costs an approval each time.

There is also a verification rule: after install, read application and warnings from the returned result, not logs, not the process list, not whether the page came up.

I did not interfere with a single technical decision. The only thing I did was two approval clicks, one yes and one no. It walked the whole thing inside that rulebook.

Three rough edges I have to mention

First, the workspace directory it created has a literal backslash in its name. On macOS dsh built the path as deepseek-harness\creator-lab, and that backslash is a real character, not an escape. ESM cannot load such a path, so the plugin simply could not be imported. It found this itself and worked around it by packing a tgz and installing from that.

Second, in the same turn the tool could not be called. The tool list is fixed when a turn begins, so a freshly registered tool only appears next turn. It spun in the Trajectory several times, writing in its own reasoning that it could probably only emit tools from the static list. I had to open a new session to verify it.

Third, the install record says file:/tmp/dsh-plugin-build/xxx.tgz. Clear the temp directory and this plugin never installs again. That is the problem it wanted to fix, and that is the request I rejected. For anything long-lived, the package belongs in a workspace and should be installed by pointing install_bundle at the directory.

What it can build, and what it cannot

It can build tool plugins, which add a capability to the agent’s toolbox, like my profile_ping; configuration plugins, which change the behavior of some host service; and UI plugins, which mount into a slot in the web UI. The skill package ships templates and reference docs for all three.

It cannot build plugins that need a new host service. Its own documentation says this plugin is not a kernel: no new services, no new session event types, no new sandbox backends. Cross-profile changes are also out, one profile at a time.

The more practical limit is tokens. Nine minutes of work burned 8.9 million tokens, and a 99% cache hit rate is what kept the cost bearable. If you want it doing serious work, decide first whether it is worth that.

My take

“Build plugins by chatting” makes it sound like a generator: you describe, it emits code.

It is not that. It behaves like an engineer who knows this framework: inspect what the runtime offers, read source to confirm the constraints, follow the skill package’s procedure, request approval to install, and verify the result itself.

What is actually scarce here is the procedure. The skill package writes down “deliver something runnable before anything pretty,” “an unspecified visual request lands in the current UI,” and “read application, not logs.” Models change. This rulebook does not.

One boundary worth stating: 8.9 million tokens for nine minutes, 99% cache hit. This is not free magic, it is real construction work.

What tool of yours do you have to dig through config every time just to learn its state? That one is worth having a plugin written for it.

So I went and read the Android 16 behavior changes doc. The word the documentation uses is not “encourage.” It is ignore. Ignore your portrait lock, ignore your non-resizable flag, ignore your aspect ratio cap.

It is not asking. It removed the switch at the system level.

So I ran a controlled test: one codebase, two builds at targetSdk 35 and 36, installed on the same emulator with the display resized to tablet dimensions, then a command to rotate.

What the doc actually says

For apps targeting Android 16 (API level 36), orientation, resizability, and aspect ratio restrictions no longer apply on displays with smallest width >= 600dp.

Two conditions: target 36, and smallest width at least 600dp. Meet them and the app fills the entire window, without even the courtesy of letterboxing.

The list of what gets ignored is specific. Three manifest attributes: screenOrientation, resizeableActivity, minAspectRatio, maxAspectRatio. Two runtime methods: setRequestedOrientation() and getRequestedOrientation().

Portrait, landscape, reverse portrait, sensor portrait, user portrait, the whole set of values stops mattering.

Why Google dared to just remove it

The Android Developers documentation writes that apps today have to run on phones, tablets, foldables, desktop mode, cars, TVs, and inside multi-window shapes like split screen and desktop windows. Its words: locks on orientation and size are now “overly restrictive.”

Plainly: a portrait lock protects your layout on a phone, and on a tablet or a desktop window it turns into “the user cannot use this.”

The docs also name the direction, saying apps are expected to adapt to any orientation, size and aspect ratio themselves. That reads soft. In system behavior it is hard.

How I built the test

One Activity, plain Java, no Compose, printing four lines on screen: current orientation, screenWidthDp, screenHeightDp, smallestScreenWidthDp.

The manifest deliberately turns every restriction on: android:screenOrientation="portrait", android:resizeableActivity="false", android:maxAspectRatio="1.5".

The same source compiled twice with only targetSdk changed, 2.5 MB per APK. Device: an API 36 emulator.

To make it a tablet: wm size 1200x1920 and wm density 240, which works out to an app area of 1280×800dp with a smallest width of 800dp, just over the line. Then settings put system user_rotation 1 to command it into landscape.

Result one: targetSdk 35 stays locked, with a nudge

The 35 build dutifully stays in portrait. Its content is still 800×1200, stuffed into a 1280×800 landscape window with two fat black bars on the sides.

That is the old behavior, compatibility mode. The system even pops a hint in the corner: “Tap to restart this app for a better view.”

Which is to say: tap this and it will look right. The system is not being subtle about its opinion.

Result two: targetSdk 36 defies the manifest

Switch to the 36 build, same rotate command, and it flips.

The screen reports itself: orientation is LANDSCAPE, screenWidthDp 1280, screenHeightDp 800, smallestScreenWidthDp 800. Full bleed, no bars.

Three lines in the manifest, not one of them had any effect.

Result three: back to phone size, the restriction returns

I reset the display to phone dimensions (1080×2400 at 420dpi, smallest width 411dp) and told the 36 build to rotate again.

It did not move. Still PORTRAIT.

So the rule is not “new target version, no restrictions.” It is “smallest width over 600dp, no restrictions.” At 411dp your portrait lock still holds.

This matters, because a lot of the coverage rendered it as “Android 16 removed orientation restrictions,” which is wrong.

The exceptions, and one temporary escape hatch

Per the Android 16 behavior changes page, there are three exceptions: games (determined by android:appCategory), users who explicitly opt into an app’s default behavior in the system aspect ratio settings, and displays smaller than 600dp.

There is also an opt-out, written in the manifest:

<property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY"
          android:value="true" />

It can sit on the activity or on the application. Declare it and you fall back to compatibility mode.

But it has an expiry date. The same doc notes this opt-out stops working on future Android versions when targeting API 37. In other words, you get a year to move house, not a permanent switch.

If you want to preview the behavior on 36 without changing targetSdk, flip the compatibility framework flag UNIVERSAL_RESIZABLE_BY_DEFAULT. I compiled two APKs instead, which is cleaner.

What this change will knock loose

The docs list the typical symptoms in a Common breaking changes section, and it is more precise than any secondhand write-up I have read: stretched layouts, and off-screen animations and components.

Both are the same underlying thing: your layout assumed a fixed aspect ratio. A RecyclerView with a hardcoded height, margins computed from screen width, a background image prepared at one size, none of it visible while you were locked to portrait, all of it obvious the moment you rotate.

There is a sneakier category. With a portrait lock, the Activity never recreated on rotation, so a sloppy onSaveInstanceState never showed up. Now it recreates, and state you failed to save is data the user just lost.

So how do you actually fix it

The official answer is a single sentence: lay out by window size, not by device type.

Window size classes now come in five width tiers: under 600 is compact, 600 to 840 is medium, 840 to 1200 is expanded, 1200 to 1600 is large, above 1600 is extra large.

Height is classified separately, with breakpoints at 480 and 900.

The breakpoint table lives on the Use window size classes page.

That page also offers a useful reference. The compact width tier covers 99.96% of phone portrait configurations; expanded covers 97.22% of tablet landscape ones.

One sentence from the doc worth copying down: window size classes are explicitly not determined by the size of the device screen, and they are not for writing isTablet logic. Split-screen an app and the window is half as wide, so it should use the medium set.

One more thing that is easy to miss: allowing rotation means more Activity recreation. Before, with a portrait lock, rotation simply never happened. Now it does.

The limits of my test, stated plainly

First, I resized an emulator display rather than using a real foldable. Fold posture, desktop windowing, and resize inside split screen, I have no real-device behavior for any of it and can only describe what the docs say.

Second, I tested one Activity with an empty UI. What I verified is whether the system-level restriction applies, not how well some real app adapts.

Third, I skipped Android Studio’s foldable AVD because it meant downloading another system image and the time was not worth it. If you want better data, the official foldable emulator config gives you posture with one install.

I state plainly the parts I can prove, and flag the parts I cannot. That is the rule I hold myself to on every hands-on piece.

My take

This change matters more than “foldable support” makes it sound.

For the past decade the portrait lock was an honest compromise: phone screens are narrow, landscape wrecks the layout, so lock it. The system just removed it, which turns “can your layout adapt” into a hard requirement.

For product people that is good news, less room to be lazy. For the people writing the code it is work: onConfigurationChanged and state saving need a careful pass.

Will the app you are working on today survive a rotation? You do not need to wait for 37. Spin up an emulator, set the display to 1200×1920 and density to 240, and you will know in five minutes.

That means anyone who can sit in the middle of your network can sign a “trusted” certificate with one of those keys and impersonate the services JetBrains tools talk to.

JetBrains published two advisories on October 30. One covers what to do about the IDEs, the other is a status table across the product line. I read through the coverage in Chinese, and it was all paraphrase. Nobody actually went and checked their machine.

This post is that check, written as a manual. Everything runs locally, and nothing in here changes your configuration.

What the advisory actually says

The affected components are the ones that run on Java: the IDEs, Toolbox, Gateway, ReSharper. They trust the trust store shipped inside the bundled JetBrains Runtime, not the macOS Keychain.

The advisory is blunt about one thing: updating your operating system does not protect you here.

The fixed JBR no longer trusts these four root certificates: emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2, and AAA Certificate Services.

Under the hood that is four CVEs. CVE-2026-91403 and CVE-2026-114820 are Oracle’s fixes inside the JBR. CVE-2026-118696 covers the embedded browser JCEF taking Chrome’s certificate revocation list. CVE-2026-118697 covers the background service jetbrainsd and its own bundled list.

Three layers, each fixed separately.

Step one: check whether your versions even line up

Don’t start deleting certificates. First find out which build you are running. A JetBrains .app carries an Info.plist, and the build number is in it.

/usr/libexec/PlistBuddy -c 'Print :CFBundleShortVersionString' \
  "/Applications/Android Studio.app/Contents/Info.plist"
/usr/libexec/PlistBuddy -c 'Print :CFBundleVersion' \
  "/Applications/Android Studio.app/Contents/Info.plist"

Swap the path for whichever IDE you have. Toolbox installs live under ~/Applications.

On my machine:

• IntelliJ IDEA 2026.2.3, build IU-262.10968.63, bundled JBR 25.0.4+1-508.27
• Android Studio 2026.2, build AI-262.9437.185.2621.16467767, JBR 25.0.3
• JetBrains Toolbox 3.9.1, build 3.9.1.89198

Cross-checking against the fixed-version list: IDEA has to be 2026.2.4 to count as fixed, and I am on 2026.2.3, one patch short. Toolbox 3.9.1 is on the list, so that one passes.

Android Studio is a blank spot. It is not in JetBrains’ table at all, and I could not find an equivalent Google advisory, so I checked the JBR version myself: 25.0.3, while the fixed JBR 25 builds are 635.79, 508.41, and 329.142. 25.0.3 is obviously old.

Step two: just ask the trust store how many are left

Version numbers can lie. Trust stores cannot. Every JBR ships a cacerts file, and its own keytool will list it.

"/Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/keytool" \
  -list -cacerts -storepass changeit | grep -iE "emsign|comodo"

Android Studio returns four lines:

• comodoaaaca [jdk]
• emsigneccrootcag3 [jdk]
• emsignrootcag1 [jdk]
• emsignrootcag2 [jdk]

All four are there. IntelliJ IDEA’s copy is the same, all four present, 111 certificates in total.

There is a trap here I have to mention, because I walked into it: the alias as printed carries a space and a bracketed suffix, emsigneccrootcag3 [jdk]. If you type just emsigneccrootcag3 to delete it, keytool tells you no such alias exists, even though it is sitting right there in the list.

Step three: prove your fix actually took effect

This is the step the official documentation does not have.

The official workaround is: copy the cacerts file, delete the affected roots, then point the IDE at the copy with a VM option. The problem is knowing whether that -Djavax.net.ssl.trustStore actually got loaded. A wrong path, a missing slash, a ~ that never expands, and it fails silently.

So I wrote a thirty-line program that asks the JVM directly: how many of these do you still trust?

The key line is tmf.init((KeyStore) null), which makes the JVM use its default trust store, the one that honours javax.net.ssl.trustStore. Then you count how many issuers in getAcceptedIssuers() are named emSign or AAA Certificate Services.

Here is what came out:

With no VM option, it reports 109 certificates and 4 hits. Pointed at the officially cleaned copy, 107 and 2 hits. With all four removed, 105 and 0 hits.

Three numbers, and the gap between “I think I fixed it” and “I did fix it” closes.

Two things the advisory does not tell you

First: the official workaround removes two aliases, comodoaaaca [jdk] and emsigneccrootcag3 [jdk].

But what I found on my machine was all four present, G1 and G2 included. After deleting those two, my probe still reported two hits. So if you follow the two documented steps on this machine, two eMudhra root certificates stay behind.

I am not in a position to explain why JetBrains listed only two. Maybe the fixed runtime handles G1 and G2 elsewhere, maybe they were being conservative. On the plain question of what is on the machine, the number is four, not two. If you want to be thorough, delete all four; I measured 105 certificates and zero hits afterwards.

Second: macOS’s own system roots still contain these two.

emSign ECC Root CA - G3 has SHA-1 3043FA4FF257DCA0C380EE2E58EA78B23FE6BBC1, and emSign Root CA - G1 has 8AC7AD8F73AC4EC1B5754DA540F4FCCF7CB58E8C.

security dump-trust-settings shows no per-certificate distrust policy in either the system or the user domain. That does not mean macOS is letting them through, TLS has other mechanisms, but from the Keychain side at least, they are still there.

While you are at it, scan the other JVMs

This is the part most people will miss.

JetBrains only speaks for its own products. But your Gradle daemon runs on some JDK, your command-line Kotlin compile uses some JDK, Homebrew installed another one, and every single one has its own cacerts, unrelated to the IDE’s.

I walked every JVM on the machine that can run keytool:

• Homebrew OpenJDK 21.0.10, 109 certificates, all four present
• Android Studio’s bundled JBR 25.0.3, 109 certificates, all four present
• IntelliJ IDEA’s bundled JBR 25.0.4, 111 certificates, all four present

Not one of them is fixed.

JetBrains also shipped fixed JBR builds on two jbr21 lines, 21.0.11b1163.125 and 21.0.9b1038.91. When upstream OpenJDK catches up I have no first-hand source for, so I will not draw that conclusion for you. All I can say is that the 21.0.10 on this machine still has all four.

What to do

The priority order is obvious: upgrade if you can, and skip the workarounds.

IDEA 2026.2.4 shipped on October 30; I checked the date against JetBrains’ release API. Toolbox 3.9.1 is already installed, and I checked jetbrainsd too, which runs 0.9.9728, the fixed version. So the only thing left to touch is the IDE itself.

If you cannot upgrade yet, the official three steps are: copy cacerts, delete the aliases with the keytool from that jbr, then add a line to Help → Edit Custom VM Options with -Djavax.net.ssl.trustStore= pointing at the copy.

The path has to be absolute. No ~, no quotes. Get it wrong and it will not complain, it just silently does nothing. Then confirm in Settings → Server Certificates that automatically accepting untrusted certificates is off.

One more detail: the JCEF embedded browser’s certificate list cannot be changed, so on 2025.2.6.4 and earlier you have to turn it off entirely with the registry key ide.browser.jcef.enabled. Markdown previews and notebook output stop working when you do, so remember to turn it back on after you upgrade.

My take

The thing worth remembering here is not which version got fixed. It is where your trust boundaries actually are.

You updated macOS, so you assume you are safe. You updated Chrome, so you assume you are safe. But the IDE carries its own trust store, Gradle has another one, and the JDK on your command line has a third. Each one needs its own fix.

A security advisory is written for everyone. It will never answer “what state is this specific machine in.” That answer only comes out if you run it yourself.

How many JVMs are on your machine right now? Go scan them. I would bet more than one still has all four.

On the phone it has been a blank. Your app holds a pile of capabilities, search, send a message, create an event, and an agent can reach none of them. It falls back to screenshots, taps a guessed coordinate, takes another screenshot.

In February Google put something called AppFunctions on the Android Developers Blog. On the twenty-first of last month its SDK shipped 1.0.0-beta01.

I got it running on an emulator, including letting an “agent” send a message straight through my app’s UI.

The official framing is blunt

That post was written by Matthew McCullough, VP of Product Management for Android Developer. His wording: AppFunctions let apps declare what they can do the way backends declare capabilities through an MCP cloud server, except execution happens on device.

The same paragraph mentions WebMCP, saying the two are part of one line, one in the browser, one in the system.

So the positioning is clear. This is not another custom intent protocol, it is deliberately shaped like MCP. A detail from the October beta confirms it: they renamed the metadata field from description to instructions, and the stated reason was aligning with MCP naming conventions.

One AppFunction takes four steps

First, you write a service class in your app that extends AppFunctionService, annotate methods with @AppFunctionDeclaration, and the KDoc becomes the description the model reads. Second, an annotation processor generates an XML at build time carrying every parameter, type, enum constraint, and return shape.

Third, that XML goes into the APK’s assets directory and Android reads it to register functions in a global table.

Fourth, an authorized caller gets AppFunctionManager, checks whether the function is enabled, and calls it.

I went digging inside the APK and the XML is really there. The sample’s assets/chat_app_function_service.xml is twenty-two kilobytes, six functions, every parameter description pulled out of KDoc.

Local test: from compile to an actual sent message

The sample is ChatApp from the official android/appfunctions repo, Compose plus Hilt, building into a 14.8 MB debug package. Installed on the emulator, it registers six functions on first launch: search contacts, send a message, place a call, search messages, fetch send details, change the wallpaper.

The device listing looks like this, and the same emulator has system apps doing it on their own:

• com.example.chatapp, six, all business functions of that chat app
• com.android.settings, six, all named getXxxDeviceState, reading battery, storage, notifications
• com.google.android.permissioncontroller, one, reading permission state
• com.google.android.apps.wellbeing, one

System apps are already using this thing themselves. That is more convincing than any documentation.

One call, and what comes back

I called it over ADB, straight past the UI, imitating what an agent would do. Following the function’s own instruction that you must search contacts first to get an endpointValue, I searched a contact:

androidAppfunctionsReturnValue:
  contactDisplayName: Alice Smith
  endpointValue: 1
  contactType: INDIVIDUAL
  endpointDisplayName: alice@example.com

With that 1 in hand, step two sends the message, taking the id plus the body. It returns Message sent to: Alice Smith.

Then I opened the app and looked. The message I had passed in, which said in Chinese “this one was sent by an agent through AppFunction”, was sitting in Alice’s conversation.

No screen interaction at any point. No screenshot, no coordinates.

The one thing to remember: who gets to call

This is the part I most want you to notice.

For another app to discover and execute your AppFunction, the caller must hold EXECUTE_APP_FUNCTIONS. I pulled the permission definition on the emulator:

Permission [android.permission.EXECUTE_APP_FUNCTIONS] sourcePackage=android prot=internal|privileged

Internal plus privileged means an ordinary app cannot get it, only the system signature or apps on a privileged allowlist have it. Today that means system assistants like Gemini.

Which makes both camps right. “Android apps can finally talk to AI agents” is true. “This is not open agent access” is also true. The functions are publicly declared, and the door is locked.

It is already turning into policy

The other thread in the docs is AEP, Google Play’s Apps Experience Program.

It carries an explicit guideline called Android MCP, requiring participating apps to implement at least one relevant scenario with AppFunctions and pass its required tests. The scope is spelled out: messaging, notes, calendar, tasks, health, shopping.

Enforcement is March 1, 2027, or three months after self-service registration opens, whichever is later.

In other words, today it is an experimental API, next year it is a Play compliance item. That cadence is worth seeing early.

There is also a zero-code path, worth seeing side by side

The same blog post put a second route on the table: UI automation.

The platform operates your interface itself, so the developer’s workload is zero. Users long-press the power button on a Galaxy S26 or some Pixel 10 devices and hand a multi-step task to Gemini, starting in the US and Korea with food delivery, groceries, and ride hailing.

Users can watch progress, take over at any point, and get a prompt before sensitive actions like payment.

Side by side, the tradeoff gets clear. AppFunctions gives you control: you decide what to expose, how to describe it, how failures come back. UI automation gives you reach, but you have no part in the definition, and the agent can only tap your UI like a person would.

Google says Android 17 will broaden both. My read is that serious product teams will treat the first as home turf and the second as a fallback.

What is not here yet, stated plainly

The SDK is beta, not final. The docs mark it experimental preview, the API will move, and October moved a fair amount.

The Gemini integration is a private preview open to trusted testers. The public case that actually works is Samsung Gallery, on the Galaxy S26, expanding to One UI 8.5 soon.

And one honest note: I tried disabling a function over ADB to verify the claim that users can turn them off, and the command timed out after thirty seconds with the function state unchanged. I did not verify that, so it does not belong in the conclusions.

My read

What makes this different from the usual “AI integration APIs” is the shape.

Before, each vendor invented an intent and agents had to adapt one by one. This one is cut from the MCP mold: self-describing, discoverable, with enum constraints, required fields, and error codes.

For people who write apps, the real change is not this year. It arrives when that policy takes effect next year, and the question becomes whether your app can explain its own core capabilities.

A well thought out function declaration does more for an agent than ten pages of help docs.

If your app were only allowed to expose three functions to a system assistant, which three would you pick?

Tell me in the comments. I will pick a few interesting ones and take them apart next time.

Native apps are a different story. iOS and Android have no equivalent protocol, so all an agent gets is a screenshot.

A screenshot shows you something, but it cannot show that “this button’s border went from 5.25 to 15.75 over 1.8 seconds”, or that “this line of text is buried under a translucent layer”. It guesses, edits, screenshots again.

On October twenty-third a project called agent-ddp went open source to fill that gap.

It turns the screen into a few hundred lines of text

Once installed, an agent asking what is on screen gets this back:

@e1 animatedButton "Selected" [383, 158, 315, 137]
  z=1 layer fill #0000FFFF corner 31.5
  z=2 bitmap [467, 195, 147, 63]
  z=3 layer border 15.75 #FFA500FF corner 31.5
@e2 flashBox "Flash" [460, 358, 160, 115]

Every element carries a reference like @e1, usable in the next command. Fill, border, corner radius, coordinates, z-order, all numbers.

I measured it: this screen has 25 elements across 59 draw nodes, and ddp tree outputs 4,184 bytes. The same screen saved as a screenshot is 77,397 bytes.

That is 18.5 times smaller, and the difference is not size, it is determinism. A screenshot has to be interpreted, text is read.

Running it locally: install to result

I used the emulator already on my Mac, Medium Phone, API 36.1.

npm i -g agent-ddp installs the CLI, a Rust binary with no runtime dependencies. The sample project builds a 10 MB debug APK with Gradle, installs to the emulator, and launches.

First command is ddp doctor, which checks device, app, library, and endpoint:

ok agent-ddp library in the build ok control endpoint answers ok 25 elements on screen ok hook compose.zSortedChildren (internal): answered 4608 times

About twenty lines, all green. That step matters, because it does not just check connectivity, it reports how many times each hidden hook was called. More on why later.

Then I typed one line, ddp check all. 2.7 seconds, 116 frames scanned, nine problems, exit code 1.

The nine problems look like this

• Two cases of text covered: not a single pixel of boxCovered’s glyphs appears inside its own frame
• One corner radius violation: hatchCard draws a gray line outside its rounded corner
• One animation that never settles: clockBar still changing in the last 500 ms, 29 times
• Two accessibility elements without labels, two tap targets at 37×47, under the 48×48 minimum
• One contrast ratio at 1.5:1, under 4.5:1

Every item carries evidence coordinates. The covered text one reads that its glyphs never appear inside [42, 1283, 258, 85], and that the screen at that spot is #9E9E9EFF.

I checked the screenshot. There really is a gray block sitting on top of the text.

What I liked most is the time it refused me

That covered button in the UI, I tried to make it tap:

ddp: boxCovered is covered by pointerInput: no point of it takes a touch next: ddp check tappable, or ddp tap boxCovered –force to touch it anyway

It will not tap, it tells you why, and it offers two next steps.

Anyone who has done UI automation knows how backwards that is. Traditional frameworks tap anyway and leave you guessing why nothing happened.

Three hard rules it sets for itself

Going through the docs I found the project writes three sentences as inviolable rules, placed ahead of everything else.

First, zero false positives. A report only fires when something is certainly wrong, and when unsure it says nothing. The reason is in the docs: one false positive teaches the agent to habitually add --force, and that costs far more than a missed report.

Second, the platform engine is the only source of truth. What consumed a tap, what got drawn, who covers whom, those answers must come from UIKit, Compose, and View dispatch themselves. It is not allowed to reimplement its own rules that approximate the platform.

Third, every hook must be instrumented. Anywhere a private symbol or framework internal is used, it gets registered and every call gets counted. When a hook goes dead, the conclusion becomes “unknown”, never “broken”.

That answered 4608 times line in ddp doctor is the product of this rule. If an OS update changes an internal structure, the count drops and you immediately know one of your checks quietly went blind.

It wrote the CDP design and killed it the same day

There is a decision record in this project worth reading.

The earliest design had the library in the debug build speak Chrome DevTools Protocol directly, so Chrome and existing CDP clients could connect and the agent would not need a second protocol.

The same day, it rejected its own proposal.

The reasoning is concrete: to imitate a browser it would have to fake a #document > html > body above the native element tree, support CSS selectors, name preferences localStorage, and fill fake values into fields Chrome expects.

Every one of those is a translation layer, and you are the person who has to learn and maintain it. Worse, those translations hide the app’s real structure.

After the switch, the protocol names became native: screen.elements, input.touch, prefs.write. The deleted browser layer was about six hundred lines.

What goes into the app is light

The iOS side is Swift, a bit over 4,300 lines. Android is Kotlin, a bit over 4,100. The CLI is Rust, a bit over 9,700.

The library in the debug build is itself the server, running on a local WebSocket. On Android it uses an abstract socket only the shell user and root can reach, on iOS it listens on 127.0.0.1 and rejects Host headers that are not localhost.

No daemon. Every ddp command is a short-lived process, and recording produces a jsonl file. The same file can be asked different questions repeatedly.

None of that code exists in the release build. On Android it is debugImplementation, on iOS the whole package sits inside #if DEBUG.

The unflattering part

It has 0 stars. Created October twenty-third, now 114 commits, five releases, and five open issues all filed by dependency upgrade bots.

The iOS side only supports the simulator, real devices are not done. The list of things it cannot see is long too: text and images inside SwiftUI Canvas, system dialogs, some covered text, and certain cached drawing inside Compose layers.

I tried one class deliberately: a button that only responds to touch on release. It cannot judge that case, it will only say the touch reaches, then after tap it tells you nothing changed.

That is not a defect, it is honesty. It would rather say it does not know than guess an answer for you.

My read

The real dividing line in this wave of tools is not how many properties they can read, it is whether they dare to stay quiet.

A checker that reports everything teaches an agent to route around it. A checker that speaks only when it should is one an agent can trust as an acceptance condition in a pipeline.

Nine real problems, 2.7 seconds, one thousand and ninety-one bytes of output, one exit code. If this holds steady, agent UI work stops being “write the code” and becomes “write it, then verify it yourself”.

When you have an agent change UI today, do you hand it a screenshot, or do you let it feel the tree?

The conclusion in one line: the benchmarks you use to grade agents today aren’t measuring how people actually use them.

In SWE-Bench Pro, 93.8% of tasks are feature additions and bug fixes, and every task arrives as one complete message. The agent sees the whole picture at once and then starts working.

In real sessions, feature additions are only 19%, bug fixes 26%. Together they don’t add up to half.

So what’s the rest? 6% asking how the code works, 10% general programming questions, plus planning, code review, refactoring, running commands, debugging. None of that exists in SWE-Bench Pro, because that benchmark’s task definition has no such action as “asking a quick question.”

Half the sessions are a single message

They counted every session by number of user messages.

50.9% of sessions have just one message, 16.2% have two, 8.8% have three, and everything from four up to five adds up to under 15%.

So the rest of the analysis only looks at the 33% with at least three messages, which they call long sessions — a single message is a one-shot Q&A. Inside long sessions, the breakdown looks like this: 6% asking about the project’s own code, 10% general programming questions, and the rest scattered across planning, review, refactoring, debugging, execution — feature additions and bug fixes have been diluted down to a small slice.

Run SWE-Bench Pro through the same classifier and you get 55% feature additions, 39% bug fixes, 6% refactoring. That’s it.

Three public corpora, three completely different patterns

They also ran the same labeling on three public agent conversation sets.

SpecStory is a public export of IDE sessions. 521 of its 1,000 are long sessions, the closest to their own data, with a noticeably high share of planning.

DataClaw is a community-shared set of sessions, 585 long ones, almost all execution and short commands. SWE-chat is records of real users in a chat interface, 698 long sessions, predominantly execution and planning.

The three datasets come from different products, different users, different collection methods, so they don’t compare volumes. But one thing is hard fact: calibrate a benchmark against any one of them and you get a different task mix, and that difference isn’t something sample size can wash out.

Not even their own 4,782 count as ground truth. In their words, you have to pick a target first and then declare it; there is no default one.

That sentence is the whole skeleton of the study. Everyone used to assume “building tasks from GitHub issues is what’s real.” This paper says no — issues are just one slice of one population. Swap the population and the data takes on a different shape, and nobody is in a position to call their own slice the standard.

They didn’t build a new benchmark, they retrofitted the old one

Building an interactive benchmark from scratch means throwing away all the repos, environments, and tests SWE-Bench has accumulated over the years. So they took another route: keep the tasks, repos, tests, and original requirements, and only rewrite the user messages.

The method is to split each issue into three ordered requests, with zero invented content allowed. Each request has to be actionable against the code state the previous one left behind, identifiers and code snippets stay verbatim, and after splitting another model checks for any dropped requirements. Of the 731 public SWE-Bench Pro issues, 31 failed validation, leaving 700.

Those 700 are the entire battlefield. Every number from here on comes from them.

The original issue is roughly a thousand words in one message, all crammed into a single block. After splitting it looks like this — the first sentence gives only the main symptom, edge cases wait for the second and third.

qutebrowser had an issue where LinkedIn wouldn’t load, caused by an older QtWebEngine missing Array.prototype.at.

The first request just says “fix LinkedIn failing to load on macOS with QtWebEngine 5.15.2, and catch it with a polyfill.”

Only the second one adds “it must cover versions before 6.3 that lack native support, and both positive and negative indices have to be correct.” The third only then says “out-of-range must return undefined, and only inject when the native method is missing.”

Line the three up and the complete spec from one message has been spread into three rounds of progressive disclosure.

They also injected “ask about the project itself” questions

In real sessions, 6% is asking how the project’s code works, and issue benchmarks have none of that. So they had a model read the repo plus a trajectory where the problem had already been solved, and generate one to three questions.

Each question carries two things: a reference answer, and an evidence script that actually runs. During dataset construction it’s run against a clean repo — if it produces no evidence, or it modifies the repo, the question is dropped.

That rule conveniently eliminates a whole class of questions: ones whose answer isn’t in the code (“why was it designed this way back then”) are physically impossible to produce.

The qutebrowser task later got a companion question whose answer named two config entries and touched five files.

After splitting: cost doubles, scores don’t move

Here’s the most valuable part of the whole paper: four models, 700 tasks, three feeding modes, three runs of each.

Single-shot means throwing the original issue over as one message. Split means sending the three requests in sequence, with nothing added in between. Split plus Q&A means also adding those repo questions, with an optimizer choosing where they go.

The result: splitting raised each model’s cost 2.0 to 2.6 times.

Same repos, same tests, not a single added requirement — all the extra money went into “requirements arriving in batches.”

Scores barely moved. GPT-5.6 Terra stayed flat; the other three dropped 4 to 5 points on average, roughly the same as the variance from running the same setting three times.

They also ran a control: splice the three rewritten requests back into one message and send that. All three GPT models’ cost and scores landed right back in the single-shot bucket. So the expense is in the act of sending three times, not in the rewording.

Splitting gives you intermediate checkpoints

Run one long requirement to the end and you get a single final score, with right and wrong smeared together — if you want to know which step collapsed, you have to go dig through the trajectory yourself. Split into three steps and you can run the tests after each one, scoring only against the requirements revealed so far, and the failing step is visible at a glance.

In an ablation over 64 tasks, the pass rate and test pass rate climbed with each request. One problem becomes several verifiable checkpoints, and diagnosis gets much clearer.

This is probably the only benefit of splitting. Beyond it, splitting is pure cost.

What it hasn’t solved

They only generated two kinds of messages: split requirements, and questions about the repo. Planning, review, execution, and debugging without a fix, all of which show up in real sessions, still have no generator — and for most of them, even “how do you automatically judge correct from incorrect” hasn’t been worked out.

One more thing: every message is frozen before the run starts. Reproducibility is real, and so is the fact that the “user” never changes their mind in response to the agent.

The research stops there. The things they listed as not done go on for a while, right down to admitting a weakness like “the classifier has no human-labeled accuracy set.”

What this means if you write code

When you look at a model leaderboard, you assume that number means “how good it is at writing code.” What this paper says is that the number also contains something you’ve never been choosing: the pace at which it’s asked to work.

Same model, requirements delivered all at once versus in three batches — more than double the cost, roughly the same score. So how you ask for things on your own project is a separate question, and it’s the one you control. My habit is to write background, goal, and constraints all in one message. Reading this hasn’t changed my mind. When cost actually becomes the sticking point, the first thing I look at is how many extra steps it took, not whether it got the answer right.

One fun corollary: if every benchmark measures “everything delivered at once,” the models being trained will get used to that pace too, and then nobody can measure the follow-up questions, the course corrections, the progressive disclosure that real sessions are full of.

Think back to your last few agent sessions — how many were solved in one message, and how many took several rounds back and forth?

That “six platforms” claim needs unpacking. Android, iOS and HarmonyOS are officially supported. Web and WeChat Mini Programs are marked Beta. macOS is Alpha. The docs say so plainly, so don’t mistake a trending spot for maturity.

It gets confused with Compose Multiplatform most easily because both let you write Compose. Underneath they’re two completely different roads. I dug through the repo, and the numbers add up.

One draws everything itself, one rents the drawing

Compose Multiplatform draws with Skia. You write a Box, and it takes a brush and paints the pixels itself. All six platforms come out identical, because it’s the same brush.

Kuikly doesn’t draw. It translates your Box into each platform’s own View: View on Android, UIView on iOS, ArkUI components on HarmonyOS. The rendering job is outsourced to the system.

The official post announcing the Compose DSL puts it bluntly. The original wording: “CMP adopts Skia self-rendering, while Kuikly Compose DSL can directly reuse the existing mature native rendering system, delivering an experience fully consistent with the native system, such as scrolling feel, text input, animation and accessibility.”

Both the payoff and the price are in that sentence. Scrolling feel, text cursors, screen reader output, the system hands you all of it, so you don’t have to simulate it yourself, and that simulation is exactly what drains a self-rendering framework. The price is that every platform needs a translation layer, and whatever the system looks like, you follow.

Here’s how the numbers add up

I cloned the repo and counted lines by directory.

Shared Kotlin comes to 209,000 lines. The core module is 33,000 of those, and the other 175,000 sit in the compose directory.

The per-platform renderers total 155,000 lines. Android is 31,000 lines of Kotlin, iOS 37,000 lines of Objective-C, HarmonyOS 51,000 lines of ArkTS plus C++, Web 35,000 lines of Kotlin.

One shared codebase, four platform renderers. That ratio is the fixed cost of this road, not sloppy work by Tencent. On the CMP side the bill is zero, because there’s only one brush to maintain.

The HarmonyOS 51,000 deserve a closer look. ArkTS accounts for only 5,900 of them, and the remaining 42,000 are C++ and C. Calls into ArkUI have to go through the native layer, and ArkTS alone can’t carry that volume. It also shows where native rendering leads: the deeper you go, the closer you end up to the system side.

Those 175,000 lines aren’t theirs

The compose directory is forked from JetBrains’ compose-multiplatform-core, based on Compose 1.7.3.

The README says as much: they renamed the package from androidx.compose to com.tencent.kuikly.compose, commented out what they don’t use, and chose not to upgrade all the way so they can track upstream later.

So running Compose isn’t compatibility, it’s Compose moved over and modified. The official claim of “compatible with more than 95% of Jetpack Compose APIs” holds because physically it’s the same code. What changed is the layer that connects it.

It had its own DSL first, Compose came later

This part is easy to miss. Kuikly had no Compose at the start. It shipped its own DSL, building UI with ViewBuilder, marking pages with the @Page annotation, and handling state through the observable decorator.

Both styles coexist in the demo directory: 300 pages in the homegrown DSL, 123 written in Compose. The count tells you which is primary. Compose is a layer grafted on later, not the foundation.

I opened one homegrown DSL page. It looks like this, a completely different route from Compose.

@Page("NetworkExamplePage")
internal class NetworkExamplePage : BasePager() {
    private var output by observable("")
    override fun body(): ViewBuilder = { NavBar { attr { title = "网络请求示例" } } }
}

Same job: Compose writes @Composable plus recomposition, the homegrown side writes a declarative tree. Keeping both alive means the framework maintains two front ends.

The real work happens in the middle layer

Recomposition keeps adding, removing and changing nodes, and those changes have to reach the rendering backend through an Applier. Android and Skia both have official implementations. Kuikly had to write its own.

Its KuiklyApplier extends AbstractApplier. Each KNode hangs a LayoutNode for layout on one side and a DeclarativeBaseView for rendering on the other, one to one.

The trouble is coordinate systems, and the example in the official docs gives it away in a single line.

Box(Modifier.padding(10.dp).size(50.dp).background(Color.Blue))

background is bound to the inner coordinate system, so it paints 50×50. With padding added, the outer boundary is already 70×70. But Kuikly’s View has only one frame, so whichever number you put in is wrong.

Fill in the outer one and the background stretches across the full 70×70, too big. Fill in the inner one and the size is right but the padding offset is gone, so every child node is misplaced. Creating a View per Modifier is worse: three Modifiers means three levels of nesting, and any real page blows up the hierarchy.

The rule they settled on: the drawing coordinate system decides Size, the relative position decides Position. One sentence, but behind it is the alignment of two rendering semantics, and that’s where frameworks like this actually spend their time.

Eleven build scripts

The repo root holds eleven Gradle scripts, running from Kotlin 1.3.10 all the way to 2.1.21, each paired with its own identically named settings file.

Not out of a love of tidiness. The Kotlin Multiplatform Gradle plugin API has kept changing over the years, one set of scripts can’t serve every version, so they keep one per major version and switch when needed.

That detail is more convincing than any performance claim. For a large company building a long-lived framework, the biggest cost is that someone is still on an old Kotlin three years from now, and you have to keep it running for them.

One clause in the license worth reading

The LICENSE is MIT at its core, with one extra restriction. The key phrase is may not modify, extend, or create derivative works, limited to the purpose of adding or enabling dynamic code loading / live updating capability, and only with Tencent’s prior written consent.

In plain terms, dynamic delivery and hot updates you cannot build yourself without Tencent’s written approval.

And dynamic delivery happens to be its biggest selling point. Compose Multiplatform produces a build at compile time, so one changed line means a new release. Kuikly can ship pages as assets and have the change take effect immediately. For domestic businesses that gap matters more than any performance number.

The repo’s license field on GitHub shows NOASSERTION for exactly this reason: it isn’t a standard license.

Who should use it

The official validation data: more than 30 internal apps, scenarios at 500 million daily active users, over 20 external teams onboarded including Kuaishou, Founder Securities and MiniMax. On migration cost they write that 50-plus standard Compose pages moved over in one pass, plus 73 AI-generated feature demos that compiled and ran with zero modification.

If you need HarmonyOS or WeChat Mini Programs, this is the least painful road right now, since CMP doesn’t cover them. If you only target Android, iOS and desktop, maintaining four renderers yourself isn’t a good trade. Those 155,000 lines become yours to maintain.

What I verified stops at project structure and line counts, plus the compiler boundary. The Gradle config works, 13 modules in 2m49s; the core module also compiled into a macOS arm64 native library, 1m06s, with JDK17 and Kotlin/Native and no Android SDK needed.

I didn’t build complete apps for the six platforms. That needs Xcode with CocoaPods and DevEco Studio, one setup each.

When you pick a cross-platform framework, do you first ask how many platforms it covers, or how many releases a single change costs you?

One thing has to be said up front. This version is not the latest one on npm yet. A plain install still gives you 0.2.1-rc.2, so you have to pin the version number by hand.

npm install -g @deepseek-ai/dsh@0.2.2-alpha.2

Skip that version number and nothing I describe below will be visible to you.

Then I started it, and there was the problem. Three consecutive disabling profile plugin row lines in the log. Three of the things I had installed were taken away.

npm had also flagged something during the install: install scripts for five packages were blocked, including two native modules, node-pty and koffi. I stared at it for a while and started the app anyway. The web UI opened, the model list loaded, nothing seemed broken. I filed that away to look at later if something misbehaved.

Three lines hit me the moment it booted

Here is the log, verbatim.

dsh: disabling profile plugin row "plugin-market":
  Plugin @deepseek-ai/dsh-plugin-market@0.2.1-rc.2
  is incompatible with dsh 0.2.2-alpha.2:
  requirements {"@deepseek-ai/dsh-plugin-manager":"0.2.1-rc.2",
                "@deepseek-ai/dsh-settings":"0.2.1-rc.2",
                "@deepseek-ai/dsh-tools":"0.2.1-rc.2",
                "@deepseek-ai/dsh-typert-protocol":"0.2.1-rc.2"}

The three that got disabled were ui-agent-team, plugin-market, and tool-plugin-market. The last two are actually the same package, referenced by two different config rows.

The requirements block is the whole story. It reads "0.2.1-rc.2". No caret, no tilde, four exact version numbers. And the four internal packages at runtime had already moved to 0.2.2-alpha.2.

Exact match fails, plugin gets rejected. DeepSeek Harness handles it cleanly: it does not load the plugin, it does not throw, it prints one warning line and keeps going.

That design is actually right. Letting a plugin that declared “I was only tested against these versions” run on a newer runtime makes the eventual crash far harder to diagnose. Rejection beats loading something broken.

The cost lands on the user though. You bump a version, things you installed disappear, and because it is a warning rather than an error, it is very easy to miss.

The fallout spreads to the plugin market

I had a custom plugin index configured. It lives at line 12 of ~/.dsh/profiles/web/cordis.patch.yml and points at a local static server.

After the upgrade I opened Plugins → Discover and got one line in red:

Could not read the index sources.

There was a Retry button next to it. Clicking it returned the same line.

My first instinct was the static server. lsof -iTCP:3489 came back empty, so the service had died at some point. I assumed that was the whole story, brought it back up, and curl returned 200 with a 3,764-byte index.json sitting there.

Back to the browser, clicked Retry. Same red line.

Same red line on the second try, and only then did it click: reading the index is itself an action performed by plugin-market. The index source was fine. The thing that reads it was gone. An empty page either way.

So there are two layers stacked here. On the surface the index source was down. Underneath, the plugin that reads it had been disabled.

I also tripped over a hole of my own making, worth noting. The serve.py I use for reproduction hardcodes its access log at /tmp/market/access.log, and I had cleaned that directory out. Every incoming request threw before it could respond, so curl returned exit 52 with an empty body. Creating the directory fixed the requests.

There is an official switch, buried in the warning text

The tail of those three warnings does give you a way out. It mentions dsh plugin allow-version, or the plugin manager, to grant an exemption for an exact version.

I read the help first. The plugin subcommand documentation for DeepSeek Harness does not mention this at all. It only says the remaining arguments are forwarded to pnpm.

So I just ran it, and the usage fell out on its own:

dsh: Error: usage: dsh plugin allow-version <package@version>
                   --dsh-version <exact> --accept-risk

Filling that in, one exemption per plugin:

$ dsh plugin --profile web allow-version \
    "@deepseek-ai/dsh-plugin-market@0.2.1-rc.2" \
    --dsh-version 0.2.2-alpha.2 --accept-risk
dsh: allowed @deepseek-ai/dsh-plugin-market@0.2.1-rc.2 for DSH 0.2.2-alpha.2

The exemption is scoped to one package at one version. A different version and you have to grant it again. After restarting DeepSeek Harness, the three warning lines were gone from the log, Discover read the index immediately, both plugins listed properly, and category and tag filters were back.

One note: --accept-risk means what it says. I got lucky here and the plugin ran without incident. That is not a guarantee.

What the new interface looks like

The plugins page now has two tabs, Installed and Discover. Installed splits into two sections.

The top section is Built-in plugin settings, four entries. Subagent governs recursion depth, count, and model. Web search configures the DeepSeek search source. Agent loop controls how the agent dispatches tool calls. Shell limits how long a single command may run and how much output it may produce.

The bottom section is Experimental plugins, five entries, each with a toggle:

Agent teams lets the agent split work across named teammates that share a task board and report results back.

Voice input transcribes locally with SenseVoice; the first use requires installing dependencies.

Custom plugin indexes is what adds the Discover tab to Plugins, letting you browse and install from index sources you add.

Auto authorization review is a new review mode: before each tool call the model checks it against your original request and batch-approves the ones that comply.

Change requests & worktrees tracks each session’s change requests along with their check and review results, and can start new sessions directly inside a Git worktree.

Of the five, the first two are on by default and the last three are off.

Two things that actually changed on the plugins page

After all that, it is worth looking back at what this upgrade actually delivered.

The plugin detail page now renders the package’s own README. Click into an experimental plugin and you get the full documentation, with an English and Chinese toggle, a summary, a table of contents, and a section called Use this package further down.

More interesting is that the same page breaks the bundle into its 5 components, listed one per row, each with an icon, a one-line description, a short name, the full package name, and its own toggle on the right.

Take the Change requests & worktrees package. Expanded, it is five parts.

Change requests, GitHub change requests, Session change requests, Worktree service, Change request panel. The top of the page reads Components 5 total · 5 off.

The bottom also shows provenance: Code source is Built in, current version 0.2.2-alpha.2.

This is far clearer than the old “one plugin, one switch” model. You can inspect each part of a bundle and flip them independently, and you no longer have to open a config file to find out what is installed.

Where I land on this

The interesting part of this whole episode is not the trap I fell into. It is the design tradeoff the trap exposes.

An exact-version lock keeps the plugin ecosystem safe, and the price is that any runtime upgrade can invalidate a batch of plugins at once. It is especially visible between alpha and rc: bump a few internal packages and every plugin declaring a dependency on them drops offline.

DeepSeek Harness provides an exemption switch, but the default path is rejection. The bet it is making is “better to load less than to run something broken.”

For people building plugins, this means reissuing a version declaration every time you follow a runtime release. For people using plugins, it means knowing what you installed before you upgrade, because afterwards you may not even be able to tell what went missing.

DeepSeek’s official release notes for 0.2.2-alpha.2 also mention that a failed hot plugin update will attempt to restore the previous version. That mechanism protects updates already in flight. It cannot save the version check that runs before startup. The two pieces of logic do not touch each other.

This release also lists a few things I did not verify: subagent_oar can hand standalone tasks to a local Codex or Claude CLI, and the developer tools stats plugin can show context, cache, model, and tool timing by turn. The first one sounds the most interesting, but I could not find an entry point in the UI, so it likely needs a separate install and I left it alone. Same for the hot-update rollback: official wording, and I did not construct a failure to test it.

Do you check which plugins you have installed before upgrading your toolchain? Or are you like me, finding out only after things are gone.

References

• DeepSeek Harness v0.2.2-alpha.2 release notes: https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.2.2-alpha.2
• Test environment: macOS arm64, DeepSeek Harness upgraded directly from 0.2.1-rc.2 to 0.2.2-alpha.2, npm global install

JetBrains put that experience into the reasoning of their October 27 blog post. Starting with 2026.3, the built-in terminal in their IDEs no longer runs JediTerm. It runs libghostty, the core library behind the Ghostty terminal emulator.

Shift+Enter starts a new line in your prompt instead of sending a half-written message.

That one clause, “instead of sending a half-written message,” says plainly what the default behavior has been for over a decade.

What makes a terminal library good enough to replace a thirteen-year-old one

JediTerm is JetBrains’ own pure-Java terminal emulator. The repository opened in January 2013 and has been maintained ever since. It handles SSH and PTY. It works, and it is stable.

The problem is that it does not support the batch of modern terminal protocols that came later.

The official framing is that TUI applications increasingly depend on protocols JediTerm never supported, and that gap used to feel like a minor annoyance. The experience differed from other terminals, but not enough to warrant a bug report.

What changed is what runs inside the terminal now. Claude Code, Codex, Neovim, tmux, assorted system monitors and dashboards all push the terminal far harder than a shell prompt ever did.

libghostty took over parsing and terminal state. The IDE still handles rendering, along with higher-level features and integrations. The official post is clear about the split. This is not a rewrite of the whole terminal.

A word on where libghostty itself comes from. It is written in Zig and exposes a C ABI. Both Ghostty front ends, the macOS one in Swift with AppKit and the Linux one in Zig with GTK4, consume it. Mitchell Hashimoto says it plainly in the project introduction: this is something he works on in his free time, not a full-time job for anyone.

Shift+Enter finally makes a new line. Why did it never work before

The old protocol for keyboard events in terminals only distinguishes which key was pressed. It cannot tell you whether Shift, Ctrl, or Alt was held, and it does not say whether a key went down or came up.

The Kitty keyboard protocol fills that in. Terminal applications can now distinguish Enter, Shift+Enter, and Ctrl+Enter, and can ask to receive key-release and repeat events.

Vim uses the older xterm modifyOtherKeys, which is supported now as well.

For anyone who spends the day with agents in a terminal, this produces two changes. A newline is a newline, and half a sentence does not fly off on its own. Shortcuts built from Ctrl, Shift, and Alt combinations reach the application intact.

The official post notes one detail. The old setting that sent Esc + CR on Shift+Enter is no longer needed, and is ignored if set.

Switch to Dark mode, and the tools inside the terminal follow. Why didn’t they before

The experiential gap here is obvious.

When the IDE switches to dark mode, programs inside the terminal have no way of knowing. They guess. Guess wrong and you get dark text on a dark background, or a bright terminal panel inside an otherwise black IDE. Fixing it means hand-configuring one tool after another.

Now the terminal answers the dark/light query, CSI ? 996 n, drawing the answer from the current IDE theme. When the theme changes it broadcasts a notification through mode 2031.

Claude Code, OpenCode, Pi, Neovim, and tmux subscribe to these notifications, so most tools switch along with the IDE without any configuration on the IDE side.

Palette queries expanded too. JediTerm handled only OSC 10 and 11. The new terminal also answers OSC 4 and Kitty’s OSC 21. Programs can set extended palette colors 16 through 255 with OSC 4, while colors 0 through 15 stay under the IDE theme’s control.

Those garbled control characters in the terminal. Why did they show up at all

The official post says the new engine handles close to 50 control sequences that JediTerm either ignored or misread. Here are three that map to everyday experience.

REP (CSI Ps b) is what ncurses uses to compress runs of repeated characters, seven or more of the same. Lines used to render with characters missing because this was not handled.

Colon-separated SGR colors (38:2::r:g:b): the old terminal printed the colons literally and merged the digits into the wrong attribute. If you have ever seen a stray 38:2::255:0:0 string appear in your output, that was this.

Unknown APC, SOS, and PM strings used to be printed as ordinary text. They are now silently dropped.

A batch of edge capabilities came along as well: left and right margins, protected areas, tab stop control, insert mode, XTSAVE/XTRESTORE, Kitty’s scroll-and-clear, and X10 mouse reporting. Cursor blink mode used to blink no matter what you set. Now it listens.

I pulled the library out and ran it myself

Everything above is the official account. What follows is what I verified on my own machine.

First the before-and-after. My machine has IntelliJ IDEA 2026.2.3 installed. Under Contents/lib you find intellij.libraries.jediterm.core.jar, intellij.libraries.jediterm.ui.jar, and pty4j. A find for ghostty returns nothing at all.

Then I pulled the 2026.3 EAP build from JetBrains’ release endpoint. It is 1510 MB, and mounting the disk image lets you inspect it without installing anything. The addition is this:

Contents/plugins/terminal/libghostty-vt/macos-aarch64/libghostty-vt.dylib
-rw-r--r--  1.9M  Oct 23 13:10
Mach-O 64-bit dynamically linked shared library arm64

A 1.9 MB native dynamic library, shipped under the terminal plugin in the plugins directory rather than the main lib. What surprised me is that both JediTerm jars are still present in 2026.3, which matches the official claim that you can switch back.

The library exports 205 C symbols, all prefixed ghostty_. Roughly by module: terminal 31, render 22, key 21, mouse 17, kitty 16, followed by snapshot, color, sgr, selection, search, and osc.

The dylib also embeds a complete ABI type description as JSON, opening with "library_version":"0.1.0-dev".

Then I took the dylib out of IDEA entirely, wrote a few dozen lines of C to dlopen it, and called ghostty_build_info:

VERSION_STRING  rc=0 len=9  "0.1.0-dev"
VERSION_MAJOR/MINOR/PATCH  0.1.0
SIMD=on  KITTY_GRAPHICS=on

It ran. That is more worth saying than whether the engine changed at all. What JetBrains shipped is a standard C ABI library that any program can link against. It needs no JVM and no IntelliJ platform.

I also checked the rollback switch the post mentions. Unpacking terminal.jar, the key terminal.use.ghostty.emulator is genuinely present in TerminalEmulatorType and in plugin.xml. You find it under Help, then Find Action, then Registry.

What this has to do with people writing Kotlin and Android

If your day is an IDEA window with a terminal running Claude Code, with gradlew and adb alongside, this engine swap moves the floor you walk on every day.

Three things you feel directly. Shift+Enter stops sending half a message. Switching to Dark mode brings the terminal tools along. The control characters that used to come out as garbage no longer pollute the output.

There is another set the library can already parse but the IDE side has not wired up yet, which the official post lists: OSC 52 clipboard, desktop notifications, ConEmu progress bars, Kitty graphics, and styled and colored underlines. The point is that parsing is no longer the bottleneck. What remains is on the IDE side.

The most practically useful of those is desktop notifications, where a program running in the terminal can raise a notification when it finishes a task, such as Claude wrapping up a prompt and waiting on you. That one is not connected yet. The post says it will arrive faster than it did under JediTerm.

One more thought

Replacing a thirteen-year-old in-house terminal with someone else’s library is a more interesting decision than any of the technical details.

JetBrains is capable of continuing to improve JediTerm. What they chose was to acknowledge the gap. The modern terminal protocol layer is no longer something you bolt on in passing, and catching up from scratch loses to standing on a library built specifically for the job.

And libghostty was always meant for other people to use. The Ghostty documentation states the architectural goal plainly: let other terminal projects build on a shared core, focus on higher-level features and the interface, and skip reimplementing terminal emulation.

At the end of the post JetBrains thanks Mitchell Hashimoto and Tim Culverhouse by name, noting that over the past months libghostty also picked up the capabilities JediTerm users depended on, which is what made the switch possible.

Read that backwards and it holds up too. A library treated as a side project added a large customer’s decade of requirements in order to catch them.

What is your daily terminal now, the one built into the IDE, or a separate Ghostty, iTerm, or Warp window? If the IDE terminal genuinely catches up to standalone terminals on features, would you still open a second window for it?

References

• JetBrains blog: The Terminal in JetBrains IDEs Now Runs on libghostty (October 27, 2026)
• Ghostty documentation, About: https://ghostty.org/docs/about
• The libghostty ecosystem list: https://github.com/Uzaaft/awesome-libghostty
• libghostty build_info header: https://github.com/ghostty-org/ghostty/blob/main/include/ghostty/vt/build_info.h

While I was running that gauntlet, on October 13, Google published an update on the Google Play product blog titled New on Google Play: More ways to create, discover, and play.

There was this line in it.

Using Google AI Studio, you can vibe code a custom Android app. Since many of these apps start out as personal projects, through Google Play you can now launch these personal apps on your own device. This means your creations stay private, secure, and separate from the public store catalog. You only need your standard Google account to do so — no developer account required.

In plain terms: say a few sentences to an AI to generate an Android app, hit publish, scan a QR code, and the app is on your phone. No developer account, no $25, no review.

Same Google Play, two sets of gates.

What the process actually looks like

Play Console’s help center opened a new page titled Personal library apps in Google Play, and it spells the steps out in detail.

Open Google AI Studio in a desktop browser and sign in with your personal Google account. Click New app, select Build an Android app, and type in what you want. Once the preview generates, click Publish in the top right corner. The first time around you connect your Google account, then click Create app.

A few minutes later, a QR code appears on screen.

Your phone is signed into Play Store with the same Google account. Scan the code, and it installs.

If you would rather not scan, the path is: in the Play Store app, tap your profile, then Manage apps & device, and find Your personal library. Everything you built yourself is in there. Tap install. Updates work the same way, go back to AI Studio, change the prompt, click Update app, and the phone updates on its own.

The line I most wanted to confirm through all of this was no developer account required. The official help page puts it even more bluntly.

You only need a Google Account to get started.

One sentence, one account, one QR code.

People who already have a developer account cannot use it

This was the most surprising thing I read, and the official help page devotes a whole Q&A to it.

Owners of Google Play Console developer accounts will need to use a different Google Account to use this feature.

Meaning if you already have a Play Console developer account and want to use this feature, you need a different Google account.

Google does not explain why. My reading is that the account systems need to stay separated. Nothing in your personal library can mix with apps you submit as a developer in Play Console, because otherwise one account could both submit public apps and bypass review to install private ones, and the boundary would blur. That is my inference, not something Google wrote.

For developers the experience is odd though. You paid $25 to publish properly, and now when you want to knock together a small tool for yourself, you have to register another account.

The word “private” needs quotation marks

Google stresses the private part repeatedly. Not listed in the public catalog, not appearing in search results, charts, or recommendations, installable only by you.

That does not mean Google cannot see it.

The last section of the help page is explicit. When you create, modify, or publish an app in AI Studio, the tool transmits the app’s package and creation metadata to Google Play, including prompts, AI-generation indicators, software dependencies and SDKs, user-facing strings, and source code.

For what? Google lists four uses: safety and security scanning, abuse prevention, policy compliance, and training and improving automated app safety classifiers.

So every prompt you write and every line of Kotlin the AI produces passes through Google’s scanning pipeline. What gets waived is manual review and the publishing workflow, not data collection.

I would recommend reading the original text on this one, because “private” in Chinese tends to get read as “nobody is watching.”

Review is waived, but the rules are not

The same page lists explicit content prohibitions, and personal apps get no exemption.

No banking, loans, cryptocurrency, real-money gambling, or government services, the high-risk categories. No requesting sensitive permissions like accessibility services, SMS and call log access, binding notifications, or requesting install packages. No infringing third-party intellectual property, no impersonating existing brands, government entities, or individuals. No malware, spyware, phishing, unauthorized data collection, hate speech, sexually explicit material, or violence.

The consequence for violations is removal from AI Studio, and repeated violations terminate your access to AI Studio.

Waiving review only skips the queue and the manual check. Not one of the lines actually disappears. The difference is that Google used to stop things before they shipped, and now it deals with them after you walk into the wall.

What kind of project it generates

This part matters if you write code.

AI Studio generates a standard Gradle project, with build scripts in Kotlin DSL via build.gradle.kts, a UI layer of Jetpack Compose with Material 3 theming, single-activity architecture with ViewModels and data classes, plus AndroidManifest, drawables, strings, and the other resource files.

Enable Firebase and you also get google-services.json, firebase_applet_config.xml, and firestore.rules. The agent adds dependencies from Maven and Google repositories on its own.

You can download it as a ZIP and import it into Android Studio to keep going.

The limitations are stated just as plainly, four of them.

Client side only, no server component, so anything involving secret management, multiplayer, or Google Workspace APIs is out. Single activity and single module, so structures beyond that scale do not work. Kotlin and Jetpack Compose only, Java and XML layouts are unsupported. No NDK, so C and C++ cannot come in. Wearables and Android TV are unsupported too, phones and tablets only.

One detail I found interesting: the emulator in the browser runs entirely in the cloud, so you do not need the Android SDK, Android Studio, or a local emulator installed. But it does not support camera, NFC, or Bluetooth, GPS is simulated, and there is no Google Play services, so Google Sign-In and Maps do not work in the emulator and need a real device to behave.

The ceiling on this kind of project is clear. Fine for personal tools, small apps, prototypes. Not for stacking a large codebase on top.

One button, two exits

For me the most interesting detail in all of this turned out to be the Publish button in AI Studio.

It has two exits. One leads to the personal library, zero gates, installable only by you. The other leads to the internal testing track in Play Console, which needs a $25 developer account and a complete developer profile, and reaches up to 100 testers.

Same screen, same generation run, and the rules differ that much.

Google also lays out the path forward in the blog post. In the coming months you will be able to share personal apps with a small circle of friends and family, and at that point the app goes through a Trust & Safety review first. If you eventually want the whole world to use it, you can upgrade to a full developer account, and every app in your personal library migrates to Play Console as a draft on the internal testing track.

My sense reading that section is that Google has split “build a little tool for myself” and “build a product for other people” into two entirely different entrances, with an upgrade path between them.

Previously only the latter existed. If you wanted to put something AI had just generated onto your own phone, you first had to become a developer. Now the former has its own door, and the price of entry is admitting you are not a developer.

This feature is not available in China yet

It is in beta, open to users 18 and over in the US, rolling out over the coming weeks. Play Store app version 53.5 or later. Other countries get “near future,” with no timeline from Google.

I am not in a supported region, so I never touched the feature. Every process, limit, and quote above comes from three official documents: the October 13 Play product blog, the Play Console help page Personal library apps in Google Play, and the AI Studio Android build documentation. Which sentences are official text and which are my inference is marked in the body.

So here is the question.

If a friend in the US can say a few sentences to an AI and have an app installed, while you are still grinding through 12 testers for 14 straight days, would you register a plain Google account to route around it? Or was that $25 and those five gates always buying the right to let other people install your app?

Think one layer down. What Google knocked down this time is only the half of the wall labeled “for my own use.” The other half has not moved. When enough vibe coders want to share with friends, does that Trust & Safety review become the new five gates?

Do you have one of those small tools that only you would ever use, but you never bothered to open an account for it? If a single prompt could put it on your phone right now, what would you build first?

So I pulled the whole repository down and counted, and that is not what it is.

The documentation is 1,778 lines, fourteen attack-surface manuals plus the process writeup. The validators themselves are 1,645 lines, with 142 explicit error checkpoints across the two of them. Add 1,392 lines of tests and 461 lines of schema and the validation side totals 3,498 lines.

Documentation for finding bugs: 1,700. Code for stopping it from making things up: 3,500.

The funnel they publish

The Cloudflare blog post about their own vulnerability harness has a set of numbers.

The discovery stage generated 20,799 raw candidates. 12,057 survived independent validation. Merged with findings from another harness, the central pool reached 13,841. Deduplication collapsed 5,442. Another 1,154 were routed out as wrong-repo or low-risk and fed back into the system.

What reached engineers: 7,245. From 20,800 down to 7,200, six and a half out of ten dropped.

They write it plainly in the post. The core metric of this harness is not recall. It is keeping the number of unconfirmed findings in front of real humans as close to zero as possible.

Their words: the architecture has to be a relentless filtering funnel.

Two models checking each other

One line in that post I read several times.

They run discovery on one model and validation on an entirely different one. The reasoning is spelled out. If you make model B judge model A’s output, B looks at it through a completely different set of weights and training data, which makes it an unbiased adversarial party whose only job is to tear apart A’s assumptions.

The same post has another line worth quoting. Point different models at the same target and each turns up a different share of the bugs.

There is also a number buried in the body text. In their own testing, a single run found roughly half the vulnerabilities that repeated runs found in total.

Half. They said that themselves.

I went at the validators with bad data

Documentation alone proves nothing, so I made the code run.

Its bundled tests total 65 across the two validators, all passing, zero failures. The test cases are interesting in themselves: rejecting Unicode format controls, rejecting a FIFO without blocking, rejecting a symlink without following it, rejecting deep nesting without blowing the stack, working under a constrained heap.

Then I wrote data designed to hit it.

I wrote a needs_validation record the way AI most typically cuts corners, and threw in a severity field for good measure. The validator came back with two errors. One said the field should not exist, the other said a record of this kind must not contain severity.

The same mistake blocked from two directions at once.

I wrote the trace field as a single sentence of prose with no concrete location. The validator told me it expected an object and got a string.

The most humbling part was the first attempt. I thought I had read the schema, and my very first submission was wrong in four places. The trace kind can only be entrypoint, propagation or sink, and I wrote source.

An agent that patiently read all 461 lines of schema still got it wrong four times on the first try. This is not nitpicking. It is simply not fakeable.

What it handed back was an empty array

The validators are the outer layer. The real question is what an agent produces when you point this standard at a file.

I picked a target I could check against, the 773-line validator itself. The instruction was a single line: every candidate must supply six elements, drop any that is missing even one, do not pad the count.

It ran for two and a half minutes and handed back an empty array.

Zero candidates.

But it did not stop there. It listed ten things that looked like vulnerabilities and explained, one by one, why they are not. A few you can check yourself.

Terminal injection. Validation failures print the user-supplied path to stderr, which looks like ANSI escape injection. It traced line 98 and found every message passes through an escape function covering control characters, format characters and surrogates. It also noticed safeQuote clips to 256 characters before escaping, and that clipping can split a surrogate pair in half, and that half a pair is itself inside the escape range.

Resource exhaustion. The 5 MiB limit is checked twice. Once with fstat on the file size, once with a running byte counter during the read, so a file that grows mid-read still gets caught. Depth 64 and array size 1000 are likewise checked both on the raw text and on the parsed value.

Symlinks and FIFOs. The file is opened with O_NOFOLLOW and O_NONBLOCK, and if the platform lacks either constant it refuses to run rather than degrade. It then fstats the descriptor rather than the path, so there is no open-then-reopen race.

Two more in a sentence each. The ReDoS regex compiles a pattern from the bundled schema, not from findings.json, so the attacker controls the subject string and not the pattern. Every attacker-controlled key is read through a hasOwn guard.

None of the ten held up. Then it closed with four engineering observations, clearly labelled as suggestions rather than vulnerabilities: exit code 1 is overloaded so unsafe input and failed validation are indistinguishable to a caller; the catch discards the exception; the schema regex is recompiled per string; UNSAFE_DIAGNOSTIC_CHARACTER carries the /g flag.

Why an empty result is more convincing than a finding

An agent required to supply evidence will hand in a blank page when the code is watertight, rather than invent a finding.

I will not overstate that. I have one sample, and this code was written by a security team. It does not prove the workflow finds real bugs in genuinely vulnerable code.

What it does prove is the other half. The workflow stops things that look like problems from being packaged as vulnerabilities.

And that half is the genuinely hard part. Finding things is not hard, models love to talk. The hard part is getting them to shut up when they should.

The three walls they hit

The blog post also covers what broke when they went from a local skill to fleet-wide scanning.

The first wall is context exhaustion. An hour in, the window fills and the model starts eating its own memory, and the bug it chased all morning is gone. Their fix is a hard engineering constraint: each agent’s job is cut extremely fine, keeping context below 25 percent of the total window. Fill it and the model starts hallucinating, which is the original wording.

The second wall is speed, which means running in parallel. They found some models do not proactively fork sibling agents, so they added a request mechanism: hit a path outside scope but worth pursuing, and you can fork a sibling. That accounts for 9 to 20 percent of all tasks.

The third wall is the most mundane. One rate-limit error or a connection hiccup and hours of work are gone.

Same battlefield as verification

Last month the Flutter team published a post whose core claim was that code generation stopped being the bottleneck, and verification is the bottleneck now.

Writing about Compose last week, what I saw was JetBrains opening the running application to an agent so it can change code, reload, screenshot and confirm on its own.

Cloudflare takes a third path. It does not optimize the speed of verification. It turns verification itself into a gate you cannot slip past.

What all three have in common is clear. What is scarce is not the ability to make AI do work, it is the ability to judge whether the work is right. And on that second half, the mainstream approach is still handing judgment back to another AI.

How to use it

The skill installs directly. The README says npx skills add, and it works in any agent skill directory as long as your agent supports parallel sub-tasks.

One caveat. It requires an OS-enforced sandbox: no external network, empty environment, read-only target, writes only to its own scratch directory, explicit resource limits. Without that, the skill refuses to execute target code and downgrades every conclusion to needs-validation.

I originally meant to run all six phases in my own dsh and got stuck on credentials, since headless mode cannot reach the API key. I ended up running the discovery phase with an independent agent, and the validation phase never started because there were zero candidates. So the numbers here come from three sources: the funnel from the Cloudflare post, the tests and validator experiments from my own machine, and the audit result from one independent agent.

In your team’s code review today, is a human reading AI-written code, or is AI reading yours?

That line in the title is not a hook. This release changes a fair amount, but none of it points anywhere new. The thing that actually moves cross-platform development forward went out quietly two months earlier.

The conclusion up front: 1.13 has exactly one new feature, and the rest is fixes. That is enough on 1.13.

1.13 is basically this

Desktop ComposePanel in SwingGraphics mode can now pace frames to the display refresh rate. Off by default. Turn it on with this property.

System.setProperty("skiko.swing.frame.pacing", "true")

iOS gained UIKitInteropSafeAreaInsetsPolicy, which controls how much of the safe area an embedded UIKit component sees.

The only cross-platform change: AnnotatedString can now render Bullet annotations.

Everything else is bug fixes. Four on iOS, mostly Safari selection and focus on web, and exactly one on desktop, sluggish window resizing on Windows.

Right, that is 1.13 done.

The line worth reading is two months old

On August 25, 1.12.0 shipped. Its Highlight section has one line.

Compose Hot Reload got an MCP server, letting AI agents interact with a running Compose application in real time.

Almost nobody discussed that line. Spread the tool list out and it stops looking like a small update.

What an agent actually gets

One Gradle task, hotMcpServer, brings the service up, connects to the app, waits for startup, detects shutdown, and reconnects on its own.

An agent connecting in gets these tools.

State and reload: status reads app and reload state and hands back the last error with it. reload and await_reload trigger a hot reload and wait for it. restart and reset_ui restart the app or reset its UI.

Observation: take_screenshot captures a screenshot, optionally to a path. list_windows and resize_window inspect and resize windows. get_semantic_tree reads the semantic tree, dialogs, modal bottom sheets and popups included. get_ui_error and get_logs read the current error and the app logs.

Action: click, type_text and scroll, simulating user input directly.

Put those three groups together and an agent has a complete loop inside Compose for the first time.

How the loop closes

Before this, an agent writing Compose code hit a wall at the UI. It could edit files and compile, but it could not see what the screen looked like, could not tap a button, and had no way to know whether the change was correct.

A human had to pick it up. That is the long stretch of waiting.

Now the cycle runs like this. The agent edits code, calls reload to trigger a hot reload, takes a screenshot, reads the semantic tree to confirm the layout has not collapsed, checks the logs to confirm nothing threw. If it is wrong, it goes around again.

No human in that loop.

An agent walking that circle by itself is the closed loop.

1.3.0-beta02 added the missing piece. Scrollable nodes now carry scrollX or scrollY, giving the current offset, the max offset, and a reversed flag when content scrolls against layout direction.

That looks like plumbing. For an agent it is decisive. Before, it knew a scrollable container existed. Now it knows where the scroll sits and whether there is more below. Without that, every screenshot it takes is the first screen.

Two different roads from Flutter

Last month the Flutter team published a piece whose core claim was that code generation stopped being the bottleneck and verification is the bottleneck now.

Their fix is structural. Hot reload at 200 milliseconds, widget tests at 500, state inspection by reading the widget tree directly, all deterministic structured data.

JetBrains did not take that road. It did not optimize the framework’s feedback speed. It opened the running app to the agent and let the agent do the verifying.

One leans on being light. The other leans on opening a door.

I lean toward the second being more general. It has nothing to do with the framework, only with the runtime being reachable by a program. That also makes the ceiling concrete. It depends on how much the MCP server exposes. A dozen tools covers simple UI. More complex interfaces will need more.

What you can do tonight

If you have a Compose desktop project, you can try this tonight.

The prerequisite is Compose Hot Reload 1.2.0 or later. Run gradlew hotMcpServer in the project, point your agent client at the endpoint, and have it change a Composable, trigger a reload, and read the semantic tree to confirm the button has not moved.

The tool list and the loop above come from the 1.12 and Hot Reload 1.3.0-beta02 release notes plus repository source. I have not run this end to end on my own machine, and I would rather say so than let you assume it is measured.

Two places I would expect to get stuck on a first attempt. The MCP server only starts in dev mode, so the client needs the right port. And get_semantic_tree over dialogs is documented very briefly, so test that on its own before wiring it into anything.

The first time you watch it close that loop without you, it feels different from watching it generate code.

So, a question for you. Have you tried letting an agent take over hot reload and verification in your projects? Or are you still changing code and clicking through it yourself?

And one more. Do you think opening the runtime to agents will move slower on web and mobile than on desktop? Desktop has a JVM to hook into directly. Mobile will need a different answer.

The title was blunt: native is now the future of mobile at Shopify.

Six years ago they went all-in on React Native. Last January, Ali wrote a retrospective saying RN had a bright future. Now they are reversing course, and the stated reason is one thing: coding agents have crushed the cost of writing everything twice.

The switch worked out. Six engineers took Shop App from proof of concept to the app store in 12 weeks. iOS cold start improved 23%, Android 50%.

But the most valuable line in that post is not a number.

Ali writes that an agent can rewrite the code in seconds, then spend minutes working out whether it actually works. Simulator control is too slow, so getting state means going through the accessibility tree or taking screenshots.

His words: if the model cannot quickly verify its own work, it does not matter how good the model is.

That complaint made me read two posts side by side. The Shopify piece from September 10 and the Flutter team’s response forty days later are arguing about the same thing.

The bottleneck is not generation, it is verification

The Flutter post went up on October 20, by Carlos Mendonça and Emma Twersky. Its title is just as blunt: AI makes it easy to migrate, Flutter makes it easy to scale. It exists to answer the question Shopify threw down.

The whole piece rests on one claim. Code generation stopped being the bottleneck a while ago. Verification is the bottleneck now.

Two numbers back it up. 73% of developers say AI makes them more productive when starting a task. 46% do not trust AI’s debugging accuracy without a human checking it.

Squeeze from both sides and the blocker sits on the human side.

The bill for three steps

The team published a comparison table putting native and Flutter next to each other across the three verification steps.

Code-to-running latency: native takes 2 to 5 minutes per cycle. Build, link, archive, install on the simulator. Four debug rounds burn twenty-odd minutes.

Flutter stays under 200 milliseconds. Hot reload injects the change into a running Dart VM and keeps state.

Automated tests: native walks the full simulator lifecycle and a background emulator. Flutter’s headless widget tests run in an isolated environment in under 500 milliseconds.

The UI and state-check row is where it gets interesting.

Native screenshots the simulator and hands the image to a vision model to guess at the layout. Probabilistic, and slow. Flutter goes through MCP to query the Dart VM Service and DevTools, reading the widget and render object trees directly. Deterministic, structured.

Chain the three and you have a complete loop. Every step queues on the native side. On Flutter a round trip is milliseconds.

Harness beats prompt

Fast verification is one thing. Getting the agent to actually use it is another. The team ran an internal experiment called Project One Shot, letting an agent fix a production bug in camera_android_camerax on its own.

The plugin manages Android CameraX lifecycles and surface texture binding, the hairiest kind of Flutter code there is.

Given vague instructions like watch out for memory leaks, the agent failed every time.

It only worked with a deterministic harness. AST analysis over MCP, package-level domain skills, enforced test-driven guardrails. Reproduce with a failing test, write the smallest fix, finish with the full test suite and leak checks.

No room for the agent to freestyle. Every step has its acceptance criteria nailed down.

Three things shipped alongside. An official Dart and Flutter agent plugin bundles an MCP server with ten Flutter and fourteen Dart skills, so the agent can reach the Dart Analyzer and Widget Inspector directly.

A dedicated agent inside Antigravity audits accessibility issues and submits fixes that match existing conventions. Plus an Agent Skills CLI built with Serverpod: one dart run skills@get installs the skills a package ships with into your agent.

The benchmark numbers: Gemini 3.5 Flash from 84.1% to 85.5%, Gemini 3.1 Pro from 89.6% to 92.7%. Modest gains, run by the team on its own eval suite.

Where this actually lands

The post lists a set of deployment targets well beyond phones. Toyota and Lexus head units, the Xiaomi SU7 center console, Nubank’s fintech app with a hundred million users, Universal Music.

The post does not push this angle. I think it is the most convincing part.

What these share is absurdly expensive verification.

Flashing a head unit takes tens of minutes. One production incident in a fintech app costs real money. Music app users tolerate zero jank.

In places like these, a minute off the verification loop is money and time you keep.

Look further out. Once agents writing code is normal, one codebase across platforms saves more than headcount. It saves time.

An agent produces a change, hot reload shows it on phone, desktop and web at once. That is an order of magnitude faster than compiling, packaging and installing per platform.

That is also why the Flutter team has been pushing into automotive, desktop and embedded.

The second half of cross-platform may not happen on phones.

A few things I do not buy

The app store rating section does not hold up. It cites Apptopia’s study of 201,000 apps. On Google Play, Flutter apps average 4.1 stars, and so do non-Flutter apps. On the App Store both sit at 4.0. The conclusion offered is that users do not care about the framework.

All that shows is that cross-platform did not hurt ratings. Flip it around and it also shows cross-platform did not help. Using a tie to argue for adoption is missing a step.

That 200 milliseconds is the time to inject a change. It excludes writing the code, thinking it through, switching windows.

It cannot change class structure either. Add a field or restructure the state tree and you need a restart.

The table measures code-to-running latency, which is an honest definition. Readers will take it as development being twenty times faster, and those are very different claims.

The enterprise examples have survivorship bias too.

Xiaomi SU7, Universal cutting 45% of its code, Toyota and Lexus, Nubank’s hundred million users. All real.

No post ever covers the company that moved to cross-platform for two years and then tore it out. Arguments from these examples are half evidence.

How to do the cross-platform math

Line up both sides first. Shopify’s call: the cost of writing twice has been crushed, and what is left is not worth giving up native capabilities for. Flutter’s call: coordination costs remain.

The example in the post is specific. Same checkout state machine, two instances of the same model. One writes Swift and drops stale events through an async stream. One writes Kotlin and queues events through a reactive flow.

Both pass local unit tests on day one. Weeks later Android checkout conversion drops three points, because under network jitter the retry timing differs.

Both positions hold. They are doing different arithmetic.

I also do not think this pivot is evidence that cross-platform is dead.

This is a company with hundreds of screens, over a thousand engineers, and mobile as a core investment. At that scale, rebuilding for 23% faster cold start and a better crash rate pencils out.

For five people maintaining a mid-sized app, the same move probably does not.

What decides whether you go cross-platform is team size, how many years you will maintain it, and how long your verification chain is. AI changes none of those.

Here is a question worth arguing about instead. If agents really do get a verification cycle down to a few hundred milliseconds, how much longer does native-feels-better hold up.

I would like to hear what is actually on your desk. Is your project single-platform, dual, or cross? What drove that call: performance, headcount, or a boss who said we are going native?

One more question: do you think Compose Multiplatform has a shot? It is cross-platform too, arrived years after Flutter, but it stands on half the Kotlin and Android ecosystem.

Drop a comment. I will pick a few representative ones and write them up as a follow-up.

Both source posts are here. Twenty minutes total.

Native is now the future of mobile at Shopify

AI makes it easy to migrate. Flutter makes it easy to scale.

The real changes are in the later sections. The publishing format changed, the compilation scheme changed, and three defaults were quietly tightened. I installed both compilers on the same machine and fed each one the same source. The results differ.

The point of this release is not syntax

Two of the four stable features are really about turning a choice into a default: the syntax-only mode for destructuring by name, and the unused return value checker. Not one line of old code needs changing. What new code can express changes.

The two experimental ones follow the same line: companion extensions and companion blocks, and full value classes. All of them remove a bit of arbitrary restriction from the language.

The language layer is the quiet part this time. Laid out properly, the substance is in the last three sections of the doc: the Kotlin Multiplatform publishing format, the new compilation scheme, and incremental compilation on Apple platforms. None of those change what you write. They change what you ship and how long it takes to build.

One .kar file replacing seven thousand

Their words:

The new format publishes platform artifacts (except for JVM and Android) as a single .kar archive, which is a ZIP archive additionally compressed with XZ.

A library supporting several targets used to publish several sets of artifacts. Now everything except JVM and Android goes into a single .kar, which is a ZIP with an extra layer of XZ on top.

The numbers are clearer than the description. Their example is cryptography-kotlin: published artifacts went from 7,539 files and 91 MB to 1,036 files and 23 MB. For the whole multi-module project.

One line to turn it on. Per module in the build script, project-wide in gradle.properties:

kotlin.publicationFormat=KOTLIN_ARCHIVE

Two caveats have to be read together. Except JVM and Android: those two ecosystems still use standard Maven artifacts. The consumer side is fully available, so when a library you depend on switches format, your build does not move. The publishing side is still experimental, so if you publish libraries yourself, verify your pipeline separately.

Why Maven Central’s limit is about file count

The notes only say Maven Central recently introduced a publishing size limit. What sits behind that sentence is more interesting than size.

What blocks library authors is not total bytes, it is file count. A library with six targets, one artifact set per target, plus source jars and metadata, lands in the thousands without trying. Every file is a separate record in the repository, a separate upload, a separate index entry. For the repository that is operational cost. For the user it is the first screen of requests during dependency resolution.

So 7,539 files down to 1,036, minus eighty-six percent, matters more than 91 MB going to 23 MB. What you save is requests and index entries, not bandwidth.

JVM and Android being excluded says something too: those two ecosystems are still anchored to standard Maven classifiers and cannot move. The real situation for cross-platform libraries is many targets, mainline platforms on the old format, everything else in an archive. That hybrid will stick around for a while.

The change is completely transparent downstream, and because it is transparent, it can be recommended to everyone. The beneficiaries are library authors and the people maintaining release pipelines, not those of us writing application code.

The new compilation scheme: common code should not quietly reach platform APIs

This section is written with restraint. Four items: make the compiler treat common source sets the same way the IDE does; prevent common code from accidentally resolving to platform-specific declarations; improve consistency of overload resolution and type inference; enable incremental compilation for common source sets.

The first three fix an old hole. One wrong import in commonMain and the IDE marks it red while the command line passes, or the reverse, and the two never agree. The cause: the IDE and the compiler each have their own resolver, each doing its own math.

Unifying them has a side effect: code that used to compile may not anymore. That is not a regression. That code was reaching symbols it should not have seen. Nobody was stopping it.

The fourth is the everyday payoff. Common code finally gets incremental compilation, and people who live in the IDE feel it most. On CI you will not notice, because the pipeline builds from scratch every time.

JetBrains wrote a dedicated post on this scheme in September, with the word reliable in the title. The problem being fixed is exactly unreliability: the IDE and the compiler reaching two different conclusions about the same common code.

The compiler got stricter: three defaults changed

The most visible one first. The same code fails to compile on 2.4.21 and passes by default on 2.5.0-Beta2:

(val mail = email, val name = username) = user

val inside the parens, an equals sign picking which property to take, and the variable name no longer has to match the property name.

An old hole while we are here. Positional destructuring like val (email, username) = user passes on both versions, but the values are assigned by position. I destructured User(username, email) into email=alice, username=alice@example.com. Every variable name wrong, and the compiler said nothing. This feature exists because of that.

Second, the unused return value checker. The same file passes silently on 2.4.21 and warns on 2.5.0-Beta2: unused return value of 'plus'. If an expression produces a non-Unit value and nobody uses it, it tells you.

Third, cross-module inlining. Optional when introduced in 2.4.0, on by default in 2.5.0-Beta2. The off switch is -Xklib-ir-inliner=disabled.

There is one more that is not a default. Type inference generates fewer constraints and no longer stalls on complex generics. The notes are restrained, saying only that it may change inference results, overload selection and diagnostics. In plain terms: after upgrading, some code will infer different types, and that code is code you previously believed was correct. Off switch: -XXLanguage:-EliminateSecondKindIncorporation.

value class is where the cut goes deepest

Value classes used to allow exactly one property and required @JvmInline. Multiple properties work now, plus two new shapes: abstract value classes and value objects.

On my machine: 2.4.21 rejects a multi-property value class outright, telling you to enable -XXLanguage:+FullValueClasses. 2.5.0-Beta2 passes with -Xfull-value-classes.

Same for value objects. 2.4.21 says modifier 'value' is not applicable to 'standalone object'; 2.5 compiles and runs with the flag.

One detail explains it better than the docs. Write === on a value object and the compiler errors immediately. Identity comparison is banned by the language, because it has no identity to compare.

The real trap is migration. value class is no longer inlined by default. The stated timeline: warnings start in 2.5.20, errors in 2.6 or 2.7. On 2.5.0-Beta2 the switch is not even recognized yet; the compiler answers that the flag is not supported, which means the window really does open at 2.5.20.

Meaning: upgrading today will not blow up. But you have until 2.5.20 to mark the old code, deciding what keeps inlining and what lets go. Whether a value class wrapping a single String should inline is a trade-off to begin with, and the language should not make that default for everyone.

The standard library closes two small gaps

Three functions landed for if expressions: onTrue(), onFalse(), ifOrNull(). Printing a line when an add succeeds used to mean a local variable and an if/else. Now one line holds it:

val added = tags.add("wasm").onTrue { println("Tag added") }

The return value is still the same boolean. The check and the side effect sit on one chain, and you no longer build a variable for a case this small.

The other half is Unicode code points. A Char holds one UTF-16 code unit, so when you hit a surrogate pair like an emoji, iterating by Char splits one character in half. The new CodePoint is a value class holding the code point in an Int, and it can tell you how many UTF-16 units it occupies, which category it belongs to, whether it is a letter.

Both need @OptIn(ExperimentalStdlibApi::class). Note the shape of CodePoint: it is only writable because value classes were relaxed. Language and standard library line up in this release.

Two surprises on my machine

First surprise: compilation did not get faster. On a 489-line project, warmed up, 2.4.21 has a median of 2.86 seconds and 2.5.0-Beta2 comes in at 2.99. The output is 161 KB either way. The difference sits in the noise, so it is not slower, but there is no visible payoff from the inference work on a small project. That kind of optimization only shows up in large generic-heavy code.

Second: the scope of that switch. -Xklib-ir-inliner=disabled is rejected outright by the JVM compiler, which says the flag is not supported. It only means something where klib is produced: Native, JS, Wasm.

On by default in the docs has to be read per platform.

Three things to do before upgrading

The JDK floor moved. The compiler’s minimum went from 8 to 17, and anything below now errors out. CI images and Docker base images have to follow, and that step usually eats more time than the code changes.

If you publish Kotlin Multiplatform libraries, do not rush into .kar. The publishing side is still experimental. Try it in a pipeline, do not push it to a real release.

Run your tests. The unused return value check and the inference changes both fall into the passes silently but behaves differently category. Reading the docs will not reveal the problem; running tests will.

Last

Most of what 2.5 does lands on defaults: packaged by default, checked by default, inlined by default, destructured by name by default. Every one of those comes with an off switch, which says the team knows it will step on people, and also that these defaults are not final.

Do you have code the IDE marks red while the command line compiles it fine? After 2.5 it will probably have to come clean. Tell me what broke on your end in the comments.

Sources: Kotlin 2.5.0-Beta2 release notes Kotlin release schedule A more reliable compilation scheme for Kotlin Multiplatform modules

My DeepSeek Harness has had memorix attached the whole time. Months of use, zero problems.

Yesterday I was going through the ai-memory repo. The support matrix has a row for DeepSeek Harness, status: MCP only. A memory service that set aside an adapter slot specifically for dsh — that I had to try.

Installed it, ran it for a night. Conclusion up front: this is not a better memory, it is a different way of layering memory. Picking the wrong layer is a lot more trouble than picking the wrong tool.

Memory actually has three layers

The first layer is in the context window. Whatever the model can see this time is gone when the session closes. Compaction, truncation, switching models — all lost.

The second layer is in the repo. AGENTS.md, notes, a small wiki. Git tracks it, you can grep it, you can review it, and git diff shows you what actually changed.

The third layer is in an external service. A background process stays alive, across machines, across people, across agents. Whoever connects reads the same copy.

Most agent memory tools on the market talk about the third layer but ship something that crowds into the first, usually by stuffing summaries back into the prompt. What makes ai-memory different is that it touches all three: the first layer as the entry point, the second as the substrate, and the third is the actual job.

What you are actually installing

The macOS build is a 17,817,781 byte archive, sha256 identical to the official release. Unzip it and it is a single file, 39,835,136 bytes, no runtime dependencies, and --version returns 3.1.2.

Its data directory holds three things: wiki stores markdown, db stores the SQLite index, raw stores the original observations. The real substance is that pile of plain markdown files under wiki. The index can be rebuilt whenever.

I wrote three pages and got three files on disk: 435, 446 and 585 bytes. Indistinguishable from notes I typed by hand. That is worth more than any feature, because the files are yours — the tool dies and the notes are still there.

The real novelty: a job can only be claimed once

The tool list has a handoff group: begin, accept, list, cancel. A handoff has an owner, can be claimed exactly once, and once claimed it is yours.

There is also a message group: send, list, pop, cancel. Messages across projects, and popping one counts as claiming it.

Strictly speaking these two groups are not memory, they are scheduling. When you work half a day in Claude Code in the morning and a different agent picks it up at night, the hard part is not “what did it forget”, it is “who owns this unfinished work”. It turns that into a protocol.

On dsh you get MCP, no hooks

The output of install-mcp --client dsh says it itself: print only, MCP only, no lifecycle capture.

The generated snippet uses @deepseek-ai/dsh-mcp-client, identical to the memorix entry in my cordis.patch.yml. Only command and args differ.

Translated: on dsh it does not record anything on its own. No lifecycle hooks means no “write a page when the session ends” step. To get dsh to remember something, the agent has to actively call write page.

This is the reminder I keep on both of my machines: “supported” in a support matrix does not mean the experience is the same. The cost of that MCP only line lands entirely on automatic capture.

Tool surface: 24 vs 20

Same MCP probe, initialize then tools list, two numbers came out.

ai-memory 3.1.2 has 24 tools, all memory-prefixed, covering pages, briefing, query, handoff, message, decay, lint.

Local memorix 1.9.1 has 20. The extras are project context, codegraph status and the session lifecycle ones.

Similar count, different direction: one grows toward cross-agent collaboration, the other toward project context and code graphs.

The Chinese search problem: I ran three comparison tests

This is the pitfall I most want to talk about.

The CREATE TABLE for the index spells out the tokenizer: unicode61 remove_diacritics 2 tokenchars '/_-'. unicode61 tokenizes on spaces and punctuation, so a run of consecutive Chinese becomes a single token.

Which produces this. I wrote three pages of Chinese notes and searched directly:

search "构建缓存"   → 1 hit (the body has exactly "Gradle 构建缓存", whole string as one token)
search "白屏"       → 0 hits (the body has "渲染偶发白屏", whole string as one token)
search "渲染"       → 0 hits
search "skiko"      → 1 hit (an English word tokenizes itself)

To confirm I was not searching wrong, I wrote another page and deliberately put spaces on both sides of “白屏”. Searched again, this time it hit.

So the rule is: a Chinese query has to exactly equal some contiguous run of Chinese in the text, otherwise you get zero results. That is not a bug, it is an inevitable consequence of the tokenizer, but it makes people think the memory was never written.

Two practical workarounds. Leave spaces on both sides of key terms when you write a page, like “遇到 白屏 时”. Or just use English keys and keep the Chinese in the body.

Project scope falls into scratch

I called briefing from a static MCP client and got zeros across the board. Reading the parameter docs turned up one line: a static client must pass both workspace and project on every call.

Skip them and everything lands in a fallback project called scratch. Your memory is not lost, it is just filed in a different drawer.

dsh’s mcp client is static, so once it is wired up every call needs those two parameters, otherwise you get the classic “I definitely saved that, why did it forget”.

Memory ages on its own

The config has a set of decay parameters: lambda 0.02, sigma 0.6, mu 0.04 by default, a cold threshold of 0.20, hard delete at 180 days.

In usable terms: a page nobody reads slowly goes cold, past the cold threshold it can be compacted and the plot compressed into a conclusion, and after 180 days it may actually be deleted. Raw observations are never pruned by default; the config value is 0.

It also has one rule I think is right: memory that has been accessed decays more slowly. Opening, searching, following a link all count as uses. That makes more sense than wiping on a timer.

I measured the startup briefing size too. Empty project 651 characters, three pages 1,136, ten pages 1,340. So every session it puts a bit over a thousand characters into context. That amount is acceptable.

How to choose

Three questions, in order.

First, do you want “what happened in this repo” or “how many live threads do I have on this machine”. The former is the repo layer: AGENTS.md plus one directory, no service to install. Only the latter needs the third layer.

Second, does your agent client give you lifecycle hooks. If yes, the third layer can capture on its own. If no, you gain a manual write-a-page step, and you have to judge for yourself whether you will keep doing it.

Third, are your notes mostly Chinese or mostly English. If mostly Chinese, accept the search limitation first and do not expect it to find things like a search box does.

My own conclusion: for now the third layer is only a relay channel across machines. Day-to-day stuff like “I hit this pitfall before” stays as markdown in the repo, one line at a time, with a diff I can read.

Which layer does your agent’s memory live in right now? Comments are open.

The day my account got banned, my first reaction was the same as yours: register another one.

But after going through the official docs I realized reopening is not a process problem at all. It splits into two cases, and the outcomes are very different.

The first is dormancy. If an account goes a long time without publishing updates, checking stats or managing store listings, Google deactivates it. The help center says: after a dormant account is deactivated, you can still create a new account and publish on Google Play later. For that kind of account, reopening is routine.

The second is termination for violation. The same article says: if you repeatedly or seriously violate these policies or the developer distribution agreement, your developer account or related Google Play developer accounts may be terminated.

Pay attention to the words “related”. Another page puts it more bluntly: multiple warnings may lead to termination of the individual account and related Google Play developer accounts.

So the real question is not “how do I reopen”. It’s “will the new one survive”.

Why I still picked a personal account

When you reopen, the account type step matters more than it did the first time.

An organization account needs a D-U-N-S number, organization registration documents, and the authorized representative’s ID, and all three have to line up with each other. A D-U-N-S application can take up to 30 days. The account is already gone; waiting another month is too slow.

A personal account needs one government-issued photo ID. Fewer documents, fewer places to get it wrong.

But don’t pick it just to save effort. There’s an official list: financial products and services, health apps, apps using VpnService, and government apps. Those four categories must use an organization account. If your app touches any one of them, a personal account won’t show the problem up front, but review will kick it back later anyway.

The six steps to reopen

Order matters here, especially step two. Step one is getting the Google account ready. Use a clean one, not an account that already registered another developer account, and don’t buy one.

Step two: go to Google Payments first and create a payments profile. Country/region China, legal name and address exactly as printed on your ID. You can’t skip this and can’t bolt it on later.

Step three: register a developer account in Play Console with that account and pay $25. Cards accepted are MasterCard, Visa, American Express, Discover (US only) and Visa Electron (outside the US). Prepaid cards are not accepted.

Step four: choose a personal account.

Step five: identity verification, submitting a government-issued photo ID.

Step six: device verification. Find a real Android 10+ phone that isn’t rooted, install the Play Console mobile app, scan the QR code. The docs say this takes a minute.

Why can’t you skip ahead? Phone verification comes after identity and device verification. Finish the earlier steps or the phone verification entry point never opens for you.

After approval, the home page looks like this

The day verification passed I got into Console and the first look is a letdown: 0 apps in production, 0 apps with policy tasks, 0 apps with publishing submissions. Three cards, all zeros.

That’s correct. Passing only means you can create apps now. It doesn’t mean an app can ship. The real starting point is that “Create app” button in the top right.

Two things on this page are worth noting. In the row of buttons at the top there’s “Policy status”, and account reputation problems show up there first. In the list below, anything tagged Draft is an app you created but haven’t submitted for review. That green banner in the middle is just a Play redesign notice and has nothing to do with your account status.

The address section ate most of my time

Last time I filled the address in without thinking. Not this time.

The docs say this on the required documents by country page, and I copied it down:

All documents you submit must match the information in your payments profile exactly, including personal identity details, organization name (for organization accounts), and address information. If you find any discrepancy between your documents and your payments profile, you can update the payments profile information during the verification task.

That sentence explains why most people get rejected. Verification is not checking whether your documents are complete. It’s checking whether they match what you typed in yourself.

Three lines have to match character for character.

Name: if the ID is in Chinese, write it in Chinese. Don’t write “张伟” in one place and “Zhang Wei” in another.

Address: the address in the payments profile is the legal address, and the country/region Play displays publicly is based on it. If the ID says “3号楼502, XX路128号, XX区” and you only wrote “XX路”, that counts as a mismatch. Province, city, district, street, building, unit — write down as many levels as you can.

Documents: four hard requirements. Valid and unexpired, color not black and white, clearly legible with reasonable exposure, and not a photocopy.

If you’ve already been rejected you don’t have to register again. The second half of that same sentence says you can update the payments profile during the verification task, fix the address to match the ID, and submit again.

How to keep the new account from getting dragged down

This is the part I most wanted to get right, because there’s no trick to it. Only facts.

When Google says “related developer accounts may be terminated”, it means Google looks at whether a set of things are the same: the same person, the same payment card, the same device, the same batch of package names, the same payout account.

Open a new account and carry all those traces over unchanged, and you’ve raised your hand to say “still me”.

What actually reduces risk is the reason the original account was banned being not that serious, or the appeal already settled. For serious violations like malware or fraud, ten new accounts won’t help. Reopening in that situation means the $25 is gone and the account gets banned again.

Put bluntly, that phrase “related developer accounts” exists specifically to close this door.

Before you submit, check the files locally

Two of the four photo requirements can be checked right on a Mac: is it color, and is the resolution high enough. The built-in sips tool does it, nothing to install.

sips -g pixelWidth -g pixelHeight -g space your-id.jpg

Look at the space line. RGB means color. Gray means black and white, and a black and white image will always be rejected. If the short edge is under 1000 pixels, retake it: images passed through WeChat often end up only a few hundred pixels.

I wrote a small script to chain both checks, and the output looks like this:

id-color.png        1600×1000  space=RGB   ✓ pass
id-gray-small.png   640×400    space=Gray  ✗ short edge 400px  ✗ grayscale

One last honest word

With reopening, the documents and the process are secondary. What comes first is always why the last account died.

Dormancy deactivation: just walk the six steps above. Termination for serious violation: don’t count on a new account turning the page. Fix the problem first, then talk about registering.

Have you reopened one? Which step did you get stuck on? Comments welcome.

Someone asked me again last week what to do about a rejected Play developer account. Going through his materials: ID photographed, card linked, the $25 charged successfully. The problem was the address — his card’s billing address was the office, the address on his ID was his hometown.

There are plenty of Chinese tutorials on the registration flow. Almost none cover address alignment, even though Google puts this front and center in its help center.

In Google’s own words

All documents you submit must match the information in your payments profile exactly, including: personal identity details, organization name (for organization accounts), and address. If you find any discrepancy between your document and your payments profile, you can update the payments profile while the verification task is in progress.

Right after that comes a line about why it fails:

Submitting unsupported documents is the leading cause of developer verification failure, and providing altered or forged documents can result in immediate removal of your account and apps.

Those two sentences lay the rule out completely: verification is not about whether you have documents, it is about whether what you submit matches what you entered. If it does not match, complete paperwork is still wrong.

The address is not the one you typed on the signup page

A lot of people think the address is just a field you fill in on the signup form. It is not.

Play’s legal name and legal address come from the Google payments profile attached to your account. In other words, the address you store in Google Payments is what actually gets compared against your ID. The country and region shown publicly on your Play page are derived from that same legal address.

So the order is obvious: get the payments profile right first, then open the developer account. Doing it the other way plants a mine under your own review.

Three lines that have to line up

The first is the name. If the name on your ID is in Chinese, write it in Chinese in the payments profile too. If the system only takes Latin characters, pick one transliteration rule and stick to it. Do not write 张伟 in one place and Zhang Wei in another, and definitely do not spell it out in one place and abbreviate it in another.

The second is the address. Province, city, district, street, building number — go as deep as the ID goes, and match the wording character for character. If the ID says XX District, XX Road, No. 128, Building 3, Unit 502 and your payments profile says XX Road, that counts as a mismatch.

The third is the photo of the document. The four official requirements are specific: valid and unexpired, color not black and white, legible with balanced exposure, and not a photocopy. Fail any one and it counts as an unsupported document.

One item that is not in the official text but comes up constantly in practice: the billing address on the card you link should ideally be the same address. No official basis for this one, just experience. Take it as a pointer.

Six steps for registering entirely in Chinese

Step one: make a clean Google account. Do not reuse an account that already registered another developer account, and do not use a bought one. Identity verification later checks the person.

Step two: go into Google Payments and create a payments profile, set country/region to China, and enter the legal name and address exactly as they appear on your ID. The address you enter here is what every later verification checks against.

Step three: register the developer account in the Play Console with that account and pay $25. Cards are limited to MasterCard, Visa, American Express, Discover (US only) and Visa Electron (outside the US). Prepaid cards are not accepted.

Step four: choose the account type. Personal account, pick individual. Do not force organization just because it looks more official — organization accounts need a D-U-N-S number and company documents, and one missing item stalls you.

Step five: identity verification, submit a government-issued photo ID. For a personal account that is the only document.

Step six: device verification. Take a real phone on Android 10 or later, not rooted, install the Play Console app, scan the QR code. One minute.

You cannot skip around. Phone verification comes after these; until identity verification is done, the phone verification entry point does not even open.

Organization accounts need two more documents, with the same address alignment

An organization account needs the representative’s ID plus the organization’s registration document (a business license, typically) and a D-U-N-S number. The organization name and address on all three must match the payments profile character for character.

D-U-N-S is free to apply for on D&B’s own site, and Google specifically warns that third parties charge steep handling fees. Do not fall for it. Approval can take up to 30 days, so if you are going the organization route, start a month ahead.

Run your own check before you submit

Two of the four official photo requirements can be checked locally: whether it is color, and whether the resolution is enough. macOS ships with sips, nothing to install.

sips -g pixelWidth -g pixelHeight -g space your-id.jpg

Look at the space line. RGB means color, Gray means black and white, and a black and white image will be rejected. If the short edge is under 1000 pixels, reshoot. Compressed WeChat images are often only a few hundred pixels.

I wrapped these checks in a small script. Here it is run against two sample images:

id-color.png        1600×1000  space=RGB   ✓ pass
id-gray-small.png   640×400    space=Gray  ✗ short edge only 400px  ✗ color space is Gray

What if you already got rejected

You do not need to re-register. Google says you can update the payments profile while the verification task is in progress, change the address to match your ID, and submit again.

What is genuinely hopeless is forgery. An ID with the address edited in Photoshop, a borrowed ID, a bought business license — if they catch it, the account and apps are removed and the $25 is not refunded.

The address thing is tiny — one line of text. It is also huge, because it decides whether every verification after it passes. Did the address trip you up when you registered? Tell me in the comments.

Chinese tutorials on Play developer accounts mostly stopped updating two years ago: $25, a credit card, an address, wait a day. That is no longer enough.

The help center now says: 18 or older, accept the developer distribution agreement, pay $25 by credit or debit card, cards limited to MasterCard, Visa, American Express, Discover (US only) and Visa Electron (outside the US), and prepaid cards are explicitly not accepted.

Paying the money only gets you through the door. After that comes identity verification, device verification, a closed test with twelve people over fourteen days, and the new rules that took effect September 30.

Personal or organization: pick the right one first

Play has exactly two kinds of developer accounts: personal and organization. Same features, both can monetize, both can add collaborators.

The difference is paperwork. An organization account must supply a Dun & Bradstreet number, D-U-N-S, the nine-digit business identifier issued by D&B. It is free to apply for, but you wait. There is also a list: financial services, health apps, apps that use VpnService, and government apps. Those four categories must use an organization account.

A personal account registers fast. The price is that the testing requirements below aim specifically at personal accounts.

Identity verification: the ID and the card have to be the same person

The official wording: to process the registration application, they may ask for a valid government-issued photo ID and credit card information, and the holder of both must be you. If they check and the information turns out invalid, the registration fee is not refunded.

This one gets ignored a lot in China. Paying with someone else’s card, or padding the file with a relative’s ID, both count as inconsistent information. $25 is not a lot, but you do not get it back.

Device verification: one minute, but you need a real phone

Since early 2024, a new personal account has to prove it has a real Android device before publishing anything. The method: scan a QR code with the Play Console mobile app, sign in to the same Google account, pick the developer account, tap verify.

The bar is a physical device on Android 10 or higher, not rooted. Emulators do not count, rooted devices do not count. Google says this should take under a minute, one device can verify multiple accounts, and the process does not collect the device’s phone number.

Twelve people, fourteen days

This is the one outdated tutorials get wrong most often. Plenty of articles still say find twenty testers and test for fourteen straight days. The official page now says: at least 12 testers who opted in to continuous participation in a closed test for at least the past 14 days.

The number changed and Chinese tutorials largely did not keep up. Per the current official wording, it is 12.

The rule only applies to personal accounts created after November 13, 2023. Once you satisfy it you can apply for production release access in the dashboard, and the application asks about app design, your testing process, and launch readiness.

From September 30, verification reaches past Play

This part is the genuinely new thing. Android developer verification enters the enforcement phase on September 30, 2026, starting with four countries — Brazil, Indonesia, Singapore and Thailand — covering distribution across seven stores: Google Play, HONOR App Market, OPPO Software Store, Samsung Galaxy Store, Transsion Palm Store, vivo App Store, Xiaomi GetApps.

In other words, from now on installing an app on a certified device raises a question: who signed this package. The official timeline is worldwide rollout in 2027.

It splits developers onto three paths, and identity verification, fees and where you can distribute all differ.

Three key details.

Full distribution requires opening a separate account in the Android Developer Console, also $25, which is a different payment from the Play one. Limited distribution is free and needs no ID documents, but covers only 20 devices, and users have to accept an invitation before they can install. On the unverified sideload path, users can let themselves through via an advanced flow, which the official writeup describes as a buffer that buys users time and room.

One more detail matters most to people who write code. The official FAQ is blunt: installing an app over ADB requires no registration and no verification. Development, debugging, flashing your own test builds — that channel is not closed. Apps on enterprise-managed devices also skip verification; the IT admin has already reviewed them.

What registering a package name needs, you can prep locally

The third step of the new verification system is registering the package name. Google requires an APK signed with your private key, to prove the package is yours. You do not have to wait for the account to be approved for this — you can rehearse it locally.

keytool -genkeypair -v -keystore demo.jks -storetype PKCS12 \
  -alias upload -keyalg RSA -keysize 4096 -validity 10000 \
  -dname "CN=Demo Dev, O=Demo, C=CN"

keytool -list -v -keystore demo.jks | grep SHA256

What comes out is a SHA-256 string. Mine generated 52:05:B5:73:…, with another thirty bytes behind it. That fingerprint is what gets checked against package ownership from here on. Lose the private key and it never matches again. So from day one, treat the keystore file and its backup as the same object.

The math cross-platform developers have to do

If you are shipping Android from one codebase with Kotlin Multiplatform or Flutter, the accounting splits here. $25 to publish on Play, another $25 to distribute outside Play through the Android Developer Console, and both accounts need identity verification.

Where you save is elsewhere: device verification and the twelve-people-fourteen-days test are tied only to a personal account’s production release access. Organization accounts do not carry that.

The actually convenient move is to keep publishing through Play as usual, and register the package name and signing key in the Android Developer Console at the same time. Then no matter which store a user downloads from later, or whether they install straight from your site, the install does not get blocked.

$25 buys a ticket. The gates behind the ticket are where this year’s time actually goes. Which step did you get stuck on when you opened your account? Comments are open.

DeepSeek Harness keeps saying Everything is a Plugin, meaning features are all built as plugins. Version 0.2.1 moved one step further and started managing where plugins come from: rc.1 added an entry that lets users discover and install plugins from custom plugin index sources.

I ran that whole path end to end. First read the release notes properly, then hand-wrote an index and mounted it, then clicked Install in the real UI and installed a third-party plugin. Three walls along the way, and each one is worth writing down.

First, untangle the version numbers

Three version numbers here are easy to mix up. On npm, dsh has three dist-tags: latest is parked at 0.2.0-rc.2, next is 0.2.1-rc.2, and an alpha pointing at 0.2.1-alpha.5. My machine had 0.2.1-alpha.3 installed, sitting right in the middle.

rc.1 and rc.2 shipped the same day, three hours apart: rc.1 at 13:22 on October 17, rc.2 at 16:16.

rc.2 has only two items: support for DeepSeek-V4.1-Flash-1017, and support for the DeepSeek Search and Fetch API (enabled in web search settings). The real payload is rc.1. I counted the Chinese release notes: 102 changes.

Four of them relate to plugin distribution:

• Allow users to discover and install plugins from custom plugin index sources
• New “Let the Agent create a plugin” entry on the plugin management page; you can keep a draft and enter creation mode, and execution only starts after you send the requirement
• Support for enabling, disabling, uninstalling and dependency sync after plugin updates; with hot reload enabled the update takes effect immediately, otherwise it prompts for a restart
• Version compatibility for third-party plugins is judged by engines.dsh first, falling back to the old rules when it is not declared

The last one looks unremarkable. It is the star of this round of pain.

What an index source actually is

The docs split this capability into three pieces: a Host service that reads indexes, an index format spec, and a discovery page in the web client. The optional meta-package mounts it as a single row, plugin-market.

The service has very few config options, and the defaults are all documented in the schema and README:

One detail deserves its own paragraph: with no index sources configured, the Host sends zero market requests. In other words this feature is completely silent until you add an address yourself. It does not quietly phone some server.

The index itself is JSON, with the format version pinned in a field (format: 1). The top level has a title, description, metadata (categories, tags, sort keys) and a plugin list; each plugin has a name, title, description, author, repository, and a list of versions; each version states the version number, publish time, source and compatibility range.

Sources come in two kinds. The npm type is a package name plus an optional custom registry. The git type requires a full url, a commit, and an optional subdirectory. The install expression is computed by an official function, and a git version gets pinned to that commit, in the form git+https://github.com/…/repo.git#7c4d0ef….

I hand-wrote one in that format with two real third-party plugins, then validated it with the validator in the package. First attempt, rejected outright:

must be an integer number of Unix seconds in [0, 10^11)

publishTimestamp wants Unix seconds. I had filled in milliseconds. After fixing that, validation passed and both plugins produced install specs, the git one carrying the full commit hash.

Three walls: installing a plugin is not one command

The configuration layer looks clean. Actually installing it, I hit three things in a row.

The first wall is the version guardrail. I installed the optional meta-package the usual way, and pnpm resolved 0.2.1-alpha.4. dsh disabled that row at startup:

disabling profile plugin row “plugin-market”: Plugin @deepseek-ai/dsh-plugin-market@0.2.1-alpha.4 is incompatible with dsh 0.2.1-rc.2: requirements {"@deepseek-ai/dsh-plugin-manager":“0.2.1-alpha.4”, …}

It does offer a way out: if you want to take the risk, write a version exemption with dsh plugin allow-version, or click it in the plugin manager. Nothing in the UI looks wrong. The feature is just gone. This is the most standard cause of “I installed it and nothing happened.”

The second wall is the new-release cooldown policy. Fine, install the exact version 0.2.1-rc.2. pnpm prints one line, Packages: -8, installs nothing at all, and exits 0.

Digging in, it is pnpm’s minimumReleaseAge blocking: releases that are too new have to be listed in minimumReleaseAgeExclude in pnpm-workspace.yaml before it will install them.

Running pnpm add -w directly, it added nine exclusion entries on its own before the 27 packages went in. That release note line about “when the new-release cooldown policy forces an older version, provide an explanation and an exact-version install path” describes exactly this mechanism. It just does not say it loudly on the CLI side.

The third wall is a side effect. pnpm add pruned eight packages out of the profile along the way, on the grounds that they were only in the profile’s bundles list, not in dependencies. Next startup reports:

cannot resolve profile bundle “@deepseek-ai/dsh-experimental-agent-team-web-profile” from the dsh installation or /Users/trevorwang/.dsh/profiles/web

Of the three options, only installing it back is right. And that package only exists on the 0.1.x line on npm (0.1.6-alpha.2 at the highest), so after reinstalling the 0.2.1-rc.2 runtime, the first wall bit me again: the ui-agent-team row was also disabled for version incompatibility.

The same set of guardrails bit me twice in three hours.

Walking through the real UI

With the config sorted, the rest is verified in the UI. The path is plugin page, experimental plugins, more, then flip on Custom plugin markets. It is off by default, and while it is off the plugin page only has an Installed tab.

Turn it on and Discover appears, with a very direct empty state:

No plugin markets yet Add a plugin market index to browse and install its plugins here.

Click Add index source and the dialog gives you one explanation plus one warning:

A plugin market is published as the URL of one index file. Discover browses the indexes listed here.

Indexes come from third parties. Add only sources you trust: their plugins run with your permissions once installed.

I entered my own local address. The first fetch failed with connect ECONNREFUSED, because I had accidentally killed the local static server. After clicking Retry it worked, and the list showed the index name I wrote, with category filters All, Guard, Workspace — all of them declared in my metadata. The two plugins each carried Chinese UI and Experimental tags, with version, author and date on the line below.

Click Install and the confirmation dialog looks like this: plugin name, version 0.1.3, author LanFeng97, repository address, and Commit 7c4d0ef….

The commit pinned in the index appears verbatim in the dialog, along with the line “Plugins run on this machine with your permissions”. After install, the dialog echoes the git address and commit, and the button changes from Install to Enable now.

Afterwards the profile dependencies have one more entry:

dsh-workspace-create-dialog: github:LanFeng97/dsh-workspace-create-dialog#7c4d0ef91a0ad9d49efa71ec5a637a53e6d87b2f

The UI also did something I did not expect: it wrote the index source into the profile’s own patch layer, not into some hidden database.

- id: plugin-market
  name: "@deepseek-ai/dsh-plugin-market"
  config:
    indexes:
      - http://127.0.0.1:3489/index.json

Which means that address can be seen by others, committed to version control, and moved along with the profile.

One boundary to add: after clicking Enable now, dump-config still has no row for this plugin. It takes a process restart to take effect. I did not verify past that point.

What this index is good for

First, the honest word from the docs. The meta-package docs say it plainly: there is no official plugin marketplace yet, and the discovery page only lists index sources you added yourself. In other words, the value right now is not browsing a store. It is being able to open your own shelf.

For private plugin distribution that is enough. A few internal plugins, one JSON file, dropped on an internal HTTP server, and every machine that adds the same address can see and install them. Installation pins to a specific commit instead of always pulling the latest.

The costs deserve equal clarity. Indexes are not signed, so the names and versions in an index are only the market’s claim; what actually gets installed is decided by that package’s own manifest, which is why the dialog keeps warning you to add only trusted sources. There is no upgrade support: a plugin that reports update-available still has to be uninstalled and reinstalled. The same list is last-writer-wins, so two windows editing at once overwrite each other. And an index must be configured with its final URL; a 301 from the server is rejected.

There are measured performance numbers: an index of twenty thousand plugins builds its text index in about 0.8 seconds and uses roughly 130 MiB of heap; a 38 MiB index with a hundred thousand plugins blocks the main thread for about 190 milliseconds during deserialization. The docs themselves say larger markets will need server-side queries.

While I am here, another rc.1 item. I found the original strings for “Let the Agent create a plugin” in the installed client bundle: createPlugin is “Let the Agent create a plugin,” described as “Enter creation mode and build a DSH plugin of your own.”

There are three more status strings: checking whether creation mode is available, currently unavailable so reopen the menu and retry, and the current configuration does not provide creation mode. Creation mode’s own description is “Customize DSH through conversation: let the Agent write plugins, add new features or UI.”

The shelf is built, and the tool for making the goods is included. The remaining question is whether you want an agent writing plugins into your profile.

Do you have internal plugins that need distributing this way? Tell me in the comments.

Anyone writing an AI chat client runs into this: the model does not hand you the answer in one go. It dribbles out token by token, wedging tool calls, code blocks and stretches of thinking in between. The user staring at the screen is really watching a tree grow while someone keeps rearranging it.

The GetPullRequest team wrote a long post recently about how they built this in Flutter. The sharpest line is about Flutter’s official GenUI package:

It only drew the UI after the model’s full response had arrived and been parsed.

Which means it waits for the whole answer to arrive and be parsed before drawing anything. For a normal Q&A, waiting a few seconds is fine. For an agent doing twenty minutes of work, it is not: the tool card should have appeared long ago and you are still looking at a spinner.

I reproduced the key scenarios from that post on macOS and measured them. Three pitfalls here, each with a number you can produce yourself.

Pitfall one: re-parsing Markdown on every token

The most naive approach: a slice of text arrives, you throw the accumulated full text at a Markdown parser, get the node tree, render it. Looks like the obvious thing to do. The cost is that you re-parse what has already been parsed, every single time.

I took an 886-character agent reply as a sample: prose, a three-row table, a dart code block, a two-level nested list. I sliced it into 222 four-character chunks to simulate streaming. Here is how the three approaches compare.

28 milliseconds does not sound like much, but it is not spread evenly across 222 chunks. The first 50 chunks average 0.046 ms, the last 50 average 0.199 ms. It gets more expensive as you go, because the accumulated text gets longer. This is quadratic work: for an 886-character reply, the naive approach processes about 98K characters, 111 times the original.

Real-length answers make it obvious. Same approach, reply length doubles, time goes up two to three times:

886 chars / 222 chunks: 16 ms
1774 chars / 444 chunks: 61 ms
3550 chars / 888 chunks: 229 ms
7102 chars / 1776 chunks: 899 ms

A frame budget is 16.7 ms. By the 3550-character tier, just parsing the tail eats several milliseconds, and add layout and paint on top and dropped frames are inevitable.

The post’s fix is block-level incrementality: completed blocks parse once, only the growing one is re-parsed, and “notify the UI on every chunk” becomes “coalesce notifications into one microtask.”

Line-by-line parsing shreds the structure

There is a sneakier pitfall, tied to a product requirement: letting users select and comment on individual lines. If your render layer is one widget per line and each line is parsed separately, Markdown structure falls apart.

The same content, parsed line by line, produces this tag sequence:

[p, p, p, p, p, pre, p, p, pre, ul, li, pre, pre]

Parsed in chunks it produces this:

[p, table, thead, tr, th, th, tbody, tr, td, td, tr, td, td, pre, ul, li, li, li]

Compare the counts. The table: 0 tables when parsed line by line (a four-row table turns into five lines of pipe-separated text), 1 when parsed in chunks. The code block: 4 pre tags line by line (it should be one unit), 1 in chunks. The nested list: only 1 li line by line (it should be three levels), 3 in chunks.

The nested list case is the easiest to miss. In Markdown, four leading spaces mean “this is code,” so the moment the second level of a list gets parsed on its own it turns into a code block, shown on screen as a grey box with a bare minus sign in front of it.

One more basic pitfall while we are here: the markdown package only parses tables with the extension explicitly enabled. The default Document() yields 0 tables; switch to ExtensionSet.gitHubWeb and you get 1.

And one that is specific to streaming: a chunk can break in the middle of three backticks. When I fed that half-finished text to the parser, the one or two trailing backticks became literal characters in the body, so two lonely ` pop up on screen and only turn into a proper code block when the next chunk arrives. And if it happens to be a complete triple backtick with no content yet, you immediately get an empty code box.

Pitfall two: you scroll up, it yanks you back to the bottom

The chat list is reversed (newest at the bottom, offset 0 is the bottom). The user scrolls up 300 pixels to reread history. A new token arrives, and if the code does no checking and just scrolls to the bottom, the view is dragged back 300 pixels by force.

Measured: offset jumps from 300 to 0, the viewport is pulled 300 pixels. The paragraph being read vanishes.

Change it to “only auto-scroll when within 200 pixels of the bottom” and at that same offset of 300, the offset stays at 300 when new content arrives. The user is left alone.

The second source of jitter is card expansion. A card above the viewport grows from 100 pixels to 400, visible content shifts 300 pixels, and whatever was under your finger drifts away. The fix is to measure the height difference first, then after that frame’s layout, move the scroll position back by the same distance. Measured: compensating 300 pixels leaves 0.0 pixels of residual anchor drift.

The post also mentions the reverse case: expanding is easy, collapsing is hard, because Flutter has already adjusted the scroll position before you get a chance to fix it. You have to remember the position from before the change.

Pitfall three: treating one long reply as one widget

The first two pitfalls live at the text layer. The third is at the list layer. The old way stuffs one reply into a single Column with tens or hundreds of blocks inside. The problem is that as soon as Flutter sees any part of that widget on screen, it has to build the entire Column.

Measured with 500 blocks:

232 ms is fourteen frames. It janks the first time you open it. A 30 ms update also drops two frames. Split into blocks, the first render builds only 14 and is an order of magnitude faster.

Then there is notification frequency. Twenty chunks arrive in one event loop. Call notifyListeners() on each and the UI is asked to refresh 20 times. Coalesce them into one microtask with a small flag and you get 1 notification. Same result on screen, nineteen copies of wasted work gone.

The line from that post I agree with most, and the conclusion of all three sections:

the widget that owns a stream should be the smallest widget that shows it.

Which means: whoever owns the stream owns the listening. Do not let one big thing listen on your behalf.

How to read these numbers

The caveat first: these were measured in a headless flutter test environment, counting CPU time for parsing, building and layout, excluding GPU rasterization. So read them as magnitudes and relative differences, not as real-device frame rates. On a real device you also pay for font shaping and image decoding, so it only gets worse.

The three pitfalls are three facets of one thing: all of them pay repeatedly for content already processed. Full re-parsing re-parses. One widget for a whole reply rebuilds. Notify-per-chunk refreshes. What needs fixing is not three pieces of code but one habit.

One unavoidable piece of context: many people reach for flutter_markdown and hand Markdown to the official package, but it is unmaintained on pub.dev. The last release stopped at 0.7.7+1 in May 2025, and the package page points to flutter_markdown_plus as the successor. On streaming rendering, the official path is currently broken, and the community and every client vendor are writing their own.

How do you handle streaming Markdown? Chunk-by-chunk parsing or full re-layout? Tell me in the comments.

The most common way to make an agent drive software right now is to let it look at screenshots, find buttons, and click coordinates. It works, but it is brittle. Resize a window, move a button a notch, let a page load half a beat slow, and it starts clicking blindly.

A team at HKU put the problem with this approach bluntly:

Current GUI agents struggle with brittle pixel-level interactions, timing dependencies, and coordinate-based actions that break with interface changes.

Meaning: today’s GUI agents get stuck on fragile pixel-level interaction, on timing dependencies, and on coordinate actions that break the moment the interface changes.

Their alternative is almost surprisingly plain. Stop making the agent look at the screen. Give the software a command line.

CLI-Anything turns this into a pipeline

The project is called CLI-Anything, under HKU’s Data Intelligence Lab (HKUDS), backed by a paper titled “CLI-Anything: Towards Agent-Native Computer Use”. When I looked on October 16 it had 53,122 stars, Apache-2.0, written in Python.

What it ships is a repo plus a hub. Installing the hub itself is one command:

pip install cli-anything-hub

After that you get 103 command line tools to choose from: 79 are harnesses they wrote for specific software, 24 are existing third-party packages, covering 35 categories. Pick one, again one command:

cli-hub install 3mf
cli-hub install ollama

Naming is uniform. After install the entry points are cli-anything-3mf, cli-anything-ollama.

There is another layer called the capability matrix, five tables organizing CLIs by scenario (video 14, knowledge research 13, games 9, image and design 7, 3D CAD 6), with built-in gap checks and task recipes. Ask it something like which tools do I need to make a short video, and it lists who provides each capability point and what is missing.

Install one CLI, the agent gets three things

The first is a skill file written for the agent to read. Every harness has a SKILL.md covering what the software does, how to type the commands, and where the pitfalls are. They also ship matched skill packs for Claude Code, Cursor, Codex and Hermes.

The second is structured output. Almost every command takes --json and returns machine-friendly JSON instead of a screen of text formatted for humans.

The third is session state. Harnesses are stateful: there is a session group of subcommands to manage state, plus a REPL mode. Meaning the agent can work step by step like a person, without re-explaining the context every time.

Hands-on: three apps, three endings

I actually ran it on this Mac, picking three that could both install and produce real results: 3MF, Ollama, LLDB.

Start with 3MF, a 3D printing file format. The harness finds cylindrical holes, resizes them, repairs meshes. I used trimesh to build a 20×20×10 plate with a 3.0mm through hole in the middle, then let the CLI find it:

cli-anything-3mf --json inspect --axis 2 plate-with-hole.3mf

{
  "hole_count": 1,
  "holes": [
    {
      "hole_id": 0,
      "center": [-5.09e-18, -9.34e-06],
      "diameter": 2.9988,
      "axis": 2,
      "confidence": 0.9996,
      "vertex_count": 128
    }
  ]
}

Ground truth is 3.0mm. It reported 2.9988, a 4 micron error. Then resize the hole to 4.2mm:

cli-anything-3mf resize -h 0 -d 4.2 -o plate-4.2.3mf -a 2 plate-with-hole.3mf
# Resized 1 hole(s) to 4.2mm
# Hole 0: 2.999mm -> 4.200mm (128 vertices)
# Saved: plate-4.2.3mf

Took 0.33 seconds. Check again after the change, the reported diameter is 4.1983. Finally I had it diff the two files: volume dropped from 3929.43 cubic millimeters to 3861.68, a loss of 67.75.

You can check that number yourself: hole from 3.0 to 4.2 on a 10 thick plate, the theoretical removal is π/4 × (4.2² − 3.0²) × 10 = 67.86 cubic millimeters. Against its 67.75 that is a 0.16% difference, exactly the error from approximating a circle with a 128-sided polygon.

Next, Ollama. This machine already had Ollama installed with two models, bge-m3 (embeddings) and gemma4 (an 8B chat model). The harness wraps the local service:

cli-anything-ollama --json model list      # list local models with digest and quantization level
cli-anything-ollama --json embed text -m bge-m3 -i "wrap software as command lines"
# → 1024-dim vector, norm 0.999999, 1.77 seconds

cli-anything-ollama --json generate text -m gemma4 -p "explain in two Chinese sentences..." --no-stream --num-predict 1024
# → 647 tokens, 22.99 seconds, returns real Chinese text

Here I hit a pitfall worth mentioning. The first time I only gave it a 60 token cap, and the returned response was an empty string, which looks like the model did nothing. But the same JSON said eval_count: 60 and done_reason: "length", meaning it did generate 60 tokens, they were all spent on internal reasoning, and it hit the cap before reaching the actual answer.

Raise the cap to 1024 and the text appears. Anyone writing agents should remember this: an empty string from a local model does not necessarily mean nothing was generated. Check done_reason and eval_count.

The third is LLDB, the debugger. It installs, but it will not actually debug on this machine, because the system lldb is stuck behind the Xcode license gate. What is interesting is how it fails:

{
  "error": "LLDB not found. Install LLDB:\n  macOS:  xcode-select --install\n  ...",
  "type": "RuntimeError"
}

Exit code 1. It did not dump a stack trace on me. It put the raw stderr it probed, the platform install command, and the error type into one JSON object. That is an agent-friendly way to fail: read one field and you know what to do next.

After all three, the comparison looks like this:

The on-ramp and a few pitfalls

The install was more painful than I expected. All the pitfalls are concentrated there.

cli-hub install calls pip internally, so the Python environment the hub lives in must have pip. Installing with uv tool install cli-anything-hub (nice because it does not pollute global) leaves no pip in that environment, and this subcommand immediately fails with No module named pip. If you want the official flow to work, create a virtualenv with pip and install there.

It installs packages from git, and behind a proxy you hit two network problems. First Error in the HTTP2 framing layer. After temporarily dropping git’s http.version to 1.1, it became SSL_ERROR_SYSCALL, the link itself was flapping. The safe path is to skip git, download the repo tarball and install locally:

curl -L https://codeload.github.com/HKUDS/CLI-Anything/tar.gz/refs/heads/main -o repo.tgz
tar xzf repo.tgz && cd CLI-Anything-main
python -m pip install ./3MF/agent-harness

On macOS there is another layer: /usr/bin/git is a shim blocked by the Xcode license gate, and the moment pip calls git version it dies with exit code 69. The git inside the Xcode bundle works, just put it ahead of /usr/bin in PATH.

There are two small annoyances in use. --json is a global option, so it has to come before the subcommand (cli-anything-3mf --json info x.3mf). Put it after and you get an unknown option error.

Also, 3MF hole finding returns hole_count: 0 on my plate without --axis, and only recognizes the hole when you specify --axis 2 (the hole runs along Z). And when resizing you have to use the same parameters as when finding, otherwise the hole numbering does not line up.

The capability matrix has a query: cli-hub can "transcribe audio". Natural language does not always hit. In my test that sentence returned No capability matches. You have to ask using its own vocabulary.

What about MCP

At this point it is easy to slide to the conclusion that command lines will replace MCP. That is not what they do.

Look through its catalog and several harnesses wrap MCP servers internally. The zotero one for papers describes itself as dual-form, CLI plus MCP server, 52 MCP tools and over 70 CLI commands. The Safari one wraps safari-mcp. The browser one wraps an MCP implementation called DOMShell.

My reading is that the roles are layered: MCP solves how a service exposes its capabilities, command lines solve how an agent types out an action. The former needs a service outside the process, a connection, and a tool list read in. The latter is one command and a blob of JSON. This project bets on the generality of the latter, and even its own 103 CLIs are distributed through pip, the oldest channel there is.

Which of the two saves more tokens and which fails less often needs a real head-to-head run before I would call it. This post just gets the pipeline working.

Which piece of software would you wrap first? For me it is the old tools that only have a GUI and no batch interface. Tell me in the comments.

Completion is guesswork, go-to-definition is luck, and you do not dare press rename. On October 15, JetBrains turned the Java and Kotlin engine from IntelliJ IDEA into a language server extension and shipped 1.0, installable in VS Code, Cursor, and Google Antigravity.

Below, VS Code means Visual Studio Code and IDEA means IntelliJ IDEA.

I ran it against an Android project on this machine for a full pass. The engine really is IDEA’s. But there is one condition you should know up front: the intelligence is not in the editor, it is in a server the extension downloads for itself after launch, and that server wants a license.

What it actually delivers

The capability list from the official 1.0 release notes, plus what the extension itself reports, gives you this in practice:

• One index across mixed projects. Java, Kotlin, and projects mixing both are all understood, and jumping to a definition on the other side does not break the chain. That means no more installing three or four language plugins at once, and no more worrying about them fighting each other.
• Completion, navigation, inspections, quick fixes, rename, formatting. These are the highest-frequency moves day to day, and they are this extension’s selling point.
• Maven, Gradle, and Bazel are all understood, JUnit runs, and large repos do not choke.
• A debugger with simulated breakpoints and async call stacks, which is useful for coroutine-heavy code.
• Cursor’s Agents Window gets dedicated support: it can be given its own language server instance so the agent gets analysis built on IDEA’s inspections, including JSpecify null-safety and special handling for the Spring framework.
• The language server also ships an MCP server, built with ktor’s SSE and the MCP Kotlin SDK. The team does not promote this much, but for anyone who wants agents to consume code intelligence directly, it is a new path.

One recommendation worth following: it overlaps with the Java extensions from Red Hat and Oracle on inspections and quick fixes, and the team explicitly recommends disabling those two when running both. Spring Tools does not conflict and can stay.

Installing takes one command

Set expectations first: the package you download from the marketplace is only 1.4 MB. The actual intelligence is downloaded at runtime.

So “install a plugin” is split into two halves: a shell in the editor, and 361 MB on JetBrains’s servers. The shell holds only commands, settings, and grammar files — not one line of language analysis code. The unpacked server takes 1.2 GB and bundles its own JetBrains Runtime 25.

For a command-line install, VS Code looks like this:

code --install-extension JetBrains.intellij-server --force
code --list-extensions --show-versions
# jetbrains.intellij-server@1.0.27

1.0.27 shipped packages for six platforms — Apple silicon, Intel, two for Linux, two for Windows — all released on the same day, October 15. Editors like Cursor pull from Open VSX; VS Code pulls from Microsoft’s marketplace.

Of those 43 settings, only a few are worth touching

The extension adds 43 settings to the editor, and the overwhelming majority should stay at defaults. These are the ones I would change:

That last one deserves a note. The default of -1 means “start one myself”; set a port number and it becomes “connect to that one.” The switch existing at all tells you the team designed this language server as a standalone process, and the editor is just its first client.

So I skipped the editor and talked to the server directly

If it is a standalone process, there is no reason to go around it. The installed package has an executable called intellij-server. Start it and read the flags — the surface is bigger than what the editor exposes:

./bin/intellij-server --help
# --stdio                     stdio mode, for editors
# --socket=127.0.0.1:9999     server mode, default port 9999
# --port-file=<path>          write the bound port to a file so clients can find it
# --idle-timeout=10m          exit when no client is connected
# --multi-client              allow multiple clients at once
# --data-sharing=none         turn telemetry off
# --system-path=<path>        where caches and indexes go

One more detail is fun: first launch asks you for a EULA hash, and that hash is the first 16 characters of the SHA-256 of the EULA.txt in the package. What it is asking you to confirm is “I agree to this version of the terms.” Change the terms and the hash changes.

I wrote a hundred-line Python client and spoke the LSP protocol at it directly:

The handshake took 1.4 seconds. It reports itself as IntelliJ Language Server by JetBrains, version ILS-263.7084.0, corresponding to the 2026.3 platform. It reported back 25 capability keys, 22 of them Providers: completion, navigation, rename, inlay hints, semantic highlighting, type hierarchy, call hierarchy are all there.

Then I asked it to import that Android project on this machine, and it actually did it. The log listed the Gradle model item by item, from ModuleSourceSets to AndroidProject, ending with Successfully imported.

Numbers, for the record: the first import (Gradle daemon has to start, dependencies have to resolve) took 21 seconds; with the daemon and caches warm, an import takes 978 milliseconds, and 10.5 seconds from process start to ready. On memory, the language server itself is 626 MB, and the Gradle daemon it spawns adds another 914 MB — and the daemon survives after you shut the server down, waiting out a three-hour idle timeout before exiting.

Here is the wall: no license, no answers

All of the above is the good part. Now the thing nobody tells you before you install.

The server is up, the project is imported, the ready notification has been sent. Then I request a completion and get this back:

{"code": -32802,
 "message": "Request refused: no active JetBrains license."}

Hover, document symbols, go-to-definition, one after another — same code, same sentence every time. It can connect, compute, and import. It just will not hand you the results. A quick license status query gives its side of it: not licensed, feature requests are parked.

The team is blunt about it in the release notes:

With version 1.0, the extension moves out of its free preview phase. Using it now requires an IntelliJ IDEA Ultimate subscription after a 30-day trial period during which you can try out its full feature set for free.

The same notes have a line worth more attention:

The license is explicitly designed for human use; we’ll release an update regarding licensing models for purely agentic use soon.

In plain terms, the license is granted for human use, and the rules for agent-only use will be announced later. Which is an admission that this part is not settled.

They do give you the commands for unlocking it:

./bin/intellij-server license login      # JetBrains account; --code mode suits environments without a browser
./bin/intellij-server license activate <activation code / license file / floating license server>
./bin/intellij-server license trial      # anonymous 30-day trial

You can also feed a key straight in through the INTELLIJ_SERVER_LICENSE environment variable, but it only lives in memory and is gone on restart. In other words, this layer is not a toggle inside the editor. It is a server with its own license state.

A few traps you will genuinely hit

• That 361 MB is downloaded by the server, not by you. When the download fails the editor only shows a vague notification; the real error is in the server’s own log, and the log path is printed on first launch.
• It spawns a Gradle daemon for your project, using the Gradle wrapper already in your project. First time you open a large project, do the memory math as “server plus daemon,” not just 626 MB.
• The extension requires VS Code 1.105.1 or newer and Node 22.20 or newer. Older versions will not install it.
• The day your license expires there is no loud noise. Syntax highlighting stays, because the editor’s own grammar files handle that, but completion, navigation, and refactoring all go quiet together.

Closing

This extension changed one of my assumptions. I used to think of an IDE’s language intelligence as part of the editor. Now it looks more like a subscription service, with the client as a shell. JetBrains played this smartly: sell one engine once inside its own IDE, and sell it again inside other people’s editors. For developers, the cost is one more server to keep an eye on.

What Kotlin plugins are in your editor right now, and would this make you swap them out? Talk in the comments.

First one. You paste a chunk of logs into your agent client to chase down a problem, and the logs carry a line DEEPSEEK_API_KEY=sk-.... Problem solved. That line is still sitting in the session history.

Next time you screenshot the session for a group chat, or export a transcript, the key goes with it.

Second one. A session runs for hours, the context keeps stacking up, and you’re near the window limit. The old workaround was to start a new session, and the cost was losing every conclusion you’d already talked your way to.

Neither hole is new. DeepSeek Harness (dsh from here on) shipped official fixes for both in 0.2.1-alpha.3 on October 14. Their words:

Detects keys and tokens in messages already sent, masks them by default, reveals on demand. Minimal mode supports reading images and auto-compacting long conversations; Web and desktop can compact context manually with the /compact command.

I upgraded the copy on my machine and ran both.

Upgrade: one command, one small trap

I had 0.1.6-alpha.2 installed globally via npm. The upgrade is one line:

npm i -g @deepseek-ai/dsh@0.2.1-alpha.3

Spell out the version, because the tags on npm currently look like this:

alpha:  0.2.1-alpha.3
latest: 0.2.0-rc.2
next:   0.2.0-rc.2

latest actually points at the older 0.2.0-rc.2. A plain npm i -g @deepseek-ai/dsh won’t get you the newest build.

During the install, npm 12 blocks install scripts for five packages:

npm warn install-scripts 5 packages had install scripts blocked because they are not covered by allowScripts:
npm warn install-scripts   @deepseek-ai/dsh-subprocess-local@0.2.1-alpha.3 (postinstall: node scripts/ensure-spawn-helper.mjs)
npm warn install-scripts   koffi@3.1.1 (install: node ./cnoke.cjs -P . -D src/koffi --prebuild --release)
npm warn install-scripts   node-pty@1.2.0-beta.15 (install: node scripts/prebuild.js || node-gyp rebuild; postinstall: node scripts/post-install.js)

There are native modules in that list. I didn’t allow them this time, and everything ran fine afterwards — terminal and file I/O both normal. To be safe, allow them the way npm suggests and install again:

npm i -g --allow-scripts=@deepseek-ai/dsh-subprocess-local,koffi,node-pty,@google/genai,protobufjs @deepseek-ai/dsh@0.2.1-alpha.3

One more tip. I pointed the config directory somewhere else (DSH_HOME=/tmp/dsh-021a3) so I could test the new build without touching the config and sessions I use every day.

Confirm the version after install:

$ dsh --version
0.2.1-alpha.3

Test one: key masking

I sent a message in the input box with two fake credentials: one starting with sk-, one GitHub token starting with ghp_.

After sending, the message shows up in the conversation like this:

sk-12345 followed by a run of asterisks, same for ghp_AbCd, with an eye icon at the end. The first few characters stay, the rest is masked.

Click the eye and the first credential shows in full, while the second stays masked. It doesn’t unlock the whole message, it’s per-item.

The masking holds in session history too. Screenshot it later or export the transcript and no plaintext comes with it.

Test two: /compact

This round I measured with real numbers. The method: drop a large file into the workspace, have the agent read it to inflate the context, then compact by hand.

First round read a 54 KB changelog. When it finished, the indicator at the bottom was at 3%. Running /compact:

A line appears in the conversation — compact · Compacted 12 history items (~18538 tokens) — and usage drops back to 2%.

Second round used a 224 KB document. Usage shot to 9%, compacted again, and this time it cut 16 history items and about 60,107 tokens, dropping usage back to 3%.

One action saves 18k to 60k tokens. What gets compacted is history messages; conclusions and state stay, so you can keep talking.

The official notes add that in minimal mode long conversations compact automatically, so you don’t have to think about it. Manual /compact is for actively freeing space during a long session.

Also found: where headless gets its key has changed

Anyone writing scripts or running CI should pay attention to this one. Same new build, headless mode with no key:

$ dsh headless "只回答两个字：收到"
dsh: MISSING_CREDENTIAL: llm-deepseek: no API key for provider route "deepseek-official";
store DEEPSEEK_API_KEY through the credentials service (the web Models page writes it),
or export DEEPSEEK_API_KEY in the launching environment

Put DEEPSEEK_API_KEY in the environment and run again, and it answers normally.

The official notes list this under other changes: Web and desktop prefer saved credentials, while headless now defaults to environment variables and .env and no longer reads saved keys. Scripts that used to run headless off the credentials service will hit that error above after upgrading.

From 0.2 to now, what changed across five releases

Let me straighten out the version line first:

0.1.6-alpha.2 (what I had) → 0.1.7-rc.2 → 0.2.0-rc.1 (09-28) → 0.2.0-rc.2 (09-29)
→ 0.2.1-alpha.1 (10-03) → 0.2.1-alpha.2 (10-09) → 0.2.1-alpha.3 (10-14)

Start from 0.2.

0.2.0-rc.1 is the first release candidate of the 0.2 series and rolls up the main changes since 0.1.7-rc.2. Automation tasks moved to an optional plugin package instead of being built in.

Sessions using a DeepSeek account model get web search without configuring a key separately. After a tool scheduling error the conversation can continue, but operations that already ran with unknown results prompt you to verify side effects first instead of blindly retrying.

Images that go stale get re-uploaded automatically to continue the request. Untitled history sessions now all display as “Untitled”. On Windows there’s a new sandbox permission diagnostic skill that can do permission repairs with a backup.

0.2.0-rc.2 stuffed the CLI into the desktop app’s menu bar. Installing the dsh command and managing plugins no longer needs a separate Node or pnpm.

The model picker supports search when there are many models. The third-party model catalog went up to pi-ai 0.87.1, some old model IDs were removed, and saved selections may need picking again.

Launching from the graphical entry point now inherits the login shell environment, so tool paths and proxy config are readable in the session. An experimental async Q&A mode was added; you have to turn it on yourself.

0.2.1-alpha.1 adds an experimental Claude Code Mods compatibility layer. The official word is blunt: at this stage the point is mainly to confirm that the Mods API’s capabilities are roughly a subset of dsh plugins, full compatibility isn’t the goal.

The plugin management page gained a “let the Agent create a plugin” entry that holds the draft in creation mode and only starts working once you send the requirement. Web supports --public-url, so it can sit under a subpath behind a reverse proxy. A new developer tooling bundle can show raw session logs and do two-way navigation between chat groups and the body text.

This release also has breaking changes: the runtime invariant plugin and each package’s ./invariant export were removed, the input-area stats extension split into two registration IDs, activity and usage, and extensions that depend on those have to follow.

0.2.1-alpha.2 adds two experimental plugins. One is machine translation of the thinking process, with Bing, Google or paid DeepSeek Flash as options; the other is Git Worktrees, letting the Agent create and enter its own separate checkout.

Plugins now have an interface for recording their own session state. Global instructions can read AGENTS.md from a shared agents directory, set with DSH_AGENTS_HOME. A new working_directory tool lets both the TypeScript and Python SDKs read and switch the session’s working directory.

The Official plugin list gained on-demand install entries for the Claude Code and Codex bundles. One fix matters a fair bit to Chinese users: local SenseVoice speech recognition was cutting off the start of recordings and dropping the first character when VAD was on. That’s fixed.

0.2.1-alpha.3 is the build I tested above. Besides key masking and context compaction, it adds logging into a DeepSeek account when the Web version is reached over local HTTP, image reading in minimal mode, an independent Agent Preset per sub-agent, and an optional in-memory mode for PTC’s Node execution environment.

Model settings hints got clearer and now show credential source and detection status, and the API Key can be revealed on demand. On the fix side, a few annoying ones are gone: some sessions couldn’t continue after a restart, switching to DeepSeek failed on historical message compatibility, plugins kept running old code after an update, and tasks left incomplete after an unexpected app exit were mistaken for completed.

Strung together, the main line through 0.2 is pretty clear. The plugin system is heading toward everything-is-a-plugin, with compatibility layers, bundles and plugin-owned state all filling in. Credentials and context — the two security and cost issues easiest to overlook — got put on the table. And the Agent’s scheduling, delegation and recovery keep getting thicker.

One last thing

Key masking isn’t hard to build. What’s hard is someone admitting that users really do paste keys into chat boxes. Same for context compaction: long sessions are the norm, not the exception.

The agent client you use every day — how many plaintext keys are sitting in its session history right now? Comments are open.

You have an agent write some Kotlin. It says it’s done. Now what?

You open Android Studio yourself, watch Gradle spin, wait for the emulator, then poke the screen with your mouse to check whether that string actually changed. Inside the terminal the agent flies. At the point where you need to look at the screen, the chain snaps, and the rest of the work belongs to your eyes.

That gap is what Google just filled. Android CLI is at 1.0 stable. Their words:

Whether you use Gemini in Android Studio, Antigravity 2.0 or Antigravity CLI, or a third-party agent like Anthropic’s Claude Code or OpenAI’s Codex, our mission stays the same: make high-quality Android development possible anywhere.

Blunt enough. Whichever agent you use, they want you to stay in the terminal. I ran it end to end on this machine, from creating a project all the way to looking at the screen.

What it actually ships

I’ll go through the list by what it saves your agent from doing.

One android command

After installing you get a single command, android, with 19 top-level subcommands. Creating projects, starting emulators, installing apps, looking at the screen, all of it:

auth completion create describe device docs emulator info init
install layout run screen sdk skills studio update help

Agents used to have to remember three sets of flags for adb, emulator and gradle. Now there is one entry point against one SDK. It installs a single 3.6 MB binary into your home directory, and afterward android info reports the SDK path and version.

The official skills library

android init is the interesting one. It takes no arguments, and when it finishes it has written a 24,922-byte android-cli skill into every agent’s skill directory on your machine. It hit 10 on mine:

~/.claude/skills          ~/.gemini/skills           ~/.agents/skills
~/.commandcode/skills     ~/.hermes/skills           ~/.junie/skills
~/.openclaw/skills        ~/.config/opencode/skills  ~/.pi/agent/skills
~/.gemini/antigravity/skills

Hermes is in there, along with Claude Code, Codex, Gemini, OpenClaw and OpenCode. Worth looking at which directories it wrote into after it runs. It is dropping files in your home, after all.

There are 24 skills in the library now; android skills list shows them all. On the UI side: adaptive, camerax (camera migration), edge-to-edge, wear-compose-m3 (Wear OS).

There are a few project-hygiene ones too: play-policy-insights, restore-credentials, testing-setup, r8-analyzer. Installing is one line, android skills add <name>, and you can pick which agent gets it.

An offline copy of the official docs

android docs search "edge to edge" downloads an index on first run. 5,319 entries, measured. What comes back is not a URL but a kb://android/... protocol address.

Even the sample code inside skills is in there, e.g. kb://android/agents/skills/wear/wear-compose-m3/references/material3/EdgeButtonSample.kt. Agents no longer have to search blogs. The official docs are queryable locally.

The look-at-the-screen commands

This group is the most useful thing in the release. screen capture --annotate labels the elements on screen as #1, #2, and screen resolve turns those labels back into coordinates:

android --no-metrics screen capture --annotate --output shots/12-annotated.png
android --no-metrics screen resolve --screenshot shots/12-annotated.png --string "tap #1 and #2"
# output: tap 72 31 and 835 30

The agent no longer does pixel math. It points at #3 and says tap this. layout in the same group returns the UI tree as JSON, with bounds and center point for every control.

Borrowing Android Studio’s semantic analysis

The new android studio subcommands: find-declaration for definitions, find-usages for references, analyze-file to run inspections, render-compose-preview to render a Compose preview, version-lookup for dependency versions, open-file to open a file in the IDE.

That means the agent borrows the IDE’s fifteen-odd years of semantic analysis instead of guessing with regex. There is a floor: Android Studio Quail 1 or later.

Booking a physical device

android device remote lets you book a remote physical device to run on. Their example connects to a Pixel 10 Pro. This path needs android auth and a Google account first.

I ran it from zero on macOS

Only a clean run counts. These are the commands I actually ran, none left out:

# install: download the script and read it first, don't pipe straight into shell
curl -fsSL -o /tmp/android-cli-install.sh \
  https://dl.google.com/android/cli/latest/darwin_arm64/install.sh
bash /tmp/android-cli-install.sh            # → ~/.local/bin/android, 3,650,880 bytes

android --no-metrics -V                     # 1.0.16500706, first run walks you through the Android SDK terms
android init                                # writes skills into each agent's skill directory
android --no-metrics skills list            # official skill catalog, 24 measured
android --no-metrics docs search "edge to edge"

# end to end: create project → start emulator → build → install → look at screen
android --no-metrics create --name CliDemo \
  --application-id com.example.clidemo --min-sdk 36 -o ~/android-cli-repro/CliDemo
android --no-metrics emulator list          # existing AVD on my machine: Medium_Phone_API_36.1
android --no-metrics emulator start Medium_Phone_API_36.1   # returns only when ready, about 17s
cd ~/android-cli-repro/CliDemo
./gradlew :app:assembleDebug                # first build: BUILD SUCCESSFUL in 1m 24s
android --no-metrics run --apks app/build/outputs/apk/debug/app-debug.apk
android --no-metrics screen capture --output shots/10-before.png
android --no-metrics layout

Project creation first. create produces a Compose + AGP 9 + Kotlin 2.3.20 project. I never touched SDK Manager. It noticed platforms/android-36 was missing and installed it.

emulator start is a nicely designed piece: it blocks until the device is fully booted, printing remaining seconds along the way, so you never poll adb yourself. Ready in 17 seconds for me.

What actually surprised me was the second run. I changed one string, listOf("Android") to listOf("Android CLI") in the data source, and ran the loop again:

./gradlew :app:assembleDebug                # incremental: BUILD SUCCESSFUL in 8s
android --no-metrics run --apks app/build/outputs/apk/debug/app-debug.apk
# Delta Install: Sent 167.94 KB patch instead of 28.67 MB (1 APK, 99.43% savings)

The first install pushed 28.64 MB. The second pushed a 167.94 KB patch, 99.43% saved. Delta install is on by default (--use-delta-install defaults to true), and for the change-a-string-and-look loop, everything you save is waiting.

Reading the UI tree with layout afterward, the string is already the new one:

应用窗口: CliDemo  焦点=True  边界=[0,0][1080,2400]
  - android.widget.TextView | text='Hello Android CLI!' | center=[220,136]

The entry bar and a few pitfalls

The one that trips you up fastest is run. Its description says build, deploy, launch. Without --apks, it just fails for me:

Error: No apks specified. Use --apks <path1,path2,...>
Component check failed

The APK was already built and describe had just located it. run still would not do it on its own. The actual split: producing the artifact belongs to the project’s own ./gradlew, run handles install and launch.

One more, sneakier. The package deploys but the UI does not change, because the old process is still alive and run will not force-kill it for you. Add adb shell am force-stop com.example.clidemo and run again.

There is a version floor too. The android studio commands need Quail 1 or later. Too old and you get No running Studio instances found, plus a line telling you to grab a newer build from the site.

Two more. android init writes files into your home directory, it is not a read-only operation, so if you have a lot of agents on the machine, read the list before you run it. And the subcommand is the singular device; android device list reports 'list' is not a valid command.

Also android completion writes shell completion into your shell config. Do not run it if you do not want that touched.

Telemetry deserves a line. The CLI collects data by default. The docs say what: which subcommand ran, the parameter names used, and a set of fixed values such as emulator template names and agent names (GEMINI, CLAUDE, CODEX). Add --no-metrics if you do not want it. Every command above carries it.

One last thing

This release did not invent a separate workflow for agents. It changed the things that already existed. Docs, skills, emulators, physical devices, IDE semantic analysis: all now exposed as interfaces a machine can read.

The details are handled too. Pixel coordinates become labels like #3, the UI tree comes back as JSON.

On your toolchain: would you hand the whole change-code-to-see-the-screen stretch over to an agent? Comments are open.

A general-purpose agent writing ArkTS will crash and burn, for exactly three reasons. It does not know ArkTS decorators or build commands; it has no official docs to look things up in, so it invents APIs from memory; and even when the code is right, it has no idea how to build the package, install it on a device, and ship it to the app store.

The holes can be plugged one at a time. Huawei and the community turned the plugging into tools you can bolt on externally, and going from nothing to usable is eight steps. This post walks them in order, with the command for each step and the output you should expect. At the end I wire all three pieces into a real agent, DeepSeek Harness, to see whether it actually buys it.

Four things to install

DevEco Studio, or its command line tools, is the foundation. Building, devices, signing, all the real work sits on it. @deveco/deveco-cli is the toolset, command name devecocli, and its job is installing capabilities into other agents.

The two MCPs do different jobs. The remote developer knowledge MCP handles doc lookup. The local deveco-mcp handles syntax checking for .ets and C/C++. The last piece is agc-cli, a community-written publishing CLI that drags AGC console operations back into the terminal.

Also get a Huawei developer account ready first. Installing the foundation and generating signatures both need it.

Step one: install the foundation

Go to the developer alliance download center (developer.huawei.com/consumer/cn/download/), log in, and pick the macOS build. On Apple Silicon you want the macOS ARM one.

Note the path after install. The default is /Applications/DevEco-Studio.app. You cannot skip this step, every real job devecocli does later depends on it.

If you do not want the whole IDE, the other path is the command line tools on the same page. Much smaller, but the official docs call one thing out:

Set DEVECO_CLI_CLT_PATH to the Command Line Tools root when DevEco Studio is not installed; CLT is not discovered automatically from PATH or default installation directories.

It will not be discovered from PATH or the default directory on its own. You have to point an environment variable at it by hand:

# IDE installed
export DEVECO_CLI_STUDIO_PATH=/Applications/DevEco-Studio.app
# command line tools only
export DEVECO_CLI_CLT_PATH=$HOME/command-line-tools

Put those in ~/.zshrc to make them stick. On first launch Studio walks you through downloading the HarmonyOS SDK. That needs network and it is slow, so do not sit there waiting somewhere offline.

Step two: install the devecocli toolset

Two npm packages together:

npm install -g @deveco/deveco-cli @deveco/deveco-code

You get two commands. deveco is the Agent itself, customized from OpenCode; devecocli is the toolset. 255 dependencies between the two packages, 267 MB.

Check it before moving on:

devecocli --help
devecocli device list

The second one lists connected devices. If it says DevEco Studio cannot be found, the problem is not this command, go back and check that environment variable from step one.

Step three: install the skill pack into your agent

This is the answer to the any agent half, one command:

devecocli init --skill --agent dsh,cursor,codex

Without –agent it installs into every host it recognizes. To install into a specific directory use –path, and add -f to overwrite existing config.

What lands looks like this:

node_modules/@deveco/deveco-cli-common/SKILL.md

24,690 bytes, and the trigger conditions at the top are blunt:

Use ‘devecocli’ for HarmonyOS apps (scaffold, build, run, debug, devices, emulators, logs, docs, UI inspection, 鸿蒙开发文档, skills). Use it if workspace has build-profile.json5 or oh-package.json5, or user mentions HarmonyOS, 鸿蒙, DevEco, ArkTS, ArkUI …

Once the agent reads that, hitting a HarmonyOS project or hearing the word HarmonyOS makes it think of devecocli on its own. The same package also carries an offline doc corpus. docs.zip is 40.5 MB, unpacking to 31,477 files, plus a 15.2 MB search index. That is what devecocli docs search queries, and it works without network.

Supported hosts are the official list: atomcode, codebuddy, claude-code, codex, cursor, dsh, deveco, opencode, pi, qoder, trae-cn. Eleven of them. For hosts outside the list there is a crude workaround: a skill pack is ultimately one Markdown file plus a doc corpus, so dropping it into that host’s skill directory is the same thing.

To install in bulk or see what is already installed, use the skills subcommand:

devecocli skills list
devecocli skills add --all

Step four: install the local syntax-check MCP

devecocli init --mcp

It configures deveco-mcp, a stdio MCP that exposes a single check tool, dedicated to syntax checking .ets, C and C++. Once it is wired into the agent, every round of edits gets self-checked before the agent moves on, instead of waiting for a full build to fail. The docs add one note: run it once per round of edits, not after every single edit.

One limitation from the docs: every supported host can configure global and project-level MCP, only qoder does not support project-level.

The service can be started by hand, which is useful when debugging:

devecocli serve mcp

It honors a few environment variables: PROJECT_PATH, DEVECO_PATH, and NODE_MAX_OLD_SPACE_SIZE for the Node heap cap.

Step five: connect the official knowledge MCP

This is the most universal piece. Any client that supports MCP just gets a block in its config:

{
  "mcpServers": {
    "harmonyos_developer_knowledge": {
      "url": "https://connect-api.cloud.huawei.com/api/developerknowledge/mcp",
      "type": "http"
    }
  }
}

DevEco Code ships its own MCP management command, one line:

deveco mcp add harmonyos_developer_knowledge \
  --url https://connect-api.cloud.huawei.com/api/developerknowledge/mcp

It reports status itself when done:

●  ✓ harmonyos_developer_knowledge connected

It only has two tools. searchDocuments searches by keyword and returns matching text blocks plus document IDs; getDocumentsById trades IDs for full text, ten documents max per call. Know the cost: about three thousand characters per search, thirty-five thousand per full document. Do not let it pull ten at once. The docs say this corpus syncs with the official site near real time, under 30 minutes of lag, and that is the most important difference between this path and letting the model answer from memory.

DeepSeek Harness as the example: how three pieces land in a real agent

The steps above covered what to do. This section runs through dsh to show where it lands. It happens to be on that official host list, so all three pieces connect automatically.

The skill pack is one command, landing in dsh’s own skills directory:

devecocli init --skill --agent dsh
ls ~/.dsh/skills

The directory structure is identical to its existing skills. One directory, one SKILL.md, two frontmatter lines at the top for name and description. This machine’s ~/.dsh/skills already had seven skills starting with memorix-, and deveco-cli now sits alongside them.

MCP goes into dsh’s config file cordis.patch.yml. Its config is layered profile patches, and MCP runs through its own mcp-client plugin, one record per service. The knowledge MCP goes in like this:

- insert:
    - id: mcp-harmonyos-knowledge
      name: "@deepseek-ai/dsh-mcp-client"
      config:
        serverName: harmonyos_developer_knowledge
        transport: streamable-http
        url: https://connect-api.cloud.huawei.com/api/developerknowledge/mcp

The local syntax-check MCP only swaps transport and the start command:

    - id: mcp-deveco-syntax
      name: "@deepseek-ai/dsh-mcp-client"
      config:
        serverName: deveco
        transport: stdio
        command: devecocli
        args: [serve, mcp]

It only recognizes two transports. stdio is a locally started process, streamable-http is a server. A few defaults worth knowing: 60 second timeout per tool call, 32,768 bytes cap on instructions from the server, and auto-reconnect on disconnect, up to ten attempts.

After editing, do not restart and guess. dsh has a dump command that prints the whole merged config:

dsh --profile <your profile> --patch ./hw-mcp.yml --dump-config

Once the config merges into the profile tree, the tool names really do show up in its tool table. I ran this with an isolated DSH_HOME:

mcp__harmonyos_developer_knowledge__searchDocuments
mcp__harmonyos_developer_knowledge__getDocumentsById

The naming rule is mcp, two underscores, service name, tool name, so several MCPs in the same agent will not collide. At this point, ask how to write a HarmonyOS interface inside dsh and it goes to the official docs instead of inventing something from memory.

Step six: login and signing

To run on a real device you cannot skip this.

devecocli auth login

It opens a browser for the Huawei developer account OAuth flow. Check login state with devecocli auth status, list joined team accounts with devecocli auth team list. Then generate a signature:

devecocli signature generate --product default

The order is spelled out clearly: auth login, signature generate, build, run. Not one step can be skipped. Each missing step has its error: not logged in gives Not logged in. Run devecocli auth login first, an expired token gives Invalid AccessToken. Sign in and try again, a changed signature gives error:install sign info inconsistent, at which point add –uninstall to run, or –force when regenerating the signature.

Step seven: install agc-cli

Publishing goes through AGC, which used to mean clicking through pages in a browser. This open source CLI turns the API into a searchable registry. In my test it had 159 endpoints across 13 families, each with method, path, required parameters, and a sourceUrl pointing back to Huawei’s official docs.

The Homebrew route needs you to trust its tap first:

brew tap createitv/tap
brew trust createitv/tap
brew install agc-cli

Or download the prebuilt binary from the official Release. There is a darwin_arm64 package, so verify the hash before using it:

shasum -a 256 agc-cli_0.2.0_darwin_arm64.tar.gz
./agc version

Three ways to configure credentials, pick one:

agc auth login --client-id <id> --client-key <key>
agc auth login --api-client-file client.json
agc auth login --service-account-file sa.json

agc auth check shows which one is active, agc auth list lists all stored profiles, agc auth token signs a temporary token for the current one.

By default it only rehearses. Before anything really goes out you see what the request looks like:

agc publishing app-info-query --invoke --query appId=123456789
{"data":{"method":"GET","url":"https://connect-api.cloud.huawei.com/api/publish/v2/app-info?appId=123456789&lang=zh-CN","dryRun":true}}

Once you are happy, explicitly add –dry-run=false to actually send it. Each endpoint’s response also carries an affordances block listing which command you can run next. The agent does not need to memorize the command tree, it just follows the response.

Step eight: run it and watch the agent check its own work

With all this installed, project to device is a straight line:

devecocli build
devecocli emulator list
devecocli emulator start "Phone"
devecocli run

The first emulator use needs a license, interactive with devecocli emulator license, which requires a TTY, or devecocli emulator license accept in scripts. If the image download fails, do not retry in a loop. The docs say plainly to hand that one to the user.

After the run, look at the two directories that appeared in the project. .verify holds verification artifacts, docs/screenshots holds screenshots, and the latter were produced automatically:

docs/screenshots
  01-home.png                          home
  03-quick-entry.png                   quick entry
  05-stats-mpchart.png                 stats charts
  06-stats-retry.png                   retry after stats failure
  08-trip-edit.png                     trip editing
  09-home-empty.png                    empty state
  10-real-device-home.png              real device
  11-real-device-trip-detail-finish.png
  12-light-home.png                    light theme
  15-dark-home.png                     dark theme
  19-dark-to-system-fixed.png

Numbers run from 01 to 19. Two of them are real device screenshots, meaning it installed the package on a device and actually ran it. Light and dark each get a set, meaning theme switching is in its flow too. There are empty states and the retry state after a stats failure, meaning it is not satisfied with the happy path and lays out the corner cases one by one. None of these were taken by hand.

The point of this step is the loop closing. Before, the agent handed you code and you had to look at whether it was any good. Now it can see the result itself, screenshots land as files, and the next round of edits has something to go on. This is also why I would file devecocli under tool rather than client: it is not the hand that writes code for you, it is the eye that lets the agent check its own work.

One verification command per step

Do not go by feel afterwards, walk through them one by one:

devecocli --help                  # toolset is there
devecocli device list             # devices are found
devecocli docs search ArkTS       # offline docs are there
devecocli skills list             # skill pack installed
deveco mcp list                   # knowledge MCP connected
devecocli auth status             # login state
agc auth check                    # AGC credentials configured
agc endpoints                     # registry readable

Whichever one fails, the problem is in that step, and you do not have to hunt around.

A bit of judgment

Of the four things, which would I install first? The foundation, because everything else is blocked on it. But if you only want to spend twenty minutes testing the water, connect the remote knowledge MCP first: one URL, no device, no account, and it plugs the most fatal hole.

Do not reverse the order. The skill pack and local MCP both hang off devecocli, and devecocli’s real work hangs off DevEco Studio. With a weak foundation, every later step hits the same sentence.

Do you let your everyday agent write HarmonyOS code? Where does it crash most often? Tell me in the comments.

A bit over a month ago, Claude Code refused to support AGENTS.md — the industry convention already adopted by plenty of projects and coding agents — and Shopify CEO Tobi Lütke publicly warned he was ready to drop it. Anthropic’s reasoning at the time sounded reasonable too: different models need different context and instructions.

A month and change later, the Claude Code team confirmed it will support AGENTS.md. But Thariq Shihipar, who owns that area on the team, went further on the Latent Space podcast:

I think, in the limit, CLAUDE.md disappears. And maybe we don’t even have to wait that long — I think if you start a new project now, you’re probably better off with no CLAUDE.md at all.

His four reasons

The first: the model’s floor is rising:

As models get better, the floor on the simplest tasks keeps going up.

The second is the most practical one, and it’s about order. Let it run first. Only when you keep seeing the same failure mode do you add the rule.

The third is counterintuitive:

If you keep this ever-growing log of failure modes around, chances are it over-constrains Claude.

The fourth is maintenance cost. This varies by model — you might need FABLE.md, you might need OPUS.md, and it can even differ between two versions of the same model. His words: maintaining different files is just painful.

So what should you write

In the interview the host, swyx, pointed at two things and said they matter too much to live only in a prompt. One is Goals, where the project is headed. The other is external artifacts that outlive a single session, things like decision logs and experiment logs. Thariq acknowledged in his answer that they still have to do AGENTS.md, but in the same breath he called maintaining multiple files the most painful part.

Follow that logic and the convention file’s role shifts from prohibition list to goals and record. Tell the model where the road leads. Keep the judgments you’ve already made in the file, instead of stacking twenty don’ts at the top. A prohibition list is a patch over the boundaries of an older model. Goals are not.

Local test: how convention files actually get loaded

I switch between several agent clients every day, so I went through the loading rules on this machine. Four things are worth writing down.

First, AGENTS.md support is recent. I went through the official changelog and it shows up in 2.1.277:

Added AGENTS.md support: in a project with no CLAUDE.md, Claude Code reads AGENTS.md instead; change it under “Project instructions” in /config

Note the positioning: in a project with no CLAUDE.md, Claude Code reads AGENTS.md instead. It’s a fallback, not a peer. And the build installed here is 2.1.150, older than that, so Claude Code on this machine still doesn’t recognize AGENTS.md.

Second, another client — I use Hermes daily, the thing talking to me in Feishu right now — takes a completely different route. It scans candidate files in the current directory by priority, lets one win per tier, and marks the rest shadowed:

not loaded — higher-priority context type wins

Third, it flatly refuses to read files inside other tools’ directories. The source says it plainly: subdirectory hints reject paths outside the working directory, so ~/.codex/AGENTS.md and ~/.claude/CLAUDE.md never leak in. The ~/.claude/CLAUDE.md on this machine is only 226 characters (one /graphify routing rule), and Hermes has never read it.

Fourth, loading has a ceiling. Subdirectory hints carry at most 32,000 characters, truncated head and tail beyond that. My project’s root file is 36,631 characters, so the back half has been getting cut off.

Do the math

I ran the local agent’s own tokenizer estimate over it:

   7151 chars   ~  1794 tokens  ~/AGENTS.md
    226 chars   ~    57 tokens  ~/.claude/CLAUDE.md
   9387 chars   ~  2357 tokens  ~/kmp-shop/CLAUDE.md
  36631 chars   ~  9234 tokens  ~/.hermes/hermes-agent/AGENTS.md

AGENTS.md in the hermes-agent repo: 12 files
169,982 chars total (about 42,496 tokens)

One repo, 12 convention files, over forty thousand tokens between them. It’s actually written with restraint — the root file itself says only global universal stuff goes here, each directory has its own AGENTS.md, target 8k characters — but the number is what it is, and you carry all of it every time you start work.

My call

Thariq is saying don’t hoard, not don’t write. Those two keep getting retold as one thing, and then everyone either deletes every file or keeps piling more in.

My own test is one line. If this rule corresponds to a specific failure, keep it. If it only corresponds to “I’m worried it’ll do the wrong thing”, that’s a guess, don’t write it yet. The first is a mistake the model actually made. The second is me imagining boundaries on the model’s behalf.

There’s also the layering. Don’t stuff repo-wide rules into one root file — that’s exactly where my 36,631 characters came from. What actually works is a small file per directory, and whoever works in a directory loads that one.

A ready-made example: this root file says target 8k characters, and it grew to 36k. Convention files need someone deleting things on a schedule, or they get fat on their own.

When was the last time you deleted something from your project’s convention file? Comments welcome.

Adding AI to Flutter used to mean two roads: stuff the model key into the app and call it directly, or hand-assemble requests with http. The first is handing over the keys; the second has you hand-crafting a shoddy framework by day three, patching in retries, streaming, tool calls and structured output one at a time.

On October 8, Genkit Dart shipped 1.0:

Today, we’re announcing Genkit Dart 1.0, the first stable, production-ready release of Google’s open-source framework for building AI-powered features and agents in Dart.

This post isn’t chasing the news cycle. It answers two questions: what 1.0 actually did, and what Dart developers can take away from it.

One API, four model providers

Gemini, Claude, OpenAI, and every OpenAI-compatible service go through the same interface. Providers register as plugins, so swapping models doesn’t touch business code:

final ai = Genkit(plugins: [googleAI(), anthropic()]);

final fromGemini = await ai.generate(
  model: googleAI.gemini('gemini-flash-latest'),
  prompt: prompt,
);
final fromClaude = await ai.generate(
  model: anthropic.model('claude-sonnet-5-5'),
  prompt: prompt,
);

For developers in China, the more practical part is the “OpenAI-compatible” bit: services like DeepSeek get a first-class handle in the genkit_openai plugin. deepSeek.model('deepseek-flash') is the entire config — no assembling a baseUrl by hand and pretending to be OpenAI.

flow: typed AI functions that can also be your server

Google defines a flow as strongly typed, observable functions. My read: wrap AI logic into a function whose input and output both have types.

Types are written once in Dart with schemantic:

@Schema()
abstract class $RecipeRequest {
  String get dish;
  int get servings;
}

The server uses it to constrain model output, and Flutter uses the same type to parse the result. The hand-written jsonDecode plus as Map layer in between can be deleted wholesale:

final recipeFlow = ai.defineFlow(
  name: 'recipeFlow',
  inputSchema: RecipeRequest.$schema,
  outputSchema: Recipe.$schema,
  fn: (RecipeRequest input, _) async {
    final res = await ai.generate(
      model: deepSeek.model('deepseek-flash'),
      prompt: '给我一份 ${input.servings} 人份的「${input.dish}」的做法。',
      outputSchema: Recipe.$schema,
    );
    return res.output!;   // already a Recipe here
  },
);

A flow can also be mounted as an HTTP endpoint directly, with the client calling it through defineRemoteAction and the same schema shared:

final router = GenkitRouter()..addAction(recipeFlow);
final server = await router.serve(port: 8123);

On the wire it’s {"data": {...}} in, {"result": {...}} out. For Flutter developers that means one type serves as both the interface doc and the parser.

Three placements, you decide where the key lives

This is the most substantive thing in 1.0, I think. Google states outright that AI logic can live in three places:

• Directly in Flutter, good for prototypes and bring-your-own-key scenarios
• On a Dart server, keeping sensitive prompts on the backend, with Flutter calling through defineRemoteAction
• AI logic stays in Flutter, model requests go through a lightweight Genkit backend that protects the key and handles auth

The line from the announcement is worth copying down: never embed private API keys in a published client app. We used to embed keys in clients because reality forced us to. Now there’s a legitimate way out.

Tools, interrupts, middleware

Tools let the model call your Dart functions. For actions that genuinely need a human nod, a tool can return .interrupt(...), suspending the generation loop until the client confirms:

fn: (input, ctx) async {
  if (ctx.resumed == null) {
    return .interrupt({'hotel': input.hotelName, 'total': input.totalPrice});
  }
  return .response(confirmation.id);
},

The approval lives inside the tool, so the model can’t route around it. Google’s words: Putting the approval check inside the tool guarantees that the model can't bypass it. That is far more reliable than prompt engineering to keep the model in line.

On middleware, automatic retries, dynamically loading skills from SKILL.md, tool approval allowlists — all one line of use: [...] on generate. To write your own cross-cutting logic, defineGenerateMiddleware leaves the door open.

Prompts and production observability

Dotprompt keeps templates, model config and input/output schemas in .prompt files, auto-loads from the prompts/ directory, and you call it like a function in Dart:

final introPrompt = await ai.prompt('destinationIntro');
final response = await introPrompt({'destination': 'Kyoto'});

Once you’re live, genkit_otel exports traces, token usage and latency per OpenTelemetry’s GenAI semantic conventions, plugging straight into whatever observability backend you already run.

Two still in the experimental zone

Stateful agents and generative UI. The first is defineAgent, folding model, tools, system instructions and session state into one definition, with sessions surviving restarts via a session store. The second is genkit_a2ui: the agent stops emitting only text and starts emitting components like date pickers, forms and confirmation cards, which Flutter renders incrementally into native widgets.

Both import from package:genkit/experimental.dart. Try them early without carrying the stable-release baggage.

What developers actually take away

First, four kinds of glue you no longer write: multi-vendor adaptation, structured output parsing, streaming, and tool calls with retries. All four used to be rewritten for every model you onboarded. Now they’re in the framework, and the code goes from “rewrite it every time” to “it’s there when you plug in”.

Second, two things moved to the right place. The key moved from the client back to the server — that’s the security account. The schema moved from docs into code — that’s the interface contract. Anyone who’s done this once knows what those two save you is months of manual work later.

Third, adoption can be incremental. Start by using it as “a library that can call models”, add flows when you need them, and only then think about agents. Nothing demands you swap your architecture in one go.

I ran all four scenarios on my machine, all hitting a real model (DeepSeek), not paper reasoning:

[flow]   typed output → 番茄炒蛋（2 人份）| 6 steps / 15 min / 1812ms
[tool]   finishReason=interrupted → stop after restart
[client] remote response → 葱油拌面（1人份） | 5 steps | 2686ms
curl  →  {"data":{...}} in, {"result":{...}} out

Two hurdles before you start

Now the down side. 1.0 has an invisible threshold: it requires Dart SDK 3.12 or above. My machine had 3.11.1, so dart pub add genkit quietly installed 0.16.1 for me — no error, no warning. After you upgrade the SDK there’s a second one: the code generator was split into a separate schemantic_builder in 1.0, and if you miss it build_runner prints wrote 0 outputs — again, zero errors.

Two self-check commands, take them:

dart pub deps --style=compact | grep "^- genkit"   # see the version you actually got
ls lib/*.g.dart                                    # check whether codegen really hit disk

What I haven’t verified

Being honest: the Dev UI (genkit start, needs genkit-cli from npm), middleware, how Dotprompt actually behaves at runtime, genkit_otel exports, and the two experimental ones — I didn’t run any of those locally this round. What’s written above is the official documentation’s account.

Worth mentioning: the official example is already in your local cache, at ~/.pub-cache/hosted/pub.dev/genkit-1.0.0/example/http_server_example.dart. Streaming, auth and custom routing are all in there. Read it before you start and you save half a day.

If your Dart project were getting its first piece of AI logic, would you put it in the app or on the server? Comments welcome.

On October 6, Google DeepMind released EmbeddingGemma 2, and they folded that whole chain into one model.

What it is

740M total parameters, split three ways: a text-plus-code trunk at 270M, a vision encoder at 170M, an audio encoder at 300M. Four modalities (text, image, video, audio) project into the same 768-dimensional space, and they can interleave — just mark media positions with placeholders.

The context window is 8,192 tokens, 4x the previous generation. A single input fits up to 5.5 minutes of audio, 29 images or 58 video frames.

The license is Apache 2.0. Per Google, the architecture builds on Gemma 4 and shares lineage with Gemini Embedding. The previous EmbeddingGemma passed 20 million downloads, which is the confidence behind opening up across all modalities in one shot.

Four configurations, one shared vector space

The most interesting part here is the modularity. You load only the encoders you need:

text only       270M
text + image    440M
text + audio    570M
all modalities  740M

The key is that last line: all four configurations share the same vector space. A query encoded with the 270M setup can be compared directly against a document encoded with the full 740M. Which means you don’t have to commit up front — build the index on text alone, and when you want image search one day, add the vision encoder in. The vectors you already computed don’t get recomputed.

Storage drops sixfold

Output is 768 dimensions, but it uses Matryoshka representation learning, so vectors truncate to 512, 256 or 128 dimensions, saving up to 6x on storage.

The cost is in Google’s own table: at 256 dimensions, text and code quality basically holds, and multimodal retrieval sits around 95%; at 128 dimensions text and code retain about 90%, but image, video and audio fall to roughly 75%. Google’s advice is clear — keep 128 dimensions for large indexes and first-pass ranking, don’t run multimodal retrieval on it directly.

Code is where it jumped hardest

Multilingual text barely moved. The real jump is code:

MTEB Multilingual v2   61.36   (previous generation 61.15)
MTEB Code v1           78.68   (previous generation 68.76)

Code went up 9.92 points, about 14%. Google states the uses plainly: local codebase indexing, semantic code search, retrieval for coding agents.

Scores for the other modalities are listed too, official numbers, 768 dimensions:

How small is on-device, really

Google’s measured numbers: on a Pixel 11 Pro, after quantization, text-only weights sit at about 191MB of active memory, all-modality about 567MB. Quantize further and it compresses more — Unsloth is even talking about running it in 0.5GB of memory.

Pairing it with Gemma 4 has a hidden benefit: the two models share the same text tokenizer and audio encoder, so running on-device RAG with both costs less total memory than running each on its own.

Three traps that fail silently

All of these are in the official model card and worth pulling out on their own, because none of them throws an error.

The first is precision. Don’t use float16. The model’s activation range exceeds fp16’s dynamic range, and the result is NaN or quietly degraded vectors, with no exception raised. Use bfloat16, or float32 on hardware without native support.

The second is truncation. Slicing breaks unit length, so after shortening you have to redo L2 normalization. Skip it and nothing errors — the ranking quality just rots slowly while the scores still look respectable.

The third is dimension alignment. Query and document must be the same dimension. A 768-dimensional query can’t be scored against a 128-dimensional corpus.

Also, text input needs a task prefix: SearchQuery plus Document for retrieval, CodeRetrieval for code retrieval, and the respective symmetric prefixes for classification and clustering. You can skip the prefix and it still runs, quality just drops. Media inputs take no prefix.

The ecosystem showed up fast

Tooling basically ready on launch day: sentence-transformers (from 6.1.0), transformers, vLLM, SGLang, MLX, Ollama, LM Studio, Qdrant, LiteRT.

The GGUF build for llama.cpp is in the ggml-org repo, fine-tuning docs are Unsloth’s, and on the browser side there’s transformers.js plus a WebGPU demo.

On shipping forms, Google AI Edge Gallery added two demos. One is Instant Media Search: search your local photo library as you type — typing the German “Katze schläft auf Tastatur” lands straight on the shot of the cat asleep on the keyboard.

The other is Video Moments Finder, which takes a description like “a kid laughing” and jumps straight to that moment in the video, no audio transcription and no subtitle generation.

On Mac they also shipped AI Edge Foresight, a local meeting assistant that uses EmbeddingGemma 2 for file retrieval and Gemma 4 for understanding, tapping system audio and the microphone, working offline.

Further out, ML Kit will offer this capability in the coming weeks with NPU acceleration; MediaPipe’s UniversalEmbedder and SemanticRetriever already support it, and there’s a bonus use — with no fine-tuning at all, compare user input directly against category labels and you get millisecond-level intent routing.

One judgment

What’s actually valuable in this news isn’t another leaderboard number. It’s that a 740M open model replaces a three-stage pipeline. What you save isn’t just memory, it’s the intermediates and all that serialized latency.

For people working on on-device RAG, local file search or codebase indexing, this is the thing worth spending an afternoon on this year. One caveat: the main HF repo has no GGUF or ONNX — for on-device deployment you have to grab them from the ggml-org and litert-community repos.

Which scenario would you move back to local? Comments are open.

References:

• Official launch post https://blog.google/innovation-and-ai/technology/developers-tools/embeddinggemma-2
• Model card https://huggingface.co/google/embeddinggemma-2
• Developer guide https://developers.googleblog.com/en/embeddinggemma-2-the-developer-guide/
• AI Edge shipping post https://developers.googleblog.com/google-ai-edge-with-embeddinggemma-2/

The next morning the PR was closed. No technical review.

The reason given: they do not accept low-effort AI-generated contributions. To feel the weight of that sentence, you have to read the technical part first.

What he found: small-binary mode never touches Kotlin code

The subject is smallBinary, an experimental option in Kotlin/Native since 2.2.20. It switches the IR pipeline’s optimization level to Oz and stops forcing inlining of runtime hot paths. Sounds like everything that should be cut gets cut.

But for the final code generation step, Kotlin/Native still runs clang -cc1 ... -O3. That value lives in the toolchain’s konan.properties under the key clangOptFlags.ios_arm64.

And LLVM’s MachineOutliner, the pass that removes duplicate machine code, only applies by default to functions tagged with the minsize attribute on AArch64.

Stack the two: the IR layer is in size mode, the machine code layer is still in performance mode, and functions Kotlin generates carry no minsize. The result is that MachineOutliner sweeps through and touches zero Kotlin functions.

He put two sets of numbers in the issue. Of the 33,881 function definitions in the final bitcode, only 55 carry minsize, all of them runtime cold paths. In their app, the object holding 33 MB of Kotlin code has 11 outline helpers; the precompiled Skia object next to it has 4,459.

I ran it myself

You should not take someone else’s numbers on something like this. I had Kotlin/Native 2.4.0 locally, wrote a small chunk of interface-dispatch-heavy code, 300 functions, and compiled the same source file three times, all with -opt and -Xbinary=smallBinary=true.

The mechanism reproduced completely. By default there are only 9 outline helpers, which shows the pass really is skipping Kotlin code. Add one konan.properties override and the helper count goes into the thousands, with size dropping in step. Absolute size only fell 5% to 9%, because my sample project is tiny while his Kotlin object is tens of MB.

My local konan.properties does indeed contain clangOptFlags.macos_arm64 = -O3 and llvmInlineThreshold = 100, so both premises of his argument check out.

The size saved, and the other side of the ledger

His app is a Compose Multiplatform iOS build, unsigned archive at 114.7 MiB (same commit, Kotlin 2.4.10, Xcode 26.5).

smallBinary + latin1Strings         114.7 → 101.7 MiB
plus forcing the outliner on         → 86.9 MiB
plus inline threshold 5              → 81.4 MiB

That 81.4 MiB in step three deserves a closer look: he built 81.3 MiB using a patched compiler that tags every Kotlin function with minsize, and the two differ by 0.1 MiB. In other words most of that gain comes from less inlining, and you can get it without touching the compiler.

He also spelled out the costs. A 23-second scripted scroll on iPhone 13 pushed CPU from 8.48s to 8.94s, up 5.4%, and janky frames from 18 to 27; on iPhone X CPU rose 6.5%. Startup time unchanged.

The counterintuitive one is download size. The whole executable, gzipped, went from 20.42 MB to 20.05 MB. It moved 0.37 MB. The unsigned bundle lost 14.8 MiB and compressed almost not at all, because the duplication being removed is exactly what a compression algorithm likes to eat.

Also, framework code generation time went from 2 minutes to 6. And the top of a crash stack gains an OUTLINED_FUNCTION_n frame, though lldb still walks back to the real caller — he tested Kotlin exceptions and SIGSEGVs on both builds and the logical stack matched.

His own situation was a finance app, and his conclusion was that he would rather have smooth scrolling than save those 15 MiB. The two binary options were in review; the outliner one waits until his heaviest page is device-tested.

Then JetBrains closed his PR

Technical part done. Now the rejection.

We don’t accept low-effort AI-generated contributions that shift the burden of understanding, verifying, and fixing the proposed changes onto maintainers.

In other words: they do not accept low-effort AI-generated contributions that move the burden of understanding, verifying and fixing onto maintainers. There was a follow-up line too: using AI tools is fine, but contributors have to put in their own engineering effort and take responsibility for the quality and correctness of what they submit.

His own retrospective in the post is candid. He admits he used AI tools to prepare the PR, opened it before the team had looked at the issue, then rewrote it an hour later. From his side it was one rushed move; from the maintainer’s side it was the kind of drive-by submission they get buried in every day.

He does draw one boundary: the PR being closed does not overturn the technical conclusion. Those numbers reproduce with one flag and a stock compiler, and the public KotlinConf app gives anyone an independent way to check. Worth mentioning: that public app’s Kotlin object went from 14.88 MB to 8.33 MB.

The issue is now marked Declined, created October 7, updated the next day.

What people writing Kotlin/Native can do now

If your project ships an iOS framework, do these three things in order.

First, turn on the smallBinary and latin1Strings binary options. They work with a stock compiler, both are experimental, and remember to retest on every Kotlin upgrade. That step got him 13 MiB.

To push further you go down the konan.properties override path: force the outliner on, push the inline threshold down. It does pay off, but it is undocumented usage. What is officially documented is -Xllvm-module-passes and -Xllvm-lto-passes, and KT-69212 says you cannot currently disable a specific pass outright.

That kind of override has a hidden risk: if a release renames the property, it silently stops working. So put a size check in CI.

Finally, always device-test performance before shipping. This optimization trades CPU for size, and his measured scroll cost starts at 5% and up.

A few items he also tested that did not pan out:

• A vendor’s Swift package pulled in a 4.9 MiB OpenSSL framework that was never used; check with otool -L plus nm
• The ICU data Skiko ships is 6.3 MB; he trimmed a build and long-pressing the input field crashed outright, so he stopped there
• material-icons-extended is declared in several modules but not one byte of it reached the bundle; removing it only saves build time
• @Preview functions are stripped in release anyway
• LLVM’s famous global function merging pass actually made the Kotlin object 0.44 MB larger under his configuration

Last

What is interesting here is not those 15 MiB. A reproducible performance problem, a public reproduction project, a set of on-device measurements — with all of that assembled, what stopped it was not a technical dispute. It was the trust cost inside the contribution process.

For people who write code it is a reminder: let maintainers evaluate the issue first, do not rush to open the PR. For maintainers it is a different question: AI has pushed the cost of producing a PR to nearly zero while review cost has not dropped at all. More projects are going to draw this line.

Would you take a 5% scroll cost to save 15 MiB? Tell me in the comments.

References:

• Mo Yaver’s detailed write-up https://medium.com/@mhammadjaber00/kotlin-natives-smallbinary-never-runs-llvm-s-outliner-on-kotlin-code-f457d0fbb6d2
• The issue he filed, KT-90068 https://youtrack.jetbrains.com/issue/KT-90068
• The closed PR #8802 https://github.com/JetBrains/kotlin/pull/8802
• Kotlin 2.2.20 release notes (smallBinary and latin1Strings) https://kotlinlang.org/docs/whatsnew2220.html
• Kotlin/Native binary options docs https://kotlinlang.org/docs/native-binary-options.html
• Custom LLVM optimization passes https://kotlinlang.org/docs/native-llvm-passes.html

Three paths, three bills

Start with the Google Play path. For a team that already has a Play developer account, this bill is close to zero. The app is already inside the verification flow, packages using Play App Signing get their package names claimed automatically, and all you have to do is confirm your status on the developer verification page. The new cost is time, and the review cycle is unchanged.

Now the sideload path. When users download your APK in a browser and install it directly, after September 30, 2026 they will have to clear an identity check in four countries: the package name has to be registered, and the package has to be signed with your private key.

The team left an exit. Development installs through the Android Debug Bridge are unaffected, the advanced flow lets users grant a one-time pass, and a free limited distribution account covers 20 devices. The catch: once the advanced flow is off, updates to unregistered apps fail. Those builds you hand to QA have to fit inside those 20 devices.

Then the enterprise internal distribution path. Managed devices installing from an organization store get an exemption, as long as the device is genuinely managed. If the same app also ends up on employees’ own unmanaged phones, register it anyway. What this means for cross-platform teams is that internal test builds and demo builds still count as package names and identities — you cannot skate past it with “it’s only internal.”

Why the math is messier for cross-platform teams

The first reason is the number of package names. A KMP or Flutter project often produces several artifacts out of one repo: the main build, assorted flavors, test builds, each with its own package name. Verification works off package name and signing key, so your inventory has to cover every artifact and every key, not just the one that ships to the store.

The second is where the keys come from. On one team you can easily have a keystore generated on a CI machine, a keystore someone keeps locally, and the one Play App Signing hosts. The more names there are, the easier it gets to ship a build that was not signed with the key you thought.

The third is what you submit. In the end this verification asks for two things: a package name, and an APK signed with your private key. The first gets checked for duplicates, the second has to prove itself.

While we are on boundaries: this verification only governs package names on Android-certified devices. If the same project also ships to HarmonyOS or iOS, those signing materials are a separate system and outside these rules. But archiving your keys and being able to run your own check is something both sides should be doing.

First: archive the keys, and be able to prove it

Registration requires proving the package name is yours, and the credential they accept is an APK signed with your private key. In other words, the signing key graduates from something sitting in a build cache into an identity document. The official FAQ has a line specifically about this: lose the key and you cannot register the package name, so use a key management solution.

Archiving is not enough by itself. You have to be able to prove it at any time. I wrote a thirty-line script that, in one run, prints an APK’s package name and certificate fingerprint and compares them against the archived fingerprint list. Same code, same package name, signed with a different key, and the output forks:

Identical package name, completely different fingerprint. That is what using the wrong key looks like. This happens on teams more often than you would guess, especially after a CI machine gets replaced or someone regenerates a keystore.

Three archiving rules. Keep the keystore file, the alias, and the fingerprint list together, in a password manager or the team vault; keep the fingerprint list as plain text, one SHA-256 per line, so machines can diff it; wire that step into the release process as a gate, and block the release when it does not match. The official docs also mention that one package name can register multiple signing keys, which is what you want when rotating keys.

Second: check whether the package name is taken before you ship

Package names are claimed first come, first served. You check for collisions when you pick the name, not on launch day.

Google opened the Android Developer ID Status API specifically for this, and it returns three states: registered, unregistered, and registered but tied to a different certificate fingerprint. That last one is the painful case, because it means someone else holds the package name.

When you do collide, the official path is to apply for registration, but it needs extra review, and the docs say outright that the package name may be in use by other developers at the same time. Anyone who has done Android knows what two apps sharing a package name means.

The API has a quota, 1,000 calls per project per day, and it has to be attached to a Google Cloud project: create the project, enable the API, set up auth. I do not have that setup on this machine, so this section follows the docs only — I never actually issued a request. For day-to-day status checks, the package name lists in Play Console and the Android Developer Console show it directly, as registered, unregistered, or draft.

Third: accounts and paperwork, start what you can start

For an individual developer, this step is just identity verification. Organizations need two more things: a D-U-N-S number, and a company site verified through Search Console.

D-U-N-S is free, you apply on the Dun & Bradstreet site, and the process takes up to 28 days. It is the only item on the whole list whose waiting time you cannot compress, and the official help docs specifically warn about third-party services charging steep fees for it.

On cost: a full distribution account is a one-time $25, the same ballpark as Play’s registration fee; limited distribution is free. Money and forms are not the real problem. The real cost is those 28 days up front.

Three traps that will stop you

The first is losing the key. This is not an inconvenience, it is an inability to register the package name — meaning you never get that name back.

The second is someone else registering the package name first. After you apply you may end up sharing it, which is a landmine with an unknown detonation date.

The third hides on the limited distribution path. Once the advanced flow is off, updates to unregistered apps fail. The official FAQ is explicit: unregistered apps can only be installed and updated through the advanced flow or the Android Debug Bridge. In the 20-device scenario, remember not to flip that switch off.

What to do now, what can wait

Already in effect: four countries, seven participating stores (Google Play, Samsung Galaxy Store, Xiaomi GetApps among them), covering certified devices on Android 7 and up, with the first phase limited to phones and tablets as form factors.

Three things you can do right now: archive your keys and hook up the self-check, check whether your package names are taken, and get the D-U-N-S and account paperwork moving.

What can wait: stores not on the list, and direct sideloading by users, are unregulated until this round expands. The official timeline is a global rollout in 2027 and beyond, and they recommend developers complete verification before that; press coverage puts the early pace at the US and UK first. Apps already on Play have to register for all form factors — enforcement just starts with phones and tablets.

One phrase worth remembering: the official FAQ says “not applicable for now,” not “never.” The gap between those two sentences is that 2027 slot.

Last thing

Add up the three bills and the most expensive item is not the $25. It is the lead time on identity paperwork, and the fact that a signing key has no substitute. Ten minutes to fill in a form, 28 days for D-U-N-S, and if the key is gone there is no second one. So for a cross-platform team this should not be something you remember the week before launch. It belongs as a step in the release process.

Which path does your project take? And can you find that signing key right now? Talk in the comments.

References:

• Android developer verification official guide https://developer.android.com/developer-verification/guides
• Official FAQ https://developer.android.com/developer-verification/guides/faq
• Check package name registration status (Developer ID Status API) https://developer.android.com/developer-verification/guides/check-registration-status
• Register a package name with the Console API https://developer.android.com/developer-verification/guides/developer-console-api

The Chinese tech scene hasn’t talked about this much. The English community has been arguing for a while. The Hacker News thread from October 1 pulled 338 points and 141 comments. F-Droid, on the free software side, put out an open letter together with the Electronic Frontier Foundation, and the title is one line: opposing Android developer verification.

So this is worth taking apart. What it changed, and who actually gets hurt.

In Google’s own words: apps have to be registered by verified developers

Google puts it plainly. The official guide opens with: Android requires all apps to be registered by verified developers before users can install them on certified Android devices.

Let’s draw the boundaries first:

• Takes effect September 30, starting in Brazil, Indonesia, Singapore and Thailand
• Covers seven stores: Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo App Store, Xiaomi GetApps
• Applies to certified devices on Android 7 and up, with the check delivered through Google Play services
• This round only covers phones and tablets
• Global rollout in 2027, with verification extended to all third-party Android stores

One detail matters more than it looks: this round only covers those seven stores. The official FAQ is explicit — if you distribute through other channels, or users just sideload, these new requirements don’t touch you for now.

In other words, the sideloading road isn’t blocked. There’s just an ID check at the entrance.

Google’s own analogy is refreshingly candid. They say it’s like checking ID at the airport, which is a different thing from security screening. What’s being confirmed is who the developer is. The app’s content isn’t reviewed, and neither is where it came from.

Three roads, pick one

The official docs give three paths. The difference sits in the identity verification column.

Full distribution means handing over identity: a developer console account at $25 one time, a D-U-N-S number if you register as an organization, up to 28 days for review, plus a website verified with Google Search Console.

Limited distribution is the door left open for people who don’t want to hand over a government ID. Free, no cap on app count, but limited to 20 devices and users have to accept your invite. Students, hobbyists, and people writing apps for themselves take this road, it’s the least hassle.

The third road is for users: apps from unregistered developers still install, but the user has to go through advanced flow setup once. Google says the point of those safeguards is to give users time to break off coercion.

One official line to note: once advanced flow is turned off, updates to unregistered apps fail. That road works as a destination, not as a daily driver.

I built an APK by hand. What gets verified is really just two things

Concepts go further if you run them yourself. My local Android SDK had aapt2, d8, zipalign, apksigner and keytool, enough to hand-assemble an APK without Android Studio.

The flow: write an AndroidManifest.xml with just the package name com.example.handmade, javac one class, d8 it into classes.dex, aapt2 link to produce the APK, then generate an RSA key pair on the spot with keytool and sign with apksigner.

Then pull the identity out and look at it:

Signer #1 certificate DN: CN=Handmade Identity Demo, O=none, C=CN
Signer #1 certificate SHA-256 digest:
0a220aaa9b719f34f97e88cb46a95de020fba812fee540251cc2cae7a188a269
Verified using v2 scheme (APK Signature Scheme v2): true

package: name='com.example.handmade' versionCode='1' versionName='1.0'

An 8,619-byte APK, and the identity is those two lines: the package name com.example.handmade, plus the certificate fingerprint, that SHA-256 starting with 0a22. That pair is what Google wants you to register. Officially: provide an APK signed with your private key, which links that APK to your developer account.

A control test makes it more interesting.

I verified the unsigned APK and it flatly reported DOES NOT VERIFY, missing META-INF/MANIFEST.MF. Then I signed the same APK with a second key. Not a character of code changed, the package name didn’t change, and the fingerprint went from starting 0a22 to starting ee56.

So what gets verified is the person, not the code. Which explains why the official FAQ has a line specifically saying that if you lose your signing key you can’t register the package name. That keystore file isn’t a build cache, it’s an ID card. Archive it like private data.

This isn’t App Store-ification, it’s macOS notarization

Most people’s first reaction is that Google is going Apple. That read is only half right.

Where it’s similar is real: distribution hangs off an account. On Apple’s side every install path hangs off the Apple Developer Program, $99 a year, and organizations also need a D-U-N-S. On macOS it’s more direct — Gatekeeper checks a notarization ticket online on first run. And the third-party marketplaces Apple opened up in the EU also require confirming at install time that the source is an authorized channel.

Where it’s not similar is the point, and there are two places.

First, Google doesn’t review content. The official help doc says outright that app content and functionality information is not collected. Apple’s setup is review plus cut: content rules up and down, and under the newest EU terms it’s 26% for in-app purchase, 20% for alternative payments, 15% for link-outs, and another 5% for third-party marketplaces or web distribution.

Second, Google left a no-identity exit: 20-device limited distribution, advanced flow, and adb development installs that are completely untouched. Apple has no counterpart.

There’s also a fun contrast in direction. In the EU, Apple is being pushed open by the Digital Markets Act. Google here is voluntarily tightening. Nobody is copying anybody — two curves pointing opposite ways, meeting in the middle.

The line actually worth watching is the one about verification extending to all third-party Android stores. At that point Google isn’t just the doorman of its own yard, it’s the identity issuer for other people’s stores.

Who gets hurt

Ordinary users won’t. The experience genuinely doesn’t change, which is the hardest thing for opponents to argue.

Three other groups will. Non-profit repos like F-Droid are first in line, and their open letter is blunt:

Installing or launching any app on a certified device will phone home to Google to verify that the developer and app have been approved.

They host thousands of apps, verification binds to package name, which means every volunteer has to hand their identity to Google. Their conclusion is to advise developers not to register.

The second group is people who can’t complete verification. The official FAQ admits it: developers in sanctioned regions cannot complete verification. Offline environments, no documents to produce, or a region where the flow simply doesn’t work — those people are shut out of distribution.

The third group is any future distributor that wants to compete with Play. They can’t even go live without going through Google’s registration process first.

For developers in China, three practical moves

First, if your app is Play-only and you use Play App Signing, you’re already inside this flow. Google claims it automatically, no extra action needed. To check your status, just look at the developer verification page in Play Console.

Second, if you have overseas users and distribute outside Play, what you should do now is archive your signing keys properly, apply for the D-U-N-S early, and treat 2027 as the real deadline instead of staring at this September.

Third, for apps you only write for yourself or a small circle, adb is officially kept and advanced flow works too — but remember that updates to unregistered apps depend on it, so don’t turn it off.

One API worth knowing about: Google opened the Android Developer ID Status API, which tells you whether a package name is registered, 1,000 calls a day. It has to be attached to a Google Cloud project to call, which I don’t have here, so I’m only noting it as a lead. For people who distribute, it means you can ask who owns a package name before installing.

Last

This isn’t a security check. It’s the gatekeeping right of distribution moving out of the operating system and into Google’s account system. Nearly invisible to ordinary users, a structural blow to non-mainstream distribution.

The 2027 global rollout is the watershed. These four countries today are just a very cheap pilot that can be adjusted at any time.

If you’ve got an app that only distributes inside China, will you register, or wait for 2027? Talk it out in the comments.

References:

• Android developer verification official guide https://developer.android.com/developer-verification/guides
• Official FAQ https://developer.android.com/developer-verification/guides/faq
• F-Droid open letter https://f-droid.org/en/2026/02/24/open-letter-opposing-developer-verification.html
• Hacker News discussion https://news.ycombinator.com/item?id=49917761

On October 6, JetBrains’ Amper blog published its final post, titled Amper Is Now the Kotlin Toolchain. The name carries a line underneath, Moving to the Kotlin Blog, and it means what it says: that blog stops updating as of that day and merges into the Kotlin blog.

What got renamed is not the blog. It is Amper itself. It is now called Kotlin Toolchain, and it is the official Kotlin toolchain.

News like this is easy to scroll past as another rename to dress up the quarter. But I went through the code and docs, and this one is different: they are scrubbing the word Amper out of the codebase, layer by layer.

How thoroughly? The 0.13 release notes make it clear. Two of the breaking changes: the environment variable AMPER_BUILD_DIR becomes KOTLIN_TOOLCHAIN_BUILD_DIR, and the module layout entry named amper becomes default.

When a name gets scrubbed all the way from config files down to environment variables, it is not a marketing move.

Three moves in three months

I put the timeline in order:

The repo moved in May, the promotion was announced in June, and the name was scrubbed out of the code in October. You can see the first two in the news. The third only shows up if you open the 0.13 release notes.

One line from the June post stuck with me, explaining why the name changed:

As the project evolved, it became clear that the ecosystem doesn't just need
another build tool – it needs a unified entry point into all of Kotlin.

Translation: as the project moved forward, one thing became clear — this ecosystem does not need another build tool, it needs a single entry point into all of Kotlin.

I installed it on this machine

Rather than trust what the docs say, look at how it actually runs. Installation uses the official script. I did not pipe it straight into a shell; I pulled it down and read it first. It does a SHA256 check, and the thing is reasonably well behaved.

curl -fsSL -o /tmp/kt-install.sh https://kotl.in/install.sh

By default it appends a PATH line to your shell config. I skipped that with its own switch so it would not touch my zshrc:

KOTLIN_CLI_NO_MODIFY_PATH=1 sh /tmp/kt-install.sh

After install:

Kotlin Toolchain version 0.13.0 (abc7a5f, 2026-10-01)
Installed Kotlin CLI to /Users/trevorwang/.local/bin/kotlin

Then create a project. It has a set of non-interactive templates; I picked the JVM command line one:

kotlin init --from-template=jvm-cli --no-git

Generated in 0.34 seconds. I expected a pile of files to read; the entire project config is one line:

product: jvm/app

Three source files: a println in main.kt, an object in World.kt, two tests in the test directory.

Build, run and test, all of it

On first build it pulled down a Temurin JDK 25 itself, and after that everything came up green. Install, create, compile, run and test in one pass looks like this:

The whole thing took 30.8 seconds, and subtracting the JDK download the rest is fast. The test section is red because the template deliberately includes an assertTrue(false) in a function named shouldFail. My guess is it wants you to see what failing output looks like, and to note that the exit code is 1.

Another command I like: kotlin show settings. It prints the effective settings for each module and marks defaults with # default:

compose:
  version: 1.12.1  # default
junit: junit-5  # default

What you wrote yourself and what it defaulted to are instantly distinguishable.

Three lines of YAML, four platforms

A single JVM target is not much to look at, so I created another from the kmp/lib template. The full module.yaml it gave me, plus the build results per platform, look like this:

Platform-specific sources do not use Groovy’s source set naming. It is a directory suffix: src@jvm, src@android, src@ios, each holding its own actual. The shared expect goes in src.

You can also build only selected platforms:

kotlin build -p jvm -p android

11.3 seconds, four green lines, output is kt-kmp-jvm.jar and kt-kmp-jvm.aar.

Here is a detail I did not expect. Poking through its download cache, I found that to compile Android it dropped a platform package into my Android SDK, with a timestamp matching this build:

~/Library/Android/sdk/platforms/android-37.0/            11:35
~/Library/Android/sdk/platforms/06259a9c8a-platform-37.0_r02.zip.flag

Add the Temurin JDK, the JUnit runner for tests, and Kotlin/Native for iOS — it pulled all of it. It is almost excessively friendly to newcomers: one install command, zero configuration, and JVM and Android compile. The cost is waiting on downloads during the first build, and it writes into your SDK directory.

The iOS leg stops at Xcode

Add iOS and see:

kotlin build -p iosArm64
Downloading .../kotlin-native-prebuilt-2.4.20-macos-aarch64.tar.gz
ERROR: Xcode first-launch setup could not be completed.
       Run `sudo xcodebuild -runFirstLaunch` and try again.
ERROR: Task 'xcodeEnvironment' failed: Xcode environment is not ready

It downloads Kotlin/Native 2.4.20 first, then stops at that step. The check is new in 0.13; the release notes describe it as Check and/or provision Xcode components automatically.

The interesting part is here: Kotlin/Native itself compiles fine on this machine. I had built an iOS arm64 framework with it directly before, output in 9.8 seconds. What the toolchain checks is whether Xcode’s components have finished first-launch installation, which sits ahead of the compiler’s own requirements, and that step needs root, so you run the sudo command yourself.

I think this behavior is good. It does not compile halfway and then dump a baffling link error on you. It stops at the prerequisite check and prints the command you need.

Two places the name has not been cleaned out

First, the distribution download URL is still the old one, with amper in it: packages.jetbrains.team/maven/p/amper/amper.

The second is funnier. One entry in the Android fix list says it used to install the Android SDK under a non-canonical name, and that name was Amper-33.

Repo, blog, command line, environment variables, module layout — cleaned all the way through, with corners still left. Details like these are more honest than a press release; they show you how many layers a rename really touches.

On the IDE side, there is a new option

That covers the CLI. The IDE side changed just as visibly.

The plugin is listed in the Marketplace as Kotlin Toolchain, version 262.10968.205. Its first line of self-description:

Provides support for Kotlin Toolchain, JetBrains' build tool for Kotlin and
Java projects.

Translation: provides support for Kotlin Toolchain, JetBrains’ build tool for Kotlin and Java projects.

Three things in the feature list I care about: running and debugging JVM, Kotlin Multiplatform and native tests; managing multi-module projects and version catalogs; and hot reload for Compose Desktop and Compose Multiplatform. There is also a note at the top of the page saying some features require an Ultimate subscription.

The really interesting part is the new project dialog. The Build system field is no longer just Gradle; there are two side by side, and the one on the right is Kotlin Toolchain.

It writes one line for each. Verbatim:

Gradle — Flexible and backed by a mature plugin ecosystem
Kotlin Toolchain — Easy to use, declarative, and AI-friendly

Translation: Gradle is flexible and backed by a mature plugin ecosystem; Kotlin Toolchain is easy to use, declarative and AI-friendly.

AI-friendly is their own word. An IDE company putting “AI-friendly” in the default copy of its new project dialog is not a surprise this year, but the placement says a lot.

The platform picker follows the same idea as the CLI templates: five checkboxes for Android, iOS, Desktop, Web and Server, and for iOS and Web you can choose whether the UI is shared with the other targets. Check Android plus iOS and the structure comes out like this:

A project.yaml at the root lists the modules: androidApp, desktopApp, iosApp, shared, webApp, core, server — seven. Each module has its own module.yaml, the same three-line thing from the CLI earlier. Versions still live in libs.versions.toml; it kept that Gradle habit, and the wrapper scripts are called kotlin and kotlin.bat.

Run configurations work as is: pick iPhone 17 | iOS 27.0 in the device dropdown and iosApp runs.

So should you switch

The official FAQ has a passage that answers why they did not just improve Gradle. Verbatim:

With the Kotlin Toolchain, we want to show you our design and get your feedback,
as it will help us to decide which direction to take the design. At the same time,
we are also working with the Gradle team to improve Gradle support in our IDEs
and Gradle itself.

Translation: we want to put the design in front of you and let feedback decide which direction it takes. At the same time, we are working with the Gradle team to improve Gradle support in our IDEs and Gradle itself.

Politely worded, and the meaning is clear: this is not replacing Gradle, it is a side-by-side showing.

Migration is interesting too. Maven projects get a convert command, kotlin tool convert-project, which handles part of it automatically. Gradle projects have no tool, and the official explanation is that Gradle scripts are arbitrary code, so no deterministic conversion rules can be written.

So what do you do? One line in the FAQ stopped me: this is the kind of thing an AI agent is good at, given a set of skills. I went and looked. The skills sit under the Kotlin org, called kotlin-agent-skills, 1,071 stars, ten skill files, two of them specifically about migrating from Gradle to Kotlin Toolchain.

The rules inside are strict: every third-party Gradle plugin has exactly three paths — drop it, replace it with a native equivalent, or rewrite it yourself. Keeping it is not an option. And the convention plugins you wrote in buildSrc do not count as plugins, they count as configuration, and they have to become module templates.

That one is worth writing down. Treat the build script as code and an AI can do the mechanical translation. Treat it as configuration and the implicit conventions become the most expensive part of the migration.

Wrapping up

Summing up this week’s move: the name Amper retires, what it leaves behind becomes the official Kotlin toolchain, and the front door is one kotlin command plus one YAML file.

New projects are worth trying — three lines of config compiling four platforms is genuinely pleasant. Leave old projects alone for now. It is still Alpha, and the team itself says not all migration scenarios are covered.

Repo and docs:

github.com/JetBrains/kotlin-toolchain
kotlin-toolchain.org

One question to close with: if you had to move your current KMP project off Gradle onto this today, which step do you think would stop you first?

On October 5 JetBrains published a short announcement. The title is blunt: IDE support for the Swift language is ending in the KMP plugin. The effective versions are specific: IntelliJ IDEA 2026.3 and Android Studio Rabbit 2 | 2026.2.2.

The list of removed features is specific too. Copying it:

This includes editing, syntax highlighting, and navigation within Swift
files and between Swift and Kotlin.

In other words: editing, syntax highlighting, and navigation inside Swift files, and between Swift and Kotlin.

Reading those lines, a lot of people’s first reaction is that KMP on iOS is finished. Hold on. The second paragraph of the same announcement draws the boundary.

Which layer got removed

The second paragraph reads:

Running iOS applications and debugging Kotlin code on iOS will remain fully
supported. Kotlin/Native functionality, such as Swift Export and importing
Swift packages into Kotlin projects, is not affected.

In other words: running iOS apps and debugging Kotlin code on iOS stay fully supported. Kotlin/Native features like Swift Export and importing Swift packages into Kotlin projects are unaffected.

So what got taken away is the layer in the IDE that reads and edits Swift. The compiler, the Native toolchain, the path into Xcode are all still there.

I verified that second half on this machine. I already had the prebuilt Kotlin/Native 2.4.0 and Xcode 26.2, so I used them to compile a small piece of code into an iOS framework:

kotlinc-native -target ios_arm64 -produce framework -o out/shared src/shared.kt

Nine point eight seconds. The output is a Mach-O 64-bit arm64 dynamic library plus a header file for Xcode. Not one step in that chain regressed. Pulling the Swift features did not touch it.

So what actually carries iOS

Take the chain apart and the order is:

1. Kotlin/Native compiles the shared code into a framework Apple can use — that is the nine point eight seconds above.
2. Xcode links that framework into the iOS app. embedAndSignAppleFrameworkForXcode in Gradle is exactly this job.
3. The Swift shell calls Kotlin. Today that mostly goes through Objective-C header interop, and the team is separately pushing Swift Export, still in Alpha, aimed at letting Kotlin export directly as a Swift module and dropping the header layer.
4. Reading and editing Swift in the IDE was only convenience during development. Remove it and the three layers above do not move.

Get these four straight and the weight of the announcement becomes clear.

Why they pulled it

The official reason is usage. Their telemetry and user research show that iOS developers on KMP projects mostly write Swift in Xcode, while the people working inside the KMP plugin increasingly use Kotlin and Compose Multiplatform.

There is also historical baggage: this Swift tooling was originally built for AppCode, and AppCode was discontinued long ago. Then it moved to Fleet, then into the KMP plugin. Keeping its core architecture in step with the continuous changes in Swift, Xcode and the IntelliJ platform is a real investment. They weighed it and decided not to, and they state plainly that they do not currently plan to replace it with something else.

That trade-off is actually on the same line as KMP’s moves these past months: they are spending effort making the Kotlin side better, not doing Xcode’s job for it.

The community side is ahead of the secondhand reports

On the same day there was another item on the trending list, pointing the opposite direction. The iOS version of the open-source OSM editor StreetComplete entered TestFlight — the first testable build after years of porting work.

That port dates from a tracking issue opened in December 2023, still open today, 51 comments accumulated. The maintainer says a full port is roughly one person-year of work, that the first half of 2024 was pushed full-time on Prototype Fund money, and that by September of that year about half was done.

One claim in the secondhand reports has already expired. It says the Compose Multiplatform MapLibre library does not exist yet and is the blocker for the port. I went and read StreetComplete’s build file. It currently says:

implementation("org.maplibre.compose:maplibre-compose:0.19.0")

That library has shipped on Maven Central from 0.11.0 all the way to 0.19.0. That gap is closed.

The costs have to be stated too. The prototype fund ran out; the maintainer writes in the issue that follow-on funding does not look good — OpenStreetMap has no money, NLNet’s program is contracting, and the crowdfunding sponsors have not increased. Known issues are still open: the map does not work on iOS 15.x, forms can only be dismissed with a gesture, and there are still plenty of bugs.

I counted the repo

While I was there I counted the repo by source set. More convincing than reading news:

• commonMain: 1,281 Kotlin files, 3.6MB
• commonTest: 287 files, 1.3MB
• androidMain: 34 files, 43KB
• iosMain: 33 files, 42KB

So each platform gets a shell of a bit over forty KB and the same app runs on iOS and Android. Among the 33 files on the iOS side, the biggest is IosModule.kt at six thousand bytes, doing dependency injection wiring; the rest are platform-specific pieces: networking, sync, upload, periodic cleanup.

See that ratio clearly and the blast radius of the announcement is clear too: the removed features act on that forty-two KB shell, and have nothing to do with the shared three point six MB.

These two stories are one story

JetBrains’s choice is “I do the Kotlin side well, the Swift side goes to Xcode”. StreetComplete’s approach fits that division exactly: shared logic and UI are all written in Kotlin and Compose, and the Swift side is left as a shell.

So the call is simple. Ask yourself a few things:

• Where do you actually write Swift in this project? If Xcode was open anyway, this announcement barely touches you.
• If you read and edit Swift inside Android Studio, you need to change your workflow from now on, or stay on an older version.
• Do not look at IDE support and toolchain support as the same thing. The first is gone. The second is not.
• A viable technical path does not mean a project reaches the finish line. The StreetComplete story is a reminder about money and people.

How long does the version on your machine still work

The threshold is Android Studio Rabbit 2 | 2026.2.2 and IntelliJ IDEA 2026.3. Mine is 2026.2, so the Swift features you have are still there, they just stop getting updates. If you need them badly, upgrade a little later. If not, let it ride — Swift’s real home has always been Xcode.

In your KMP project, where do you write the Swift on the iOS side? Comments are open.

References:

• https://blog.jetbrains.com/kotlin/2026/10/discontinuing-swift-language-ide-support-in-the-kotlin-multiplatform-plugin/
• https://github.com/streetcomplete/StreetComplete/issues/5421

You ask the agent to add a date picker. It installs a calendar library, writes a wrapper component, adds a stylesheet, and then starts discussing time zones with you.

Which is when you think of that person in the office. Ponytail, oval glasses, been at the company longer than version control. You hand him fifty lines of code, he glances at it, says nothing, and comes back with one line.

What the ponytail project does is stuff him into your agent. 155K stars, MIT license, and the first line of the README reads: he says nothing, he writes one line, it works.

Agents are born adding things

An agent’s default move is addition. Leave it alone and it outfits every request with something new: a new dependency, a new abstraction, new boilerplate. You cannot blame it entirely; that is what the engineering practices in its training data look like.

The problem is it does not care about your repo, and it does not care about your bill. That confirmation dialog above — all you wanted was “are you sure you want to delete this” — and browsers have had a native dialog since 2022, with focus management, Esc to close and a backdrop thrown in free.

That “write less code” camp on the trending lists these past two days is talking about exactly this.

Its entire estate is one 2.5KB rule file

The core of ponytail is not code. It is a 2,492-byte rules file. Inside is a ladder: start at the first rung and climb, stopping wherever one holds:

1. Does this need to be built at all? (YAGNI)
2. Does it already exist in this codebase?
3. Does the standard library already do this?
4. Does a native platform feature cover it?
5. Does an already-installed dependency solve it?
6. Can this be one line?
7. Only then: write the minimum code that works.

In other words: ① does this thing even need to exist? ② is there one already in the repo? ③ can the standard library do it? ④ does a native platform feature cover it? ⑤ can something already installed solve it? ⑥ can it be one line? ⑦ only now do you write “the minimum code that runs.”

There is one more line sitting above the ladder: read the task and the code it touches first, walk the real flow end to end, then start climbing. Reverse the order and it is not laziness, it is using efficiency as an excuse.

I got it running

These rules are spread wide. Claude Code, Codex, Cursor, Windsurf, Copilot and Hermes each get an adapter file. I picked the cleanest route, since it ships its own MCP server:

cd ponytail-mcp && npm install && node index.js   # speaks MCP over stdio

Walking through a real handshake, this is what it handed me:

The three intensity levels (lite / full / ultra) differ by only a few dozen characters in body text. Which means intensity adjusts tone and strictness, not prompt length. The rules are in there at every level, around 5,200 characters.

The README also mentions an easily missed detail: over MCP, the rules are pulled on demand. If you want them active every single turn, you have to go the hook or plugin route. Do not assume MCP means it has taken over. It depends which end you connected.

The numbers it saves, and what it does not save

The figures in the README are real runs. Take a real open source repo as the target, have the same agent do twelve feature tasks with and without it, and compare the git diff it leaves behind: 54% less code, 22% fewer tokens, 20% lower cost, 27% less time, all safety checks passing.

A few concrete examples, same model, same prompt:

• Search box debounce: 116 lines → 10 lines
• CSV sum: 20 lines (with pandas) → 3 lines (csv stdlib)
• Delete confirmation dialog: 1 dependency + 30 lines → 0 dependencies + 8 lines (native dialog)

Then the column I think matters most: the control group. Tell it only “write it as short as possible” and you get 33% less code, but safety checks drop to 95%. Say less without rules and you get 20% less code, while tokens go up 7% and cost up 3%.

So writing less is not worth anything by itself. What is worth something is the other list it writes down at the same time, the places where laziness is not allowed: understanding the problem, input validation at trust boundaries, error handling that prevents data loss, security, accessibility, calibration on real hardware. Plus one more: non-trivial logic needs a runnable check, the kind that fails the moment the logic breaks.

One more thing that is rare: the README walks its own numbers down. The earlier single-round benchmark reported 80% to 94%, and a later note states that against a fairer baseline, that was the ceiling for a single task, not the average. The mean is 54%.

The other path is addition

Also trending next to it these past two days is ECC, with more stars, going in exactly the opposite direction. The repo has 4,212 files, 1,027 SKILL.md files and a hundred thousand characters of README, and claims to offer 293 skills and 68 agents.

It does not teach the agent to write less. It packs skills, instincts (with confidence scores, learned from real sessions), memory, security scanning and a research-first workflow into the harness. The slogan is honest: optimize the context window, persist everything else.

The disagreement between the two camps is not about laziness. It is about where you spend the budget. One spends it producing less code, the other spends it remembering more things. The whole ponytail repo is 1.78MB. ECC is 56MB.

How it lands on my own machine

The agent client I normally use is DeepSeek Harness (dsh), whose slogan is Everything is a Plugin. This is how I mount MCP in it:

- insert:
    - id: memory-memorix
      name: "@deepseek-ai/dsh-mcp-client"
      config:
        serverName: memorix
        transport: stdio
        command: memorix
        args: [serve, --mode, lite]

ponytail’s MCP server speaks the same stdio protocol, so wiring it in means swapping out command and args. Think one thing through before you do: once something like this goes in through a plugin or hook, it enters your context every single turn, and you pay the tokens.

Where I land

Writing it as a checklist you can hold up against your own setup:

• Is it saving “writing” or “rework”? Less code does not mean fewer potholes, and rework rate is not in its metrics.
• Do the rules enter every turn? MCP pulls on demand, plugins and hooks inject per turn. The two have different bills.
• What in your project must not be cut? Write it down. It does far more than saying “don’t be verbose.”
• The addition path is not wrong either, but do the context math first.

Back to that colleague with the ponytail. What earns him respect is not that he writes less. It is that he knows every extra line will need a maintainer someday. Putting rules in front of an agent is the same: the point was never to make it type less, it is to make it know what it must not touch.

What is the most unnecessary thing an agent has shoved into your project lately? Tell me in the comments.

References:

• https://github.com/DietrichGebert/ponytail
• https://github.com/affaan-m/ECC

It is two in the morning, the machine has started swapping, you have hit later on the update prompt three times, and you still will not reboot.

Because you have five agents running: one refactoring, one reviewing a PR it submitted an hour ago, and two digging through other repos. They are all busy. You are just not entirely sure which terminal window is which.

That anxiety opens mvschwarz’s April post, Why I Built OpenRig. His fix is blunt: write the whole agent team into one YAML file, rig up to bring the lot online, and restore it exactly as it was after a reboot.

I installed OpenRig on my own machine and took it apart. The most useful line first: on first run it modifies your Claude Code and Codex config, so do not casually npm i -g it on your main machine.

The layer it manages is called topology

Terms first. Things like Claude Code and Codex CLI are called harnesses, and a harness wraps a model. OpenRig does not replace them, it wraps them.

A harness wraps a model. A rig wraps your harnesses. Define your agent team in YAML, boot it with one command. Claude Code and Codex in the same rig, managed as one system.

The author calls this distributed context management. What people usually mean by context engineering is watching one agent’s window: when to compact, when to hand off to a subagent. He inverts it: keep each agent in its own narrow, focused context and coordinate through formation, instead of cramming everything into one window.

The whole team shares one CULTURE.md. The author calls it the group’s constitution, the equivalent of SOUL.md in OpenClaw that defines one agent’s personality, except scoped to the entire team.

For this CLI specifically, I counted the subcommands in --help: 86. Beyond the guessable up, down, ps, tui, there are queues, a workflow runtime, watchdogs, cost telemetry, snapshot restore, and claiming stray tmux sessions back into formation. This is less a tmux wrapper and more a small job system.

First step in testing: get through the environment gate

OpenRig requires Node 22 or 24, plus tmux. I installed the package into a temp directory instead of globally:

npm i @openrig/cli          # 0.6.4, 110 dependency packages
./node_modules/.bin/rig preflight

The preflight result was blunt:

✓ node_version
✗ tmux: tmux was not found in PATH.
  Why: OpenRig uses tmux to create and control agent sessions.
  Fix: Install tmux (brew install tmux on macOS, apt install tmux on Debian/Ubuntu).
✓ writable_home
✓ port_available

1 check(s) failed.

Three of four passed, blocked on tmux. One trap worth mentioning: this machine runs node 25, and OpenRig only supports 22 and 24 — npm 12 itself warns that node 25 is unsupported. I got it running by leaning on the node@22 already in Homebrew. So do not skip this step before you start; let it tell you what is missing first.

Before installing, see which of your files it will touch

rig setup is the big environment prep step: install tmux, install cmux, install the agent CLIs, configure auth. I did not want it acting for real, so I ran --dry-run first.

It did not hedge. It listed the files it would touch:

[global]  claude-code  ~/.claude.json                pre-trust managed workspace, mark onboarding done
[project] claude-code  .claude/settings.local.json   write statusLine and acceptEdits floor snippet
[project] claude-code  .mcp.json                     write the selected MCP resource snippet
[global]  codex        ~/.codex/config.toml          pre-trust + config snippet
[global]  cmux         ~/.config/cmux/settings.json  switch cmux's socket control into compatibility mode

(The list above is my translation; the original is in English.)

Two things surprised me. First, it states plainly that it bakes no permission policy — the words are OpenRig bakes NO allow/ask/deny permission policy, with native harness permissions as the control plane. Second, when it comes to skipping confirmations, it hands the decision back to you, and your agent asks once before the team actually comes up:

Allow your agents to run OpenRig commands without repeated permission prompts? Yes — recommended / No — keep prompts. No answer leaves settings unchanged too.

Pick No or simply do not answer, and it writes nothing. Another line from the docs worth bookmarking: recording a permission policy is a note of intent, not a gate, and rig up runs without it.

So does --dry-run really not write? I took SHA256 hashes of those files beforehand; after the run they were identical, the skills directory still had 93 entries, and ~/.openrig was never created. It is a genuine dry run.

One team is one YAML

That dry-run list only covers the config layer. The actual team is defined in YAML, and the package ships 19 rig definitions, 16 agent definitions and 6 workflow definitions.

The smallest one looks like this:

version: "0.2"
name: first-project
culture_file: CULTURE.md
pods:
  - id: dev
    label: Project
    members:
      - id: owner
        agent_ref: "local:../../../agents/development/implementer"
        runtime: codex
        model: gpt-6-astra
        cwd: "."
      - id: check
        agent_ref: "local:../../../agents/development/qa"
        runtime: codex
        model: gpt-6-astra
        cwd: "."
    edges:
      - kind: delegates_to
        from: owner
        to: check

Two seats in one pod, owner and check, the second an independent reviewer, joined by a delegates_to edge. That edge is not decoration; it has runtime meaning, it is the communication path between seats. The same definition also comes in a Claude version and a mixed version, first-project-claude and first-project-mixed.

One neat touch: the first time it starts the daemon, it brings up a resident rig called kernel. Three pods. advisor commands through Claude Code; operator holds one terminal seat for the human plus a Codex seat; queue has a worker that classifies input streams into queues.

Between the human seat and the agent seats run two edges, collaborates_with and escalates_to, meaning what the agent cannot do escalates to you.

What is actually in a seat

One level deeper: a seat is an agent definition. The implementer role on the dev side looks like this:

name: implementer
defaults:
  runtime: claude-code
profiles:
  default:
    uses:
      skills: [development-team, test-driven-development, systematic-debugging, verification-before-completion]
      plugins: [shared:openrig-core]
      runtime_resources: [shared:claude-default-settings, shared:claude-default-mcp, shared:codex-default-config, shared:claude-activity-hooks]
startup:
  files:
    - path: guidance/role.md
      delivery_hint: send_text

In plain terms: which runtime this seat uses, which skills it carries, which plugins and resources it mounts, and what role description gets sent in at startup. A seat is not “open a terminal and explain as you go”; it is a reusable, versionable job description. Same for the workflow layer: roles declares the roles, steps run in declared order, and the example just routes one package through the plan, build and prove seats in sequence.

Where it stands now

OpenRig is Apache-2.0. The first release went out April 6; by 0.6.4 on October 2 it had shipped 54 versions, 4.2k stars, 38 contributors, and 4,560 npm downloads last week. The version is still 0.6, with spec versions RigSpec 0.2 and AgentSpec 1.0.

The author compares it with Claude Managed Agents, which Anthropic shipped on April 8 this year: cloud hosted, Claude only, billed per session hour. His side runs locally, mixes Claude and Codex, and spends your own subscription quota. His analogy is Terraform and AWS — one manages resources in the cloud, the other manages local formation.

Terraform doesn’t compete with AWS. OpenRig doesn’t compete with Managed Agents.

Writing my team into one file? I am willing. What actually stops people is not the syntax, it is accepting one thing up front: to manage your agents, it first edits your agent config, and does it globally. Do you take that trade, or do you figure five windows in tmux by hand is fine too?

If you write Kotlin Multiplatform you have probably hit this: the line is red in the IDE, underlined with a cannot find symbol, you hesitate for ages and do not dare commit, then you build and it is green, and it even runs correctly.

We used to blame the IDE acting up, an index that had not been built, just clear the caches. On September 28 JetBrains published a post, and the first line is blunt:

The current compilation approach to Kotlin Multiplatform projects works, but sometimes can lead to unexpected or hard-to-predict behavior.

In plain terms: the current compilation approach works, but sometimes it hands you behavior you cannot predict. Then it lists two examples, both things we have hit and never explained:

The IDE analysis disagrees with the compiler on an overload, type inference, or whether the code should compile at all – with the IDE being stricter than the compiler.

Your commonTest code can unexpectedly call something from a platform source set, breaking your assumptions.

One is the IDE being stricter than the compiler, the other is commonTest quietly reaching into a platform source set. Below I explain the mechanism first, then give my own test results, because in the official example you only get shown half the price of the fix.

Why the disagreement exists

The key is what common code resolves its dependencies against when it compiles.

In a KMP module, commonMain is not compiled into an independent artifact and that is the end of it. When compiling the JVM target, the compiler takes commonMain and jvmMain together and compiles them against the dependency’s platform artifact (a jar on JVM). So a call in commonMain has a chance to implicitly land on a declaration in the dependency’s jvmMain.

The IDE’s code analysis does not do this. It assumes common code can only see the dependency’s common declarations, the part listed in the metadata KLIB. jvmMain declarations are not in there, so the IDE shows red.

Two different understandings of the same line, and neither is wrong, but you are stuck in the middle. The post even gives a nastier version: inconsistent overload selection, where the IDE jumps to the commonMain overload while the runtime prints the platform one.

Then there is type inference divergence, where the common side infers Any and JVM compilation fails outright with Unresolved reference. The reverse happens too: with the same example and the flag on, the common phase fixes the return type of currentEvent() to Event, .name has a basis, and JVM compilation passes. So this feature cuts both ways. It makes code that got lucky fail, and it also fixes code that used to fail.

The difference between those two paths looks like this:

The new scheme is one flag

Kotlin 2.5.0-Beta1 introduced an optional separate compilation mode, so the compiler also uses the strict metadata KLIB resolution when compiling common source sets, lining up with the IDE.

# gradle.properties
kotlin.kmp.separateCompilation=true

It is marked Experimental and off by default. One bonus: it makes incremental compilation of common source sets possible, which was not achievable before.

The official example reads easily. Code the IDE flagged red but the compiler accepted now fails to compile too; just wire up expect/actual explicitly and you are fine.

Test one: it really does stop you

I built a minimal KMP project locally (Kotlin 2.5.0-Beta1, two targets: jvm and js), two modules:

lib/  src/commonMain/Marker.kt      # interface only
      src/jvmMain/Foo.kt            # class Foo, declared only in the platform source set
app/  src/commonMain/Main.kt        # directly new a Foo from lib

app depends on lib, and app’s commonMain news up a class that only exists in lib/jvmMain.

Flag off:

> Task :app:compileKotlinJvm
BUILD SUCCESSFUL in 30s

Flag on, same code:

e: app/src/commonMain/kotlin/Main.kt:3:12 Unresolved reference 'Foo'.
e: app/src/commonMain/kotlin/Main.kt:6:13 Unresolved reference 'Foo'.
BUILD FAILED in 2s

The post was right, and it stops you cold. Not a warning.

Same for commonTest. I put a PlatformOnly class in app’s jvmMain and had commonTest new it: flag off BUILD SUCCESSFUL, flag on gives Unresolved reference 'PlatformOnly'.

Test two: the price of the fix the official example does not show

The official fix is explicit expect/actual. lib’s commonMain declares expect, the platform source set provides actual. I made that change and the JVM side really did pass:

// lib/commonMain
expect class Foo()

// lib/jvmMain
actual class Foo actual constructor()

With the flag on, :app:compileKotlinJvm is BUILD SUCCESSFUL in 1s. That half of the official story is right.

Then I went to compile the JS side of the same module:

e: lib/commonMain/kotlin/Marker.kt:5:1 The 'expect' declaration 'lib.Foo'
   has no 'actual' declaration in module '<commonMain> for JS'.
BUILD FAILED in 2s

expect/actual is a paired contract. Every target needs its own actual. The blog example only ever showed the JVM side. Turn it on in a multiplatform project and you owe one actual per target.

One thing the official post does not mention: the version number is not the gate

The blog says the feature was introduced in Kotlin 2.5.0-Beta1. I took the same bad code and tried it on Kotlin 2.4.20 (current stable):

# without the property
BUILD SUCCESSFUL in 704ms

# with kotlin.kmp.separateCompilation=true
e: app/src/commonMain/kotlin/Main.kt:3:12 Unresolved reference 'Foo'.
BUILD FAILED in 11s

The property still flips behavior on 2.4.20, and I checked that this project really resolves to kotlin-gradle-plugin:2.4.20.

So this flag is not something that came into existence in 2.5, it is just that the team only started talking about it as a feature in 2.5.0-Beta1. Flip it around: do not treat the version number as a gate, and do not treat it worked on 2.4 as a conclusion either. Neither is solid. You have to run it on your own project to know.

A quick reference table

Here is everything above plus the official Known issues section in one table, for when you hit one of these cases:

Should your project turn it on

Combining the above with the official Known issues section, my checklist is this:

• Do the libraries you depend on properly publish metadata KLIB? The new scheme turns that from nice to have into required. A library whose author cut corners will fail the moment you turn it on, and that is not your fault.
• How much does the project rely on common calling platform? The KMP project I have routes platform differences through interfaces and barely uses expect/actual, so before turning it on I need to sweep for these calls, otherwise a pile of Unresolved reference appears all at once.
• Do you use cinterop? The docs call out two known issues here (KT-88178, KT-41509), so projects with native C interop should be careful.
• Modules with only one target are unaffected, the docs say so plainly.
• It is still Experimental and off by default. Treat it as a preview, not an upgrade.

A word on the iOS front

In the same week JetBrains also published a TeamCity design retrospective about turning Kotlin Multiplatform iOS packaging into a guided flow: install a plugin, push, and the IDE pops a Configure CI prompt. Follow it and you go from first push to running tests, signing, shipping to TestFlight, and finally hooking up GitHub to run on every push.

Along the way it generates four files (teamcity.yaml plus Fastfile, Appfile, Gemfile) and leaves them local and uncommitted. The first build runs on a hosted macOS agent, and only after you have seen it pass does it let you commit.

I did not test this part, there is no TeamCity account on this machine. That section comes entirely from the official design retrospective and the official tutorial it points to.

Last

Back to that moment where the IDE shows red and the compiler passes. It was never an IDE bug and never your imagination. Two sets of resolution rules simply were not aligned for a long time. What the team is doing now is pulling the compiler over to the IDE’s side: stricter, more predictable, at the price of code that used to get lucky having to be made explicit first.

What I want to do next is turn it on in the KMP project I have, list every Unresolved reference that pops up, and see how much expect/actual that project actually owes.

Have you turned this flag on in your Kotlin Multiplatform project? How many errors did it report? Tell me in the comments.

References:

• A More Reliable Compilation Scheme for Kotlin Multiplatform Modules: https://blog.jetbrains.com/kotlin/2026/09/a-more-reliable-compilation-scheme-for-kotlin-multiplatform-modules/
• Designing the Kotlin Multiplatform and TeamCity Integration: https://blog.jetbrains.com/teamcity/2026/09/designing-the-kotlin-multiplatform-and-teamcity-integration/
• Official iOS CI/CD tutorial: https://kotlinlang.org/docs/multiplatform/ios-ci-cd-teamcity.html

I have three agents installed in my terminal right now: claude, opencode, gemini. A few days in and I hit a new annoyance. Once there are several sessions, I have no idea who is running, who changed which files, or who spent how much. I end up scrolling through terminal history to figure it out.

JetBrains is clearly thinking about the same thing, and its answer is much bigger than another chat box.

Its answer is called Air

On September 22, JetBrains CEO Kirill Skrygan wrote the post himself, pulling half a year of scattered work into one system called Air.

Three products inside: Air in JetBrains IDEs (directing agents from inside the IDE), Air Teams (turning individual agent activity into team workflow), and Air Governance (org-level visibility and cost control).

The opening line is honest, so I will quote it:

AI can produce code. Organizations still have to produce software. Agentic development is changing how software gets made, but it hasn’t changed what it costs to be wrong.

There is another line I think is the most valuable thing in the whole post:

Code becomes cheaper to generate but more expensive to verify.

Meaning: writing code got cheaper, verifying it got more expensive. So they put their bet on the verification side.

On October 1, Air in IDEs opened its EAP.

What it is: not an AI provider, a hub

One line in the official description matters most:

It is not an AI provider, and it ships with no agents installed.

Meaning: it does not build models, it ships with zero agents preinstalled, what it does is plug your agents in. Three design points, restated: multiple agents working in parallel, each session isolated in a temporary worktree, and you can see the cost of every session. Also, double-tap Ctrl and a new session starts with the current context already attached.

JetBrains plays this very modestly. Their line is that they built their own agent and intend to make it the best, but Air does not require you to use theirs, and that they have no reason to make the ecosystem smaller. They can say that because they hold something else: 26 years of code intelligence.

I installed it

Start with the useful conclusion: you do not need the EAP to try it. The plugin marketplace has two compatibility lines, one for the 2026.3 EAP and one for 2026.2 stable. I took the latter (version 262.8665.481, 33,519 downloads at the time).

I installed it on Android Studio 2026.2 (build 262.9437). The plugin requires platform version 262.8665, so it is compatible. After startup, this line in the log is the first piece of evidence:

Loaded custom plugins: ... Air (262.8665.481), Kotlin Multiplatform (262.9437.115-AS), ...

The lines after it are more interesting. I think they are worth more than the plugin itself:

INFO - AcpRegistryFetcher - Starting ACP registry fetcher
INFO - AcpRegistryFetcher - Fetching signed registry bundle from
       https://resources.jetbrains.com/agentclientprotocol/registry.zip
INFO - AcpRegistryFetcher - Verified signed registry v1.0.0 with 41 agents
INFO - AcpAgentsConfigService - ACP configuration file
       '/Users/trevorwang/.jetbrains/acp.json' not found,
       no local ACP agents will be configured.
INFO - CodexIdeContextIpcTransport - Codex IDE context IPC listening on
       /var/folders/.../codex-ipc/ipc-501.sock
INFO - AirCloudRunAvailabilityServiceImpl - Air cloud runs: not offered
       - no JetBrains Account is signed in

Those six lines say: it pulls a signed agent registry on startup; the registry holds 41 agents; the entry point for local custom agents is ~/.jetbrains/acp.json; it opens a local IPC socket for Codex so the agent can ask the IDE for context; cloud runs need a JetBrains account, and without one they are not offered.

One more thing I did not expect: Agent Client Protocol is already in Android Studio 2026.2’s bundled plugin list. So ACP support does not come only from this new plugin. The IDE itself already ships it.

Who are those 41 agents

That registry is signed and distributed, so I pulled it down and unpacked it myself: inside is registry.json, registry.json.asc, and a public keyring. I verified the signature myself and it passed. Public key fingerprint B46DC71E03FEEB7F89D1F2491F7A8F87B9D8F501.

Out of the 41, here are the ones you will recognize:

• Claude Agent, Codex, Gemini CLI, GitHub Copilot, Cursor
• Devin, Amp, Cline, goose, Junie, Factory Droid, OpenCode
• Kimi CLI, Qwen Code, MiniMax Code, GLM Agent, Mistral Vibe, Qoder CLI

The Chinese vendors are all in there.

How they install says the most about what this registry really is. Four real entries:

Claude Agent 0.85.1   npx @agentclientprotocol/claude-agent-acp@0.85.1  (license: proprietary)
Codex 2.1.1           npx @agentclientprotocol/codex-acp@2.1.1           (Apache-2.0)
Gemini CLI 0.62.0     npx @google/gemini-cli@0.62.0 --acp                (Apache-2.0)
OpenCode 1.18.34      per-platform binaries plus sha256 checksums         (MIT)

So installing an agent in this system is: one npx command, or a binary with a checksum. Note the Claude line, where the wrapper is proprietary. Anyone doing enterprise compliance should look at that detail.

I had a conversation with an ACP agent myself

I could not click through the GUI. This machine has not granted that process screenshot and accessibility permissions, so I cannot move the mouse. So I switched to a harder form of verification: bypass the IDE entirely, run the Claude ACP wrapper from the registry in a terminal, and hand-write JSON-RPC to shake hands with it.

This is the real response, not something I made up:

{"protocolVersion": 1,
 "agentCapabilities": {
   "_meta": {"claudeCode": {"promptQueueing": true}},
   "promptCapabilities": {"image": true, "embeddedContext": true},
   "mcpCapabilities": {"http": true, "sse": true},
   "loadSession": true,
   "sessionCapabilities": {"close": {}, "delete": {}, "fork": {}, "list": {}, "resume": {}}}}

It also pushed a notification on its own saying it was not logged in:

_auth/status_update {'authStatus': {'kind': 'none', 'label': 'Not logged in'}}

After sending session/new, it returned a session ID and four modes: Manual (ask before changing), Accept edits (auto-accept changes), Plan (plan first), and auto.

Then I made a mistake worth writing down too: when sending session/prompt I filled in a fake session ID to save effort, and it answered -32603 Internal error: Session not found. Meaning the protocol requires the real ID returned by session/new, and a wrong one just gets you an internal error. Not friendly to newcomers.

Three conclusions: the protocol side is alive on my machine; the agent reports its own capabilities and login state proactively; authentication did not complete, so I never got a model answer. To run a real conversation you have to finish authorization first, which is the step in the IDE.

Why anyone doing KMP or Android should care

First, Android Studio and IDEA share a codebase. Every log above was printed by Android Studio, and the ACP plugin is even bundled. JetBrains is where KMP comes from, so wherever it goes, your toolchain goes.

Second, it admits one thing:

The era in which the whole software development system can be contained in one window is ending.

One window cannot hold the whole development process anymore. Coming from a company that has built IDEs for 26 years, that carries weight.

Third, its bet is explicitly on multiple vendors, and the reason is stated plainly: models are good at different things, the leaderboard changes every few months, and teams already have their own preferences. So it does not bet on who wins. It wants everyone to pass through it.

My read

First, the real move here is scheduling control. Whoever holds the switchboard for your pile of agents (who is running, what changed, what it cost) holds the developer’s daily entry point. You can orchestrate in a terminal too, tmux plus scripts gets you there, but the IDE holds real code intelligence. It argues that handing agents this intelligence saves money, because agents no longer have to rediscover information already in the code.

Second, openness is a strategy, not goodwill. ACP is an open protocol it pushed together with Zed, and most of the 41 agents are not theirs, even Claude, Codex and Cursor are in the registry. It does not need to bet on a winner. It wants everyone to pass through once.

Third, I mark the boundary as usual. What I verified: installation and version compatibility, that the plugin actually loads, the signed registry and its 41 entries, independent signature verification, and the ACP handshake plus the capabilities the agent reports. What I did not manage: multi-session parallelism in the IDE UI, worktree isolation, and the cost display. Local permissions were not enough, I could not click. So this post counts as log-and-protocol-level evidence, not a full feature test. On top of that it is still EAP, so do not rush to change your workflow.

References:

• Air in IDEs EAP post: https://blog.jetbrains.com/ai/2026/10/air-in-ides-eap/
• September 22 Air announcement post (signed by the CEO): https://blog.jetbrains.com/blog/2026/09/22/introducing-jetbrains-air/
• ACP protocol site: https://www.jetbrains.com/acp/
• ACP registry and submission entry: https://github.com/agentclientprotocol/registry
• Air plugin page: https://plugins.jetbrains.com/plugin/33314-air-alpha
• Android Studio download: https://developer.android.com/studio

Verification boundary: the plugin version line and download count come from the JetBrains plugin marketplace API; the Android Studio version comes from the product-info.json of the local install; plugin loading, registry fetch, the 41 agents, the acp.json path, the Codex IPC socket and the cloud-needs-login lines all come from the real idea.log on this machine.

The list of 41 agents, the distribution method of each entry and the licenses come from the fetched registry.json; I verified the signature independently with pgpy and it passed. The handshake response is real terminal output. Authentication was not completed, so no model answer was obtained.

On the morning of September 30, DeepSeek announced on its official WeChat account that it is open-sourcing infrastructure components for Huawei’s Ascend compute platform: a TileLang high-level language compiler tool, a high-performance compute library, and a distributed communication library. Their wording was that these correspond one-to-one with the components previously open-sourced for NVIDIA’s platform.

Reuters reported it plainly that day, calling it another signal that Chinese tech companies are deepening cooperation and looking for alternatives to the NVIDIA ecosystem.

Chinese AI firm DeepSeek said on Wednesday it has partnered with Huawei Technologies to develop programming tools optimised for Huawei’s Ascend chips. Bloomberg’s headline was more direct: the Huawei chip tools DeepSeek just showed off could replace NVIDIA’s.

I read a lot of the Chinese coverage, and most of it stops at the four characters “matches CUDA.” So this post is not a rehash of the announcement. I went through all six repos, then actually installed TileLang on my own Mac to see what it can compile and what it cannot.

Six repos, all checked

These are the six links from the announcement. The star counts and creation dates I pulled live from the GitHub API:

Note the last row. Of the six repos, only DeepEP-Ascend declares no license; the other five are MIT. If you are doing enterprise vendor selection, that cell is worth confirming yourself.

One more thing worth being clear about: not all of the “Ascend support” is in new repos. I went through the commit history of the original repos:

FlashMLA     2026-09-30  Open-source release for Ascend 950 (2026.09.30) (#229)
DeepSelect   2026-09-30  Add Kernels for Huawei Ascend NPU (#23)
TileKernels  2026-09-30  Release tile-kernels v2.0.0

FlashMLA and DeepSelect merged the Ascend kernels straight into the mainline. Only DeepGEMM and DeepEP got separate -Ascend repos, because the changes were large. So “one-to-one” is not marketing language. It checks out.

Where it sits relative to the CUDA ecosystem

Here is how I mapped the six pieces:

• TileLang maps to the layer where you write kernels (where CUDA C++ and Triton live)
• DeepGEMM maps to matrix multiplication, the cuBLAS slot
• DeepEP maps to cross-card communication, the NCCL slot
• FlashMLA covers long-context and sparse attention kernels
• TileKernels covers ordinary vector math and memory-access kernels
• DeepSelect covers data filtering

The official line on TileLang: it is simpler to program than CUDA, it significantly improves development efficiency and simplifies code logic, and it loses no hardware performance. They added one key sentence: the TileLang path was already validated on NVIDIA’s platform, and it now carries most of the kernel implementations in DeepSeek V4 series model training.

That sentence carries more weight than any benchmark. It means they are not reinventing something on Ascend. They are moving over the thing they already got comfortable with on NVIDIA.

The numbers they published

Performance data comes from the official announcement and Huawei’s contributed piece. I am relaying it as-is, with the caveats stated afterwards:

• Communication: DeepEP’s Dispatch reaches 375 GB/s, Combine 347 GB/s; the team says this is close to the hardware ceiling
• Networking: Ascend 950’s SuperPoD Flex with the UBL128 scheme, 128 cards in a single layer at 3.2 Tbps scale-up, 256K cards in two layers of scale-out
• Inference: running DeepSeek-V4.1-Flash in EP32 offline mode, 2469 tokens/s per card at TPOT=5ms, 5102 tokens/s per card at TPOT=10ms (128K context, Dspark speculative acceptance rate 0.85)

One warning: these are vendor numbers, measured under offline inference, and they do not include serving scheduling or framework load balancing. I have no Ascend hardware here, so I cannot run this benchmark. I can only tell you that this is what they said.

I tried TileLang on my own Mac

Reading the news is boring, so I installed it.

uv venv --python 3.12 /tmp/tl
uv pip install --python /tmp/tl/bin/python tilelang
# tilelang 0.1.15 | torch 2.14.1

The install went smoothly, and there is a macOS arm64 wheel. Then I wrote a minimal kernel, 128×128 element-wise addition:

@T.prim_func
def main(A: T.Tensor((M, N), dtype), B: T.Tensor((M, N), dtype), C: T.Tensor((M, N), dtype)):
    with T.Kernel(T.ceildiv(N, block), T.ceildiv(M, block), threads=128) as (bx, by):
        for i, j in T.Parallel(block, block):
            C[by * block + i, bx * block + j] = A[by * block + i, bx * block + j] + B[by * block + i, bx * block + j]

Then I compiled it for three targets. The results were tidy:

target = c (CPU)    ✅ compiled, generated 448 characters of C source
                     run output matches reference: True
target = cuda       ❌ module 'tilelang.cuda._ffi_api' has no attribute
                     'AnnotateDeviceBoundTmaCopies'
target = ascend     ❌ AssertionError: Target ascend is not supported

The Ascend error annoyed me, so I bypassed its detector and stuffed a Target dict in directly. What came back:

ValueError: Target kind "ascend" is not defined.
Target creation from config dict failed: {"kind": "ascend"}

Reading the source explains it. Its Ascend availability check is written to require torch.npu.is_available() to be true, meaning a real Ascend runtime has to be attached.

The package actually ships Ascend codegen sources and templates (src/ascend, src/tl_templates/ascend/*.h, plus an npu interchange layer extension), but the runtime in this wheel does not register an Ascend target. So:

This Mac can prove TileLang is a real compiler (the CPU target compiles and runs correctly). It cannot prove the Ascend path.

To genuinely compile for Ascend, DeepGEMM-Ascend’s README is rigid about it:

Requirements
- HUAWEI Ascend NPU (developed and validated on the Ascend 950 series)
- CANN 9.20 toolkit providing bin/bisheng, bin/ld.lld
- Torch NPU package torch_npu
- Python 3.10 or higher

pip install . --no-build-isolation, and then you also need the card. On my path, the missing item is that last line.

What this means if you build clients

If you write applications (like the AI chat client I have on my desk), nothing changes in the short term. API prices and response latency stay where they are.

What is actually worth watching in the medium term is the word “supply.” If the same model code can run on Ascend with a few lines changed, the usable share of domestic compute goes up, and that downward curve on inference cost gets a little steadier. The relevance to you is not saving money today. It is one more variable on next year’s quote sheet.

There is a further effect, further out: if TileLang’s “write kernels in a high-level language without losing performance” spreads, the cost of adapting kernels for on-device small models comes down too. If you do on-device inference, watch this, not the benchmark numbers.

My read

First, the genuinely hard part of this release is not writing the kernels. It is making developers not rewrite code per piece of hardware. Six repos and the one-to-one claim is exactly that, compressed into a sentence.

But the Target kind "ascend" is not defined from my test shows the other side: right now, the far end of this path is tied to hard version dependencies like CANN 9.20. Change platform, change version, and wherever the link does not hold it will tell you very bluntly.

Second, the direction is clear. NVIDIA’s position was never just about fast chips. It is the twenty years of CUDA accumulated around them: libraries, tools, docs, and people’s habits. That is the position DeepSeek and Huawei are going after, and they are going after it with a language already proven in their own training runs, not starting from zero.

Third, the boundaries need marking. I have no Ascend hardware, so every performance number in this post comes from the vendor. What I verified myself is three things only: the real state of the six repos, the fact that Ascend kernels did get merged into the original repos’ mainlines, and what TileLang can and cannot compile on that Mac.

References:

• DeepSeek official open-source announcement (relayed by ITHome): https://www.ithome.com/1/008/604.htm
• Huawei contributed piece (including performance and networking data): https://www.qbitai.com/2026/09/499263.html
• Reuters report: https://www.reuters.com/world/asia-pacific/deepseek-partners-with-huawei-develop-chip-programming-tools-reducing-reliance-2026-09-30/
• DeepGEMM-Ascend repo: https://github.com/deepseek-ai/DeepGEMM-Ascend
• DeepEP-Ascend repo: https://github.com/deepseek-ai/DeepEP-Ascend
• TileLang: https://github.com/tile-ai/tilelang

Verification boundary: repo star counts, creation dates, and licenses were read live from the GitHub API; the Ascend commit records come from each repo’s commit history; the TileLang install and the three-target compile results were run on this machine (macOS arm64, tilelang 0.1.15, torch 2.14.1); performance and bandwidth numbers are all vendor figures — there is no Ascend hardware here, and no benchmark was run.

First reaction: “oh, finally.”

Second reaction: “I can’t use it anyway.”

On September 30, Google’s blog published Gemini 4 Argon, bylined to Koray Kavukcuoglu, senior VP at Google DeepMind. It hit the Hacker News front page the same day. The opening line is restrained:

Today, we’re announcing our new frontier model, Gemini 4 Argon, which is rolling out to a set of trusted cyber defenders through our Fairwind Program.

Which translates to: it goes to a batch of trusted cyber defenders first. Not to you.

I know this road well. This is how model vendors have shipped frontier capability for years. First the US government’s voluntary pre-deployment evaluation, then a small circle of trusted testers, and only then developers, enterprises and ordinary users. The post even spells out the order: “starting with paid API customers and Google AI Ultra subscribers”.

So the accurate statement is not “Gemini 4 shipped”. It is “Gemini 4 was announced, and a small batch went out.”

Right now you really can’t use it

I didn’t want to get anyone’s hopes up, so I checked two places myself.

First, Google’s own developer docs. On the Gemini API model list page (marked updated September 24), the newest entries are still Gemini 3.8 Flash, 3.8 Live, 3.8 Flash TTS. No argon endpoint. Which means even with an API key you can’t call it.

Second, prediction markets. Polymarket runs a “when will Gemini 4.0 launch” market with $880K in volume and rules written in stone:

For this market to resolve to “Yes,” Gemini 4.0 must be launched and publicly accessible… A closed beta or any form of private access will not suffice.

A closed beta doesn’t count. There has to be a publicly reachable entry point. So on that market, September 30 sits at 1%, October 15 at 68%, October 31 at 88%, November 30 at 94%. Bettors putting real money down are saying they don’t think that day counted as a launch.

Put the two together and the weight of this gets clear. The cards are face up, but they’re still in Google’s hand.

What Argon actually puts on the table

Can’t use it, but the post carries a lot. Here’s what I pulled out.

Output cap raised to 1M tokens. The post says from 64K to 1M, and calls it “industry-leading”. This matters more than it sounds: a model that can write hundreds of thousands of tokens in one go turns “long-horizon task done in one shot” from a demo into something you can configure.

A whole row of benchmarks. 77.9% on DeepSWE v1.1, which the post calls the new SOTA on real-world, long-horizon software engineering tasks. 51.3% on AutomationBench, first place in Zapier’s end-to-end business workflow eval. 91.7% on LVBench for long-video understanding. 68% on CWE-bench v1 for vulnerability repair, tied for first.

It also name-checks Vals Index, Vals Finance Agent v2 and Harvey’s legal agent benchmark, all framed as leading.

Pricing pinned right up against competitors. Introductory $2 per million input tokens, $10 output, 95% off cached input, back up to $4 and $20 after the intro window.

The most concrete part is how Google itself uses it. Three internal cases, and I find them more meaningful than the benchmarks: the quantum computing team used it to optimize subroutines, beating the published baseline by 40%; a set of agents analyzed fleet-wide performance data for memory optimization, freeing 300 TiB up front with 500 TiB to 1 PiB expected at the end.

Then large-scale C/C++ to Rust migration, from re2 and libgav1 all the way to Fuchsia’s Zircon kernel, over 800,000 lines. The libgav1 case is specific: the agent converted 32,000 lines of SIMD code into safe Rust that runs 2.7x faster than the existing Rust port.

Security it lays out fairly openly. The build for trusted defenders ships without cyber guardrails so they get the full attack surface. The public build emphasizes protection against indirect prompt injection (claimed leading on Gray Swan’s IPI benchmark), plus mismatch monitoring over chain of thought and actions. Wiz already used it to find a high-severity vulnerability in medical software used by hospitals worldwide, one that a previous frontier model missed.

What everyone else was doing the same day

This is where the “big three” line comes from. This half month was not a solo Google show.

Timeline first. Anthropic shipped Fable 5.1 and Mythos 5.1 on September 1, then Opus 5.5 on September 22 — one line summary: “matches Fable 5.1, 40% cheaper than Opus 5”. Then Sonnet 5.5 on September 28, “30% faster, up to 30% cheaper on most work”.

On OpenAI’s side, September 30 (same day) brought GPT-6.1 Sol, with a subtitle blunter than Google’s:

Near-Astra intelligence for a fifth of the price

Near-Astra intelligence at a fifth of the price. $2 per million input, $10 output, $0.10 cached input. A few concrete numbers: matches Astra on DeepSWE v1.1 at a fifth of the cost; beats Opus 5.5 on GDP.pdf at less than half the cost per task.

On Terminal-Bench Science, the scientific workflow benchmark, it costs $5.47 per task. Opus 5.5 is $23.21, Astra is $23.80.

You may have noticed something already. Google and OpenAI both report DeepSWE v1.1 and AutomationBench, and both landed cached input at $0.10. Benchmark framing and pricing framing converging at the same time means both are staring at the same customers.

Now look at what each of them has been filling in. Since Gemini 3 late last year, Google has shipped 3.5, 3.6, 3.7, 3.8 Flash variants along the way, the planned 3.5 Pro vanished without a trace (that’s media reporting, Google never said), and Argon only comes out now. Anthropic’s updates all landed on cheaper and faster. OpenAI’s Sol is Astra’s capability sold at a discount.

So does “the old guard is back” hold up

My read: rather than back, they changed how they play. Three things are pretty obvious.

One, they stopped competing on chat and started competing on whose work gets done. This month the keywords across all three are long-horizon software engineering, financial research, legal drafting, vulnerability repair, business workflows. All expensive, specialized, budgeted places.

Two, frontier models now ship in limited release. Google even says plainly this time that guardrails get hardened as access widens, and public release is “gradual”. That’s not the era of publish a blog post and everyone can call it. Frontier capability looks more and more like a controlled resource.

Three, the price war changed its unit. It used to be dollars per million tokens. Now both sides quote cost per task. Sol’s “$5.47 per task versus $23.21” is the most effective ad copy going right now.

So I’m not comfortable with the word “back”. Nobody got chased out and returned. What happened is that once open source took cheap and self-hostable, this batch of old guard turned around to take expensive work and distribution.

For people writing AI clients, two parameters are worth actually remembering. One is cached input pushed down to $0.10 per million tokens, which is a direct cost variable for clients with long sessions and repeated context. The other is that the eval names changed: DeepSWE v1.1, AutomationBench, CWE-bench are closer to “can you actually do the work” than the MMLU generation was. Next time you pick a model, these beat the overall leaderboard.

One honest boundary

There is no API key from any of them on this machine (I checked, all empty), so every number in this post — the 77.9%, the 51.3%, all the pricing — comes from official launch pages and public benchmark leaderboards. I have not run Argon, and can’t. It is only open to trusted defenders in the Fairwind program.

What’s official, what’s media reporting, what’s third-party prediction, I marked in the text. For example “3.5 Pro was cancelled” is media reporting. Polymarket odds are market prediction, not fact.

As for my own next step: the day it opens to paid API customers, I’ll run it against the AI Chat client I have and watch two things — whether a one-million-token output cap is actually usable in a real conversation, and how much that $0.10 cached input saves over long sessions. Then I’ll write one with data.

Do you think this round is “the old guard is back” or “the old guard changed how it sells”? When did you last genuinely pay for someone’s API?

References:

• Introducing Gemini 4 Argon (Google official): https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-argon/
• Introducing GPT-6.1 Sol (OpenAI official): https://openai.com/index/introducing-gpt-6-1-sol/
• Anthropic Newsroom (Opus 5.5 / Sonnet 5.5 / Fable 5.1): https://www.anthropic.com/news
• Gemini API model list: https://ai.google.dev/gemini-api/docs/models
• Polymarket “Gemini 4.0 released” market: https://polymarket.com/zh/event/gemini-4pt0-released-by-june-30-2026

Same JSON, same app, same run.

The first: the form is full. Guest Ada Lovelace, date Oct 1, 2026, time 7:30 PM, party of 2, two buttons underneath reading Cancel and Confirm booking. Native Material 3 controls all the way down.

The second: the same form, every field empty. Not just empty. The labels on both date-time controls are gone too, leaving two gray rounded boxes.

The only difference is when I sent the updateDataModel message. Send it in the same batch as the components and the fields get dropped. Send it a second later, on its own, and the values land. I will come back to this. It is the most valuable hole I fell into this time.

What A2UI is

One sentence, their words:

A2UI (Agent to UI) is a declarative UI protocol for agent-driven interfaces. AI agents generate rich, interactive UIs that render natively across platforms (web, mobile, desktop) without executing arbitrary code.

The agent does not emit HTML or JavaScript. It emits declarative JSON describing what the interface looks like, and the client renders it with its own native components. The scenario they use to contrast it is the classic one:

User: “Book a table for 2 tomorrow at 7pm” Agent: “Okay, for what day?” User: “Tomorrow” Agent: “What time?”

Three round trips to fill one form. Swap in an agent that generates the form itself, with a date picker, a time picker and a submit button, and the user is operating an interface instead of talking to one.

The smartest design in this protocol, I think, is the catalog. It does not let the agent invent UI freely. The client declares a contract first: these are the components, these are the properties, these are the local functions. The agent can only pick and compose inside that contract. The spec puts it plainly:

Rather than having an agent generate arbitrary UI code or invent unregistered components, the catalog acts as a contract that defines the specific UI elements, properties, and functions available to the agent.

Add the sends-data-not-code property and the security math gets easy: no iframe, no arbitrary code execution.

The official renderer on the Compose side

On September 23, AndroidX shipped an A2UI renderer for Jetpack Compose, 1.0.0-alpha01. I checked each of these artifacts on Google Maven; they all exist:

implementation("androidx.a2ui.compose:compose-runtime:1.0.0-alpha01")  // fine-grained recomposition on Compose Snapshot state
implementation("androidx.a2ui.compose:compose-ui:1.0.0-alpha01")       // components and catalog definitions
implementation("androidx.a2ui:a2ui-model:1.0.0-alpha01")               // protocol data layer
implementation("androidx.a2ui:a2ui-engine:1.0.0-alpha01")              // parsing, schema validation
implementation("androidx.compose.material3:material3-a2ui:1.0.0-alpha01")  // Material 3 implementation of the Basic Catalog

material3-a2ui is the finished product: the Material 3 implementation of the Basic Catalog, one line and it runs. What you have to supply is image, video and audio players, plus callbacks for opening URLs and formatting localized text. Leaving out Coil and Media3 is deliberate:

The A2UI libraries intentionally don’t bundle external media and networking dependencies, such as Coil, Glide, or Media3. Instead, you provide your own renderers.

One more thing KMP developers will ask about immediately. I unpacked the Gradle module metadata for compose-runtime:

- releaseVariantReleaseApiPublication     type=aar
- releaseVariantReleaseRuntimePublication type=aar

Only aar. No klib, no JVM variant. This release is Android-only, so Compose Multiplatform cannot use it today.

Minimal wiring

Two objects on the data side: a parser and a processor.

private val parser = A2uiMessageParser()

private val catalog = materialA2uiBasicCatalogV1(
    image = MaterialA2uiBasicCatalogV1Defaults.image { url, _, _, modifier, _ ->
        Placeholder("image", url, modifier)
    },
    urlOpener = { url -> Log.i(TAG, "open $url") },
    messageFormatter = { pattern, locale, args -> /* MessageFormat */ },
    localeProvider = A2uiLocaleProvider.Default,
)

private val processor = A2uiMessageProcessor(catalogs = listOf(catalog))
val surfaces = processor.activeSurfaces

init {
    viewModelScope.launch(Dispatchers.Default) { processor.collectMessages() }
    viewModelScope.launch(Dispatchers.Default) {
        processor.outboundEvents.collect { Log.e(TAG, "OUTBOUND: $it") }
    }
}

The UI side is one loop, handing each surface to A2uiSurface:

surfaces.forEach { surface ->
    key(surface.id) {
        A2uiSurface(surfaceModel = surface, modifier = Modifier.fillMaxWidth())
    }
}

What goes in is three protocol messages. createSurface opens the canvas, updateComponents describes the component tree, updateDataModel supplies the bound values:

{ "version": "v0.9",
  "createSurface": { "surfaceId": "booking",
                     "catalogId": "https://a2ui.org/specification/v0_9/catalogs/basic/catalog.json" } }

{ "version": "v0.9",
  "updateComponents": { "surfaceId": "booking",
    "components": [
      { "id": "root", "component": "Column", "children": ["title", "nameField", "actions"] },
      { "id": "title", "component": "Text", "text": "Book a Table", "variant": "h1" },
      { "id": "nameField", "component": "TextField", "label": "Guest name",
        "value": { "path": "/booking/name" }, "variant": "shortText" }
    ] } }

Note that value on a component is not the value itself but a path into the data model. Which is exactly why whether that third message lands determines whether your form is full or empty.

Once it runs, the pits come one after another

Every item below is something I actually hit and then found the cause or the workaround for. Not one of them is in those two pages of docs.

1. updateDataModel sent in the same batch as updateComponents gets silently dropped. This is the nastiest one. The surface appears normally, nothing errors, and every property bound through path comes up empty. Resend the same bytes one second later and the fields fill in immediately. logcat says all three messages parsed OK and the surface count is 1, but the values never land:

parsed OK -> A2uiCreateSurfaceMessage surfaceId=booking
parsed OK -> A2uiUpdateComponentsMessage surfaceId=booking
parsed OK -> A2uiUpdateDataModelMessage surfaceId=booking
activeSurfaces.size=1 ids=[booking]

So what I ended up doing: send createSurface and updateComponents first, wait for the surface to appear, then push the data model. That happens to be the real order a streaming agent produces anyway. Accidental and correct at the same time.

2. catalogId is v0_9, not v0_9_1. The “stable” example on the docs site says version: v0.9.1 and .../v0_9_1/.... The actual constants in the library are protocol = v0.9 and .../v0_9/catalogs/basic/catalog.json. The parser accepts either version string, but createSurface.catalogId has to match the id of the catalog you registered exactly. Miss it and the surface never appears, again with no error. My fix: stop copying strings out of docs and read them from the library constants.

3. processInput is not a method on A2uiMessageProcessor. It is a top-level extension function in the androidx.a2ui.model.processor package. You have to import androidx.a2ui.model.processor.processInput. Copy the line from the docs verbatim and it will not compile.

4. Failures are silent. Inside, processInput swallows A2uiException, turns it into processor.processError(...), and emits it only on outboundEvents. If you are not collecting that flow (the docs collect it, but never say what skipping it costs), protocol errors and parse failures are completely invisible and all you get on screen is a white box. First thing when debugging this library: wire up outboundEvents.

5. material3-a2ui:1.0.0-alpha01 does not work with the current stable Compose BOM. Its POM demands androidx.compose.* 1.13.0-alpha03 and pins material3 to a strict [1.5.0-alpha28] range. The stable BOM resolves to 1.12.x, so it will not install. I ended up dropping the BOM and pinning versions by hand.

6. There is no documentation for compileSdk 37 minor 1. compileSdk = 37 cannot find the already-installed android-37.1. What works is:

compileSdk { version = release(37) { minorApiLevel = 1 } }

7. The surface root component id has to be root. It is a private constant. Name it anything else and your Column is not the root.

8. Enum values are pure guesswork. Get one wrong and the schema fails, and the docs do not list them:

Text.variant           h1 h2 h3 h4 h5 caption body
Button.variant         primary secondary borderless
TextField.variant      shortText longText number obscured

My approach was to javap the enums out of the AAR and read them one by one.

One more, unrelated to A2UI but impossible to dodge: adding org.jetbrains.kotlin.android under AGP 9.x gets rejected outright. Kotlin support has been built into AGP since 9.0, so you keep only the compose plugin.

My verdict

It works, and what it renders really is native Material 3, not a wrapped web page. But at alpha the docs are running behind the code. The real catalogId, the shape of processInput, message ordering, how to pin versions: you have to unpack the artifacts and look. Good for a proof of concept right now. Do not rush it into production.

On the KMP side, wait. The aar-only fact alone settles it: Compose Multiplatform only gets the Android half.

What I want to try next is closing the outbound path: the user taps Confirm booking, the event goes back to the agent, and the agent sends another updateComponents to change the UI based on the result. I only wired that path up. I never actually pressed the button, so I am not claiming here that it works.

Would you let an agent generate the interface in your AI chat client directly? Or would you rather hard-code the UI and only let the agent fill in content? Comments are open.

References:

• A2UI protocol site: https://a2ui.org/
• The A2UI renderer for Jetpack Compose (official docs): https://developer.android.com/develop/ui/compose/agentic
• Custom catalogs: https://developer.android.com/develop/ui/compose/agentic/manage-catalogs
• A2UI Compose release page: https://developer.android.com/jetpack/androidx/releases/a2ui-compose

Verification boundary: both screenshots, the parse logs for the three messages, the catalogId and protocol version constants, the A/B on message ordering, and the build and install all come from running on a real emulator on this machine (Android emulator API 36.1, APK 13,471,211 bytes, BUILD SUCCESSFUL). Component property names and enum values came from javap on the unpacked AAR. The tap-to-agent return path was not exercised. Images, video and audio use placeholder renderers, not real loading libraries.

On September 28 DeepSeek Harness shipped v0.2.0-rc.1. Two items in the release notes concern plugins: an improved plugin management UI and install guidance, and a creation mode with fleshed-out plugin development instructions plus an experience skill.

Note it sits on the npm next tag. latest is still at 0.1.7-rc.2, so the default command will not get you this version.

I ran the new version in an isolated directory (separate prefix and DSH_HOME), leaving the instance running on this machine untouched. Everything below comes from 0.2.0-rc.1.

There are three paths now

The new version spreads writing a plugin across three entry points, with the bar dropping each time.

The first is the Plugin page in the web sidebar. Start and stop plugin entries, tick bundle checkboxes, install or remove third-party bundles, all clicked in the UI without hand-editing config files.

The second is creation mode. Pick it when creating a task and tell the agent to install something in one sentence. The official example prompt has exactly that tone:

Help me write a DSH plugin that adds a Project Notes entry to the sidebar, lists the Markdown files in the current workspace, and previews their content when clicked. Complete the install and verify the page opens.

The third is still hand-writing the three files, the shortest and most controllable. All three paths lead to the same mechanism, so understand the mechanism first and the other two stop being black boxes.

The shortest path is still three files

The official tutorial’s directory is just three files:

hello-plugin/
├── package.json       # declares dsh.bundle
├── cordis.patch.yml   # the config layer this package contributes
└── index.js           # the plugin entry the patch line references

The part of package.json that actually matters is the dsh.bundle block:

{
  "name": "dsh-hello-plugin",
  "type": "module",
  "main": "index.js",
  "dsh": { "bundle": { "patch": "./cordis.patch.yml" } }
}

index.js is the entry for a Cordis plugin. On load the framework calls apply with a context, and through that ctx the plugin registers everything it contributes:

export const name = 'hello-plugin'

export function apply() {
  console.log('[hello-plugin] plugin loaded!')
}

cordis.patch.yml is the one line you contribute. Write the package name here, not a file path, so Node can find you in the profile’s node_modules:

- insert:
    - id: hello
      name: dsh-hello-plugin

Installing is one command. The CLI entry is dsh, and dsh plugin --profile <name> forwards its arguments to pnpm in the profile directory:

dsh plugin --profile demo add ./hello-plugin

I stepped in a hole here: I cd’d into the package directory and then wrote add ./hello-plugin. DeepSeek Harness resolves against the current directory, recorded the dependency as link:/private/tmp/hello-plugin/hello-plugin, one path segment too deep, and startup failed with cannot resolve profile bundle. I reproduced this on both versions. You have to run it from the package’s parent directory.

After install, check two layers

The first is config. dsh --profile demo --dump-config prints the full merged tree. I only kept the layer markers, and the second one is mine.

# == @deepseek-ai/dsh-base
# == dsh-hello-plugin

The second is runtime. After startup [hello-plugin] plugin loaded! shows up on screen. At this point, from creating the directory to seeing that line is three commands.

Two things the new version adds for plugin developers

One is a command line flag. The new version has --dump-config-schema, which prints the JSON Schema for profile entries and patches. My output was 156,000 characters with 73 definitions, including entry, patch, patchList, includePatch. Before, confirming which fields a line could actually take meant reading source. Now you can ask the schema.

The other is inside the app. Creation mode ships with a plugin development guide, and it reads like this:

Creation mode has the standard task tools, plus runtime checks, persistent plugin management, and development guidance for Cordis plugins and Agent presets. You can write plugins to add features or UI, or combine tools and prompts to create a mode suited to a specific task.

The guide also explains the relationship between plugins and modes: a plugin adds capabilities to DeepSeek Harness, such as tools, service connections or UI entry points; a mode is an Agent preset that decides which tools a task can use and how it works. Custom modes can use plugins you wrote yourself.

The section on how to make results take effect reads more like a reminder: you can have the Agent do the install and verify the actual result, and a plugin may load immediately or need a restart depending on what changed.

Letting the agent do it, and where the boundaries are

The tool available in creation mode is called plugin_manager. I took its real description from a recorded snapshot in the repo:

List plugins or bundles in the current profile, enable or disable them, install a bundle, or remove an installed bundle. Every action requires danger-full-access permission or approval for this call. Approval does not change the session permission mode. Changes affect every session in this profile.

It takes nine parameters. Besides action and target, there is registry (which source to look in), approvedBuilds (approve dependency build scripts on your behalf), and a pair for version exemptions, runtimeVersion and acceptRisk.

Three boundaries in that description deserve pulling out.

First, every operation needs danger-full-access or a one-off approval for this call. Approval does not change the session’s permission mode, meaning approving once is not a standing pass.

Second, changes are written into the profile and affect every session under it. Not just the conversation you are in.

Third, installed Host code runs inside the host process, outside the workspace sandbox. The weight of that sentence: a plugin and the permissions it can reach equal your own permissions in that terminal.

Incompatible plugins get blocked

The new version adds a pre-check in package management: if the runtime version your plugin declares does not match this DeepSeek Harness, the operation fails before pnpm starts, so nothing gets downloaded and no build script runs.

If you really want to install it you go through a version exemption. The exemption is written into the profile’s own compatibility.json, mapping an exact package@version to an exact runtime version, and it must carry acceptRisk: true. Three matching CLI commands:

dsh plugin --profile web version-exemptions
dsh plugin --profile web allow-version <package@version> --dsh-version <runtime> --accept-risk
dsh plugin --profile web revoke-version <package@version> --dsh-version <runtime>

Neither a plugin upgrade nor a DeepSeek Harness upgrade inherits the grant. You have to decide again. I think the design is right: an exemption is a one-time informed decision, not a permanent pass.

Layer order, and the rule that costs people the most

The effective config merges over an empty root in four layers, later layers overriding earlier ones line by line:

1. Each bundle patch in the profile’s dsh.profile.bundles list, in list order
2. The profile’s own cordis.patch.yml
3. The home-level $DSH_HOME/cordis.patch.yml, shared by all profiles
4. Every --patch <path> on the command line, in argv order

The rule that costs people the most: a patch replaces the target line’s entire config, it does not deep-merge keys. To override a line from an earlier layer you must restate every key that line needs. Write only the one you changed and the rest get wiped.

The flip side is good news: users can override your line in their own profile’s cordis.patch.yml without touching your package. So pick defaults that users will most likely keep.

The same failure, run once on each version

The official Cordis tutorial says a failed plugin load reports a clear error, but a module that cannot be resolved (wrong path or package name) only logs and does not crash.

On 0.1.6-alpha.2 that did not match. I made apply throw, and the whole plugin tree failed to load, the process exited 1, and the first line named the plugin entry. Wrong package name, also exit 1, with Cannot find package.

On 0.2.0-rc.1 both failures became warnings and the process stayed alive:

dsh: warning: 1 entry did not activate
hello (dsh-hello-plugin): Error: apply exploded

The bad package name is even shorter, a single line: hello (dsh-hello-pluginX): failed to import.

This is a real behavior change in the new version. My read is that it is friendlier, but also quieter: a plugin not taking effect does not necessarily mean it failed to install, it may just be that entry not activating. After upgrading, if something looks installed but does nothing, search the startup output for did not activate first. Much faster than reinstalling repeatedly.

Last

The minimum path to doing this is still three steps: create the directory and put three files in it, install with dsh plugin --profile <your profile> add ./your-plugin-dir, confirm the layer appears with --dump-config. If you want less work, just say it out loud in creation mode and let it install and then verify for you.

What I want to try next is --dump-config-schema, generating a cheat sheet of available fields for a plugin line from the schema. Less work than digging through docs.

What are you going to hang on DeepSeek Harness? A new tool for the model, or a card in the sidebar like the batch of community plugins? Tell me in the comments. Maybe the next post is about yours.

References:

• Packaging and installing plugins (official): https://github.com/deepseek-ai/deepseek-harness/blob/main/docs/user/develop/basic/publish.zh.md
• Persisting plugin config through prompts (creation mode): https://github.com/deepseek-ai/deepseek-harness/blob/main/docs/user/develop/practice/dynamic-cordis.zh.md
• Plugin Manager package reference: https://github.com/deepseek-ai/deepseek-harness/blob/main/packages/boot/plugin-manager/README.zh.md
• DeepSeek Harness v0.2.0-rc.1: https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.2.0-rc.1

Verification boundary: the three-file install, the --dump-config layer output, the startup log, both failure behaviors, the size of the --dump-config-schema output, and the parameters and description of plugin_manager were all checked on 0.2.0-rc.1 locally (installed under an isolated prefix and isolated DSH_HOME, with the running instance untouched); the 0.1.6-alpha.2 comparison data also comes from local runs. The path where creation mode has the agent install a plugin was not actually run, because this machine has no usable model key; that section is based on the official docs and the in-app guide text.

On the night of September 28, the DeepSeek Harness plugin list gained three entries at once: crypto-ticker, a crypto price card in the lower left of the sidebar; busy-workspace, which pins workspaces with running sessions to the top of the list; and router-laya, which picks a thinking level for each message automatically.

The same night, dsh v0.2.0-rc.1 shipped, the first release candidate of the 0.2 line. The release notes call out two plugin-related items: “improved plugin management UI, built-in plugin UI layout and interaction, better install guidance”, and “creation mode now has fuller plugin development guidance plus an experience skill”.

Installing a plugin is one command. Writing one is where the specific obstacles show up: what shape a plugin actually takes, how config gets composed, and where to look when you install it and nothing happens.

This post walks the official developer docs again, in the order I actually got things working. Conclusion up front: a loadable plugin is three files, and installing it is one command.

First, two concepts: bundles and profiles

The docs have one line that nails it:

A bundle is an npm package that carries a configuration layer… A profile is a directory describing one launchable composition… Nothing is both.

In plain terms: a bundle is an npm package carrying a config layer, answering “what does this package contribute”. A profile is a directory under $DSH_HOME/profiles/<name>, answering “which bundles compose this setup, and in what order”.

The plugin you write is a bundle. A user installs it into their profile, and the profile stacks the base layer, your layer, and the user’s own layer in order. dsh’s own base and web app are assembled the same way, layer by layer, so “everything is made of plugins” is not just a slogan.

The first plugin: three files

The official tutorial gives this directory layout:

hello-plugin/
├── package.json       # declares dsh.bundle
├── cordis.patch.yml   # the config layer this package contributes
└── index.js           # plugin entry referenced by the patch line

Only one part of package.json matters:

{
  "name": "dsh-hello-plugin",
  "version": "0.1.0",
  "type": "module",
  "main": "index.js",
  "files": ["index.js", "cordis.patch.yml"],
  "dsh": { "bundle": { "patch": "./cordis.patch.yml" } }
}

index.js is the Cordis plugin entry. Cordis calls apply with a context when it loads the module, and the plugin registers everything it contributes through that ctx:

export const name = 'hello-plugin'

export function apply() {
  console.log('[hello-plugin] plugin loaded!')
}

cordis.patch.yml is the line you contribute. Note that name here is the package name, not a file path, so Node’s module resolution can find you inside the profile’s node_modules:

- insert:
    - id: hello
      name: dsh-hello-plugin

Install it, but don’t start yet

dsh plugin --profile <name> forwards its arguments to pnpm inside the profile directory, so every pnpm subcommand works:

dsh plugin --profile demo add ./hello-plugin

The first run also initializes the profile, with @deepseek-ai/dsh-base as the first bundle. Because your package declares dsh.bundle, dsh appends it to the profile’s bundles list.

This is where I hit pothole number one. I had cd’d into the hello-plugin directory and then ran add ./hello-plugin. dsh resolves against the current directory, so the dependency got recorded as link:/private/tmp/hello-plugin/hello-plugin, one path level too deep, and startup blew up:

Error: dsh: cannot resolve profile bundle "hello-plugin" from the dsh installation or /tmp/dsh-home-test/profiles/demo

Running dsh plugin --profile demo add ./hello-plugin from the parent directory fixed it. The tutorial’s line about installing in the directory containing hello-plugin means the parent.

Confirm the layer actually landed

You can see how the config stacks without starting anything:

dsh --profile demo --dump-config

The layer markers in my output were just two, and the second was mine:

# == @deepseek-ai/dsh-base
# == dsh-hello-plugin

Then actually start it:

dsh --profile demo

[hello-plugin] plugin loaded! showed up on screen. From creating the directory to seeing that line: three commands. Install, check the layers, start.

One detail worth noting: my environment had all_proxy=socks5://... set when I started, and dsh came back with all_proxy names a SOCKS proxy, which is not supported, then went direct on its own. That message is generous, but if you’re relying on a proxy to install GitHub dependencies it won’t save you. That part is pnpm’s job.

Layer order, and the one rule that costs people the most

The effective config composes over an empty root in four layers, each later layer overriding earlier ones line by line:

1. the patch of each bundle in the profile’s dsh.profile.bundles list, in list order
2. the profile’s own cordis.patch.yml
3. the home-level $DSH_HOME/cordis.patch.yml, shared by all profiles
4. each --patch <path> overlay on the command line, in argv order

One rule deserves pulling out on its own: a patch replaces the target line’s entire config value rather than deep-merging keys. So when your patch overrides a line from an earlier layer, you have to restate every key that line needs. Writing just the one you changed wipes the others.

The good news in the other direction: users can override your line in their own profile’s cordis.patch.yml without touching your package. So make defaults the kind users will most likely keep.

Let the plugin take config

Config doesn’t come from the command line. You export a Config type plus a Schemastery schema of the same name, with defaults written into the schema:

export const Config: Schema<Config> = Schema.object({
  greeting: Schema.string().default('Hello'),
  maxRetries: Schema.number().default(3),
})

On load, Cordis validates the config against the schema and fills in defaults. Invalid config fails the load, with a clear error.

The convention here is house style: any parameter that could take a different value in a different deployment must be a config field. The test is one sentence — can you change it in cordis.yml without touching code. Changing config also triggers hot replacement of the plugin, and the old instance’s registrations get cleaned up automatically, because registrations are effects.

From printing a line to doing real work

Printing a line only proves the chain is connected. The three useful categories are: adding tools for the model, adding cards to the UI, and adding capability to the host.

Adding a tool for the model is a dozen lines in the official tutorial. The key is an inject declaration saying you depend on the tool registry, then registering a defineTool:

export const inject = ['tools']

export function apply(ctx: Context) {
  ctx.tools.register(defineTool({
    name: 'greet',
    description: 'Greet someone by name.',
    parameters: { name: { type: 'string', required: true } },
    async execute(args) { return `Hello, ${args.name}!` }
  }))
}

Those three new plugins show heavier approaches. crypto-ticker is a pure front-end card, zero dependencies and no API key, with data sources falling back in order across OKX, Binance and CoinGecko. busy-workspace splits into host and client halves: the host holds a single settings record and exposes its own JSON route, and the client reads it once on mount, falling back to defaults if that fails — meaning a composition with only the client still works. router-laya goes further: besides a 40-something KB index.js, it ships a Python service directory containing a locally fine-tuned ModernBERT classifier whose job is deciding which thinking level to use.

Those three shapes make one thing clear. The hooks a plugin can attach to are not limited to “give the model a tool”. Front-end cards, host routes, even a sidecar service are all in range.

Two failure behaviors I measured

The official Cordis tutorial says a failed plugin load reports a clear error rather than silently skipping the config entry. For “module cannot be resolved” (a typo’d path or package name) it adds an exception: that case is only reported through the logger and does not crash the process.

I tried that twice and got something different from the docs.

Make apply throw, and the process does crash, and crashes clearly, naming the plugin entry on the first line:

Error: dsh: plugin tree failed to load: failed to apply loader entry hello (dsh-hello-plugin): apply exploded

Change the package name in the patch to dsh-hello-pluginX and the process exits the same way, code 1:

Error: dsh: plugin tree failed to load: failed to import loader entry hello (dsh-hello-pluginX): Cannot find package 'dsh-hello-pluginX' imported from /tmp/dsh-home-test/profiles/demo/

So at least on dsh’s startup path, a wrong package name is fatal, not “log a line and keep going”. That’s good news for plugin authors: a typo blows up in your face immediately. The doc’s exception describes Cordis’s general behavior, and the gap between the two is worth noting. When a config entry seems to do nothing, first work out which kind of failure you’re looking at.

Shipping it to other people

The docs give three ways for others to install your plugin, at quite different costs.

Publishing to npm is the least work — dsh plugin add your-package installs the compiled artifact. Handing over a tarball is next: pnpm pack, then have the user install the .tgz.

Installing straight from GitHub is the most convenient and the most likely to break. A git install pulls source, not build output, and nothing runs your build, so a TypeScript package arrives without lib/ and fails to load. The author has to provide a self-contained prepare script in package.json, and the user has to explicitly allow pnpm to run it (since pnpm 10, build scripts of git dependencies are refused by default) by adding the package key to the profile’s pnpm-workspace.yaml. The docs put it heavily: that amounts to letting this package’s code execute on your machine at install time.

Networks in China add one more layer. pnpm resolves github: dependencies with git ls-remote, HTTPS only, ignoring the system proxy, so a direct connection often times out. crypto-ticker’s README offers a workaround that actually works: swap in the codeload tarball URL so git is never involved:

dsh plugin --profile web add https://codeload.github.com/<owner>/<repo>/tar.gz/refs/heads/main

Last

If a plugin list growing by three in one night is what got you interested, the minimum viable path is three steps: make a directory and drop in those three files, install with dsh plugin --profile <your-profile> add ./your-plugin-dir, then confirm the layer shows up with --dump-config.

My first successful run took about twenty minutes, half of it on one path.

What do you want to hang off dsh? A tool for the model, or a card in the sidebar like crypto-ticker? Tell me in the comments — maybe the next post is that.

References:

• dsh plugin development tutorial (packaging and installing): https://github.com/deepseek-ai/deepseek-harness/blob/main/docs/user/develop/basic/publish.zh.md
• Writing a tool plugin from scratch: https://github.com/deepseek-ai/deepseek-harness/blob/main/docs/user/develop/basic/tool.zh.md
• Cordis tutorial chapter one: https://github.com/deepseek-ai/deepseek-harness/blob/main/docs/cordis-tutorial/01-first-plugin.zh.md
• Plugin registry awesome-dsh-plugin: https://github.com/awesome-dsh-plugin/awesome-dsh-plugin
• dsh v0.2.0-rc.1: https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.2.0-rc.1

Verification boundary: the three plugin files, the install command, the --dump-config layer output, the startup log and both failure behaviors were all actually run on dsh 0.1.6-alpha.2 here (isolated with DSH_HOME=/tmp/dsh-home-test, the user’s running instance untouched). Official doc quotes are verbatim from the repo. The router-laya classification service details come from its plugin registry entry; I did not deploy it.

A user edits a checklist on the subway: adds two levels, renames one of them, deletes the one they do not want. The whole thing happens offline and only uploads once they are back above ground.

You want that to land on the server as one transaction. But if the client tracks sync state per row, that single save gets split into several independent requests, and if any one of them fails you are left with half-written data in the account.

premi jit chowdhury, the author of Nitivakya, wrote this rework up recently. The app uses KMP + SQLDelight + Supabase and started out as a daily ancient quote, living happily on a localState field (DIRTY / SYNCED / DELETED) on a single favoriteEntity. Then he added Actions, and the structure became a nested tree: Action to Action Levels to Action Level Items.

A row-level flag tracks final row state, not multi-entity mutation intent.

His words: a row-level flag records the final state of that row, not the intent of a multi-entity change. That sentence is where the rework starts.

Three specific collapses

He lists three failures in the post. I will quote them first, then unpack.

2 separate table REST calls caused foreign-key 500 errors over shaky connections. Full-snapshot uploads risked overwriting server-calculated streak progress. Row-level flags couldn’t express a simultaneous “Create Level A + Update Level B + Delete Level C” edit.

Child rows arrive before parent rows, the server returns a foreign key constraint error, and the child rows stay stuck in DIRTY forever. Route around the split requests with a whole-tree snapshot upload and you overwrite the streak count the server computes itself. The third is the hardest to dodge: creates, updates and deletes mixed into one save gesture cannot be expressed by a row flag at all.

The judgment I agree with is this — the problem is not that the flag holds the wrong value, it is that row granularity cannot carry what actually happened in this edit.

His new architecture: local state for the UI, an outbox for uploads

The result separates two layers. Local entity tables keep localState, now used only by Compose to render a status dot. Sync moves to a single aggregate outbox table holding sparse JSON DTOs with only the fields that actually changed.

CREATE TABLE syncQueueEntity (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  userId TEXT NOT NULL,
  type TEXT NOT NULL,
  operation TEXT NOT NULL,
  entityId TEXT NOT NULL,
  status TEXT NOT NULL DEFAULT 'PENDING',
  createdAt INTEGER NOT NULL,
  payload TEXT,
  UNIQUE(userId, type, entityId)
);

That unique constraint is the point: multiple edits to the same entity collapse into one row. On the Kotlin side, withSync does three things inside one database transaction: performs the local write, deep-merges the new payload into the existing payload in the queue, and removes the queue row outright when it sees a create followed by a delete.

Enqueueing uses ON CONFLICT with a state machine guard so an offline create is not mislabeled as an update:

INSERT INTO syncQueueEntity (userId, type, operation, entityId, createdAt, payload)
VALUES (?, ?, ?, ?, ?, ?)
ON CONFLICT(userId, type, entityId) DO UPDATE SET
  operation = CASE
      WHEN syncQueueEntity.operation = 'INSERT' AND excluded.operation = 'UPDATE' THEN 'INSERT'
      ELSE excluded.operation
  END,
  status = 'PENDING',
  createdAt = syncQueueEntity.createdAt,
  payload = excluded.payload;