Next Token · Blog

Giving an ESP32 a talking personal assistant

Fri, 09 Oct 2026 16:00:00 GMT

An ESP32 dev board costing a few dozen yuan, with a screen, microphone, speaker and gyroscope, is electronic Lego for hardware hobbyists. In the past, whatever you built with one mostly stayed a toy: AI could write firmware, but it wasn’t familiar enough with this kind of hardware, so what it produced had many problems and wasn’t pleasant to use.

The change came once the platform started taking this board seriously. When off-the-shelf firmware, an editable interface, and a hastily assembled voice pipeline all came together, the board went from a desk ornament to an assistant terminal that actually gets picked up and talked to every day.

From writing your own firmware to flashing and going

The turning point was general-purpose firmware. Muse provides firmware for common ESP32 devices in different hardware form factors: round screens and rectangular ones each get a matching version. Flash it in and there’s nothing to configure — it just works. Pairing is simplified to the level of a normal consumer product: enable developer mode in the phone app, tap the plus button, and it’s connected.

The details show how complete this firmware is: Chinese font packs are large, and in the past they were usually the first thing cut on memory-constrained small devices — this firmware ships with Chinese support out of the box. Problems that used to require workarounds now have answers in the stock solution.

One concrete desktop makeover

With a ready-made foundation in place, the work concentrates on the experience layer. One actual makeover involved the following:

The interface was switched to Chinese first, with the cramped UI relaid out. The default character was replaced too: the original was a 64×64 dot-matrix sprite that had to be drawn stroke by stroke in code; this time, a model generated a few images that were turned into frame sequences packed into the firmware and played back — something like stop-motion animation, with the device showing a different animation depending on what it’s doing. Going from dot matrix to image sequences made the character on the little screen dramatically more alive.

The genuinely missing piece was voice output. The firmware supports voice input only, so replies could only be read as text — and Chinese text is a real strain on a small screen. The firmware offers no speech service, so the fix was to take an API key for a text-to-speech service and route the device’s return data through a Mac on the same Wi-Fi: the device sends the text to synthesize to the Mac, the Mac forwards it to the speech service, and the audio comes back the same way and plays. This pipeline was rigged up temporarily, but it works — the device can talk now.

Why it started getting real use

Before the makeover, this kind of device was a toy you’d touch once and never pick up again; afterwards the pattern of use was completely different: lift it, say something, get an answer.

One typical use is checking on task status. Ask it why the material it was told to gather yesterday still hasn’t arrived, and it answers: the previous job is still running Memory optimization. Behind that exchange, the device itself does no computing — the heavy lifting runs on a cloud Agent, and the small device only handles input and output. Speaking is easier than typing, the screen and sound provide feedback, and the desktop device thus becomes a physical entrance and exit for a Personal Agent.

That is exactly where the value of small hardware lies. Hardware itself isn’t scarce — over the past year companies have turned out large numbers of small devices with similar form factors; what makes a piece of hardware useful is the platform and ecosystem behind it. Only once it’s connected to an Agent does it have a purpose. The same logic can be pushed further: there’s a demo of an electric wheelchair with no brain of its own given a slice of local compute, after which the wheelchair could move on its own — compute and models can directly become the “brain” of anything.

The division of labor is shifting

General-purpose firmware also changes the situation for hardware makers. A device vendor doesn’t have to build its own Agent: once the firmware is open, hardware can plug directly into the Personal Agent ecosystems of the big platforms and act as their “physical add-on” — both an entrance for input and an exit for output. Hardware startups are already considering this direction: rather than building an Agent nobody can use, be the bridge, and do it well.

For individual hobbyists, the lowered barrier is just as visible. Modify the firmware for a dev board, publish it to GitHub for others to download and flash — distribution is simpler than for a phone app. The skills needed to customize a desktop device are sliding from “knows embedded development” to “knows how to use an Agent.”

Whole-home takeover is a vision, not the current state

Push the “physical add-on” idea outward and you reach household-scale imagination: within this kind of firmware ecosystem there are products that can serve as Mesh gateways, so in theory a single ESP32 device could become the access point for whole-home intelligence — taking over cameras and all kinds of sensors, learning when the air conditioning should come on and when you feel hot, even broadcasting proactively through the speakers at home. Measured against the smart-speaker era’s satisfaction of “turn off the light, turn on the AC,” the jobs an Agent could take over might be ten or a hundred times more complex.

Two things must be kept apart here. The desktop-scale makeover is done, and it has survived a period of real use; whole-home takeover is a vision, separated from reality by device compatibility, gateway capability, firmware permissions, and the actual performance of the speech service — and none of it counts until verified on your own hardware. This article isn’t a shopping guide either: which board pairs with which firmware, how permissions should be granted, whether you need to wire up your own audio output — all of it varies by device model and can only be settled by testing.

What’s been verified and what hasn’t been walked yet

In this board’s story, what’s verified is the desktop scale: speech goes in, an answer comes out, and task status can be checked along the way. The bigger vision sits at the scale of the house, and there the first step hasn’t even been completed. The leap from toy to assistant terminal shows that in the Agent era, what small hardware lacks isn’t compute, and isn’t ideas — it’s a platform willing to get the firmware right. The rest has to be worked out through one concrete makeover at a time.

Sources

From Collecting Personal Data to Reviewing It on a Schedule

Fri, 09 Oct 2026 16:00:00 GMT

Smart watches, voice recorders, and all kinds of apps record on our behalf every day: heart rate, workouts, conversations, sleep. But most records just lie there. The value of a record is not in “it was saved”; it is in someone — or some program — going back to look at it at a fixed moment, comparing it with the last one, noticing change. Between collecting and reviewing stands the design of the whole loop.

The barrier to recording is falling

Recording used to be an active act: to capture something, you took out a device, pressed a button, and organized it afterward. Sensors have turned much of recording into a by-product. Devices like the Apple Watch collect heart rate and other data continuously, with no action required; audio is the same — with recording on the watch, “capture a clip anytime” no longer depends on a dedicated voice recorder or recording card. Earlier criticisms of watch recording apps’ sound quality were taken, in these discussions, to be resolvable by local transcription and AI noise reduction — audio quality is no longer a reason to reject this way of recording.

Two things call for a clear head. First, a recording captures not only yourself but also everyone present; recording without consent should not become the default just because technology has made it easy. Second, a device’s actual behavior on privacy and transcription is a product promise that needs to be verified item by item — the words “processed locally” are not grounds for assuming safety.

From archive to weekly report

Once records accumulate, the bottleneck shifts to organizing. One practice actually in operation works like this: strength training has a written record for every session — the coach does the logging, and once the tool became agent-driven, the results can be pulled directly; cardio data is on the watch, with expenditure recorded as well. A scheduled task in ChatGPT Work compiles all of this weekly into a report, keeping an eye on whether the few metrics you care about have changed.

A similar mechanism goes further: every morning, health data is synced on a schedule and written back into one’s own Memory, together with the strength training records; on top of that, scheduled tasks are arranged to analyze the data and generate visualization charts. Recording is automatic, and review is on a schedule — only when both are fixed in place does the loop close. Without the review link, records are just logs taking up space.

What review can find

The value of a weekly report lies in comparison. One personal experience, as told: for a long time the headaches were assumed to come from rhinitis; looking back through the records showed the headaches correlated with long hours of sitting, not with the nose. Such a discovery depends precisely on data that has “accumulated over a period of time and been looked at regularly” — a single checkup cannot see the everyday, and the person cannot feel the slow-moving causation.

A boundary has to be drawn: this is an individual pattern found through record review, not a diagnosis. What it suggests is that “some patterns of discomfort can be seen in your own data”; the next step is still to go to the hospital and let a doctor reach the conclusion. The person telling this story also pointed out another reality: doctors do not have time to go through one person’s full everyday data, and the state of “not sick, just unwell” usually falls outside what the medical system covers. Regular review of everyday data fills exactly this gap — this is personal experience, and whether it holds up in general varies from person to person.

What to keep, and whether you can take it with you

Designing the loop also means answering: what does each layer of recording keep? One detail of watch recording is worth noting: it provides a summary but keeps no original text. Summaries are convenient for looking back, but with the original gone, some questions can never be asked again — “was it actually said that way, or is this the transcription’s understanding?” only the original can answer. How far recording, transcription, and summary are each preserved decides which future questions this record can still support.

The other question is ownership. Glucometer data can be exported; health data can be written back into one’s own Memory on a schedule — exportability means the records follow the person, and switching tools or services never means starting from zero. Conversely, records locked inside a single service become a dead archive the moment the service changes. Data authorization needs a line of its own too: which data you are willing to let programs collect automatically, and to what extent, is worth thinking through before the recording starts. “The ones that cannot cause trouble” is itself a personally drawn boundary.

The loop thus breaks into three things: recording that is effortless enough not to require willpower to sustain; review with a fixed rhythm and fixed metrics, rather than a glance when the mood strikes; and data owned by yourself, portable. With all three in place, collected data becomes usable context — miss any one of them, and it is only accumulation.

Sources

The limits on mobile Agents go beyond compute

Fri, 09 Oct 2026 16:00:00 GMT

A flagship phone can run big games smoothly, and the gap with computers shrinks year by year. But put an Agent to work on a phone and the picture is completely different: it can’t execute a single command, can’t touch files, can’t call tools. Compute keeps rising; operability hasn’t followed.

What lets Agents work on a computer

An Agent’s capabilities on the desktop rest on decades of accumulated infrastructure: the file system, the command line, FFmpeg, Git, Bash. One concrete scenario: a brand-new Linux distro has been installed, networking isn’t configured, and the various config files offer no way in — after installing ZCode, everything is handed over to it. Some systems even ship a dedicated command-line tool that delineates for the Agent what may and may not be changed; if the UI crashes or the screen goes black, the Agent can repair itself.

The toolchain also extends the output beyond code. The soundtrack for a promo video can be written in Python and MIDI, following the rhythm of the video so you can’t tell it was generated by a program; with tools like Blender, 3D modeling and rendering live in the same executable world. These capabilities share one precondition: the Agent can execute things within the system.

The sandbox blocks the same capabilities

None of this runs on a phone. Node and the usual scaffolding and component tools won’t run inside the app sandboxes of iOS and Android; debugging channels like Android’s ADB have also been locked down more and more in recent years. The result: on a phone with compute to spare, an Agent can access nothing — having an on-device model alone is useless, because the model is local while its hands and feet are tied.

One specific bug shows how small the gap can be. A small app built to replace a fitness app — recording rides and announcing kilometers covered — took half a day to a day to develop on the computer, but only in testing on the phone did it turn out the location permission had never been requested, and the entire recorded ride read zero speed. The problem wasn’t compute, and it wasn’t hard to fix — with on-device debugging, it would be one line adding a permission request. The hard part isn’t technical; it’s that the phone leaves developers no place to do it.

The same contrast shows up in interaction. Voice-driven computer use is becoming more common, and real-time speech models are being released in rapid succession; on the phone, though, this kind of interaction is largely confined within individual apps — the OS offers no deeper entry point, so no amount of voice capability gets anywhere beyond the app it lives in.

Context, too, stays on the computer side

Beyond execution capability, context also tilts toward the computer. A personal Memory can simply be the file system and documents — mount your own storage and it syncs automatically, no third-party service required; multimodal images and video have somewhere to live. On a phone, information is locked inside individual apps; even downloading a file from the cloud, just finding it afterwards is a struggle.

So the practical division of labor becomes: put the execution environment on a computer or a machine you control. One person loaded several purchased Coding Plans into a virtual machine on a Raspberry Pi, letting the Agents schedule themselves and cover for each other; scheduled jobs, information triage, and PR reviews all run on that little machine. In this round of division of labor, the phone is mostly the end that gives orders, not the end that does the work.

The box the system draws, and the gaps in it

Under these constraints, today’s viable paths all stay within what the system allows, each with its cost:

Cloud execution is the natural choice for offloading heavy work — it saves battery and local resources — but the parts that need to interact with on-device information always remain on the phone, and that is precisely the hardest part.

Vendors’ own channels are the privileged path. Phone makers can use system-level capabilities to connect a phone’s assistant to a computer, operate across devices, even read favorites and photos inside apps. This is an in-system channel; ordinary developers can’t get equivalent access.

Removing system protections would indeed open more up, but the cost is clear: after rooting or unlocking, apps can detect it, and banking apps simply stop working; the debugging interfaces under developer mode are more loosely guarded, but that is just the current state, not a generalizable solution. Treating “unlocking” as a universal fix leaves the risk on the user alone.

The community is also probing the gaps the system leaves. One direction borrows the browser component built into iOS — it is a system component with broader permissions than ordinary apps — to run Node.js and the command line; another compiles and renders a UI locally straight from a .swift file: the AI writes a file, you confirm, and the app runs. Both of these claims currently exist only at the level of demos and discussion; whether the libraries can pass app review, and how stable they are, still need engineering verification. What makes them worth mentioning is that they name the nature of the problem: the restriction comes from system policy, not from technical impossibility.

Compute is in place; the environment isn’t

In the Agent era, the gap between phone and computer is no longer about the chip. Files, commands, the permission model — the things that let an Agent work — the phone either lacks or withholds. A cycling app’s bug shows the gap can be as small as one permission request; the vendor channel shows the key is held by the system; the community libraries show gaps exist but remain unverified. Compute is in place; the open question is when the software environment catches up — that is what decides whether the phone is the Agent’s remote control, or its workstation.

Sources

Building Trust Through Ongoing Work

Fri, 09 Oct 2026 16:00:00 GMT

A widely shared joke captures the current moment: with AI, the clerical work of producing documents has gotten easier, while the programmers who write code have gotten more exhausted. Behind the joke sits a more serious question — when execution-level work is heavily automated, what can people still provide?

The answer will not be found in “output.” Generating an article, an interface, a video now costs close to nothing, and the supply of homogeneous content will only keep growing. In an environment of supply overload, what is truly scarce is something else: someone who will keep finding you, recognizing you, and trusting that what you hand over next time is still worth their attention. That is trust — and it is not earned through a single viral hit.

A personality has to be recognizable

In an era when everyone can produce, distinctiveness comes from preferences. Whether one’s taste is good or bad is debatable, but the preference itself is the difference: given the same topic, different people will make entirely different things, and some of those preferences happen to match what a portion of the audience needs.

The key is that these preferences must be perceptible from the outside. Taste and personality — without judging either for better or worse — need to come through in what you say, what you publish, and what you build, changing over time while staying consistent. Consistent does not mean frozen: opinions can evolve and style can mature, but viewed over the long run it should still be the same person, not a voice drifting with whatever is trending. This is why “a human touch” keeps getting stressed: content without a human touch is not in short supply; what is missing is a person who can be recognized.

Consistency is valuable because it lowers other people’s cost of judgment. A reader does not need to re-evaluate an unfamiliar piece of output every time — they only need to confirm “still the same flavor.” Common wisdom from outside about the creator economy supports this too: you do not need to please everyone; if you can sustain a small audience that deeply endorses you, your creative work can keep going. This is exactly the dividing line between ongoing works and short-term traffic-driving — the latter maximizes a single touch, while works accumulate trust that can be drawn on again and again.

“Work” here does not have to mean software in the narrow sense. An article, a podcast, an Obsidian plugin — any of these can play the role. Some works clear a remarkably low bar to get listed, and soon after launch they gather an active user base, with the positive feedback coming from discussions and usage reports between real people. Feedback like that carries weight that a plain like-count cannot match, because it means people are actually fitting the work into their own lives.

Trust is a bet, not a law

One claim deserves caution: that trust is the thing technological progress will not swallow. It is a bet, not a law.

Technology is changing the cost structure of trust too. Machine-generated content reads more and more like something a human wrote, and comment sections are hardly short of voices engineered to compete for attention. As the bar for faking “being present” drops, merely looking human is no longer proof of trust — and by the same token, a handwritten touch here and there, or a typo, is not evidence of authenticity either. What can carry trust is what is hard to fake in one shot: a long track record of output, products that survive use, sustained interaction between real people.

Put the three together: works provide a record that can be examined, consistent preferences provide a recognizable continuity, and feedback from real users provides external confirmation. Trust comes from the overlap of the three; remove any one layer and the whole thing collapses easily.

What can be copied, and what cannot be taken away

The games industry offers an extreme test case. When a console game is fully rewritten to run on another platform, and when remakes advance on a timescale of weeks, the pay-once business model takes the most direct hit. By contrast, services built around accounts, characters, and ongoing operations are affected in a completely different way: a remake can carry off the program and the data, but not the relationships players have built up with their characters.

This observation comes from the games industry and cannot be extended directly to every field, but the mechanism it reveals is worth remembering: the easier something is to copy, the harder it is for it to form a moat; relationships, shared consensus, and continuous service are far harder to replicate. For individual creators, that mechanism points in the same direction — put the effort into the parts that are hard to copy, namely the ongoing work and its connection with the audience.

There is no shortcut to accumulating trust, and no finish line. It is made up of works, batch after batch; each one leaves a record, and every careless one can leave a stain too. As for how to prove your continued presence to a new audience in an environment where machines are getting ever better at imitating humans — that question has no answer yet, and it may itself be the theme of the next batch of works.

Sources

Turning a TV remote into a voice entry point for your computer

Fri, 09 Oct 2026 16:00:00 GMT

A TV remote already has buttons and a microphone; “hold to talk” is something it knows how to do out of the box. Hook it up to a computer — could it work as a voice entry point? The answer from a recent experiment: yes, but the missing piece of software in the middle has to be built yourself.

The hardware is ready-made

The experiment used the second-generation Pro of the Xiaomi Bluetooth remote. It has a sandblasted aluminum shell, a button layout identical to the Apple TV remote, hold-to-talk, Bluetooth, USB charging, and battery drain measured in days. At the time of recording, the official price was 99 yuan and 89 yuan online, with the first generation cheaper; dedicated AI voice hardware sold around the same time for two to three hundred yuan, with plastic shells, poorly reviewed software, and, in some cases, a USB port taken up. The model, price, and battery life are all specific to the time of recording — the point here is the experience, not a recommendation of any particular product.

What’s actually notable is the niche: the vendor’s attention is on models and the AI ecosystem, and it hasn’t treated its own Bluetooth remote as a computer peripheral — no desktop voice input software exists for it. That empty slot is exactly where ordinary users could get real use out of it.

What’s missing is a piece of software

Getting the remote connected to the computer is just the start. To turn it into a voice input tool there are two routes: find an existing driver online, or write one to your own requirements. This experiment chose the latter — during the October Golden Week holiday, a voice input program was developed with Codex, tailored to personal habits, and put straight into use once written.

There is nothing technically novel about this: Bluetooth remotes are mass-produced hardware, speech recognition is a mature capability, and writing an input program is not hard for today’s Agents. What’s new is how it feels once the pieces are joined together.

Two days of all-voice work

Once the program was in place, two full days were spent at the computer working on projects with input almost entirely by holding the remote and talking. On the third day, needing the keyboard for something temporary, something unexpected happened: the shortcut for switching input methods wouldn’t come to mind — an unfamiliar sense of “I’ve forgotten how to type.”

That was a single experience, not a conclusion. Two days prove nothing about any long-term change; they only show that input habits form faster than expected — the body’s adaptation to “speaking to type” may run deeper than you’d assume. As for what a long-term switch of input methods would look like, the material offers no answer, and there’s no need to rush to judgment.

What the button and the screen each take care of

The most concrete part of this experience was the sense of control: with a keyboard, it feels like using a tool; holding the remote and talking, it feels like giving orders — tell it to do something, and it does it. The physical button provides a clear start and end: press to speak, release to stop, with no need to hunt for a microphone button on screen. For a way of using an Agent centered on conversation, this “entry point held in the hand” has more presence than any button in an interface.

The other half of the experience is on the screen. If voice input can’t show what’s being said in real time — two or three minutes of talking with nothing to see, the content arriving in one dump — the experience is noticeably worse; that’s why another voice tool got installed and promptly uninstalled. The remote solves the entry point for “speaking,” and screen feedback solves the “knowing it’s working while you speak.” Both are indispensable: the physical entry point issues the command; the screen confirms the command was heard.

Who will fill the niche

No part of this combo is new; what’s new is how the combination feels to use. If the vendor ever sold this remote as a standalone product with an official driver to go with it, that empty niche might not stay empty for long. Until then, the precondition of this path is writing the missing software yourself — which is exactly why it currently reads as an experiment worth recording, not a tutorial to follow.

Sources

When Is It Worth Replacing Frontier Models with Your Own Smaller Model?

Fri, 09 Oct 2026 16:00:00 GMT

Whenever a company announces that it has replaced frontier models with open-source ones at a fraction of the cost, the comments always fill with “shouldn’t other companies do the same?” The judgment at recording time was clear: this decision is not the starting point of a technology choice but the outcome of business maturity. Get the order backwards, and the money saved on models will not come close to covering the quality you lose.

Earn the right to talk about replacing first

The precondition for replacing a model is a stable business loop: the product has found its market, the revenue process works, and the whole chain still holds after the swap. Only companies that have reached this state can talk about “cutting costs” — because before replacing, they can already answer independently what “good enough quality” means. The vast majority of companies have not even found product-market fit yet; at that stage the right choice is to use capability to the fullest, not to save money.

News can easily create an illusion: one leading company switched models, and it looks like the next step for everyone. The ones actually able to take that step are the few who have already validated their business on frontier models and polished their pipelines. For most teams, the fear of “being killed by competitors if we don’t use the latest model” is closer to reality than the fear of “an overly expensive model dragging down gross margin.”

What a relayed case actually shows

The case cited repeatedly in the discussion, by the relayer’s account: an enterprise services company in the legal industry early on paid model vendors more than every dollar of revenue it took in; later it trained its own model based on an open-source LLM, and its gross margin turned positive. The revenue and cost figures have not been independently verified, but the mechanics of the case are worth unpacking: the replacement happened when model spending had grown large enough to affect gross margin, when the tasks were stable enough to evaluate systematically, and when the vertical was closed enough and the data proprietary enough. Only when all three conditions hold at once is replacing rational.

“Good enough” must be defined by metrics from within the scenario

The claim “switching to a small model makes little difference” needs a follow-up question first: verified by what metrics, at which steps of the process. Another example relayed at recording time: a product lead claimed that in their scenario, a small model matched the frontier model’s engagement rate. Engagement rate is a real business metric, but it is an aggregate — an identical overall engagement rate does not mean every step is equally reliable; the quality distribution across summarization, judgment, and execution can still vary widely.

Being able to run this kind of verification is itself a qualification. Only teams with real usage data that can run head-to-head tests of old and new models have grounds to conclude anything; teams without a data loop cannot even prove “about the same.” So the sensible order is: define the product’s requirements and quality standards first, build independent evaluation, and then let the replacement decision be made by the evaluation results — not directly by cost pressure.

Vertical and closed scenarios are where replacement holds up more easily

The company in the case operates in the legal industry — high barriers, closed processes, clear accountability. Similar structures appear in fields like medical services for doctors and architectural design: proprietary data, costly errors, customers paying for outcomes rather than for models. In these scenarios the model is just one factor of production; swapping it does not change the product’s foundation.

Conversely, in everyday, general-purpose scenarios — verticals like video generation that everyone can enter — barriers are thin to begin with and product value hugs model capability closely, so the freedom to swap models is actually smaller: the model is the product’s power itself. Figuring out which situation you are in matters more than studying how others switched.

At recording time, one complementary product direction also came up: since model capability is a black box to most users, a product can absorb the model choice, giving users an automatic mode while the product side handles scheduling and quality. Removing the model list from the interface and taking the choice back onto the product side is itself an expression of “the moat is in the product.” It also hides a way to test your moat: if the business still stands after swapping out the frontier model, the moat lives in the product, the data, and the process; if it collapses the moment you swap, the moat you were proud of was actually rented from a model.

Timing is also a cost question

The returns to replacement change over time. Inference costs are trending down overall while the compute hardware needed to run agents is getting more expensive; between the falling and the rising, the build-and-train math has to be recalculated again and again. On the hardware side there is also an old regularity cited in the discussion: as availability rises, usage grows — efficiency gains do not reduce total compute demand. Free products sustaining huge volumes of everyday interactions show that small models can already handle many ordinary tasks; but “can handle ordinary tasks” and “can handle your core task” are two different things.

The moment when replacing frontier models with your own smaller model is worth doing — and can be done successfully — is when the business is stable, the metrics are defined, the data is in hand, and the vertical is deep enough. Miss any one of the four, and the more rational choice is still to keep using the strongest model and spend the energy on product hypotheses not yet validated. Replacement is the result of capability being verified, not the starting point of saving money.

Sources

Agent Plugin Migration Is Hard Because Capabilities Are Unequal

Thu, 08 Oct 2026 16:00:00 GMT

A smooth plugin migration looks like this: a batch of Obsidian plugins is moved into the DeepSeek Harness, with the agent itself judging which features have nothing to do with note-taking and dropping them—completed in a single pass with almost no human intervention. That migration worked on one premise: the capabilities these plugins relied on happened to all be present in the target host. Try a different batch of plugins or a different host, and the outcome may not be the same.

The difficulty of plugin migration is therefore not in the moving, but in what is left once the move is done.

Consensus at the Standards Layer, Fragmentation at the Implementation Layer

What the agent plugin ecosystem broadly agrees on is really only the standards layer: MCP specifies how tools plug in, while AGENTS.md and Agent Skills specify how instructions and skills are written. Above that, each platform’s plugin system is its own thing: Codex plugins can be pinned to the sidebar and interact back and forth with the user; Claude Code has Mods; Pi has Codemode; DeepSeek Harness has its own plugin system. The same feature, dropped into a different host, becomes a different format and a different interface.

This shows an ecosystem splitting by audience: Personal Agents aimed at ordinary users keep getting simpler, while agents aimed at productivity keep expanding their plugin systems and gaining freedom. Plugins, as an important extension mechanism for the latter, naturally grow in each platform’s own soil.

The Threshold Is Which Capabilities the Host Exposes

The real test of a migration is capability parity. One host supports a given capability; another does not support it at all—migrate over and the feature is crippled. This inequality appears at multiple levels:

At the interface layer, GUI-based plugins are the most fragile: the host moves its interface and the plugin breaks, so many adaptations simply give up on the interface and build against more stable exposure surfaces like MCP or the CLI. More fundamental execution capabilities—whether the host provides code execution, and whether it persists—determine whether a plugin arrives as a full-featured port or an empty shell. Fine-grained features are just as uneven: capabilities like multi-account connectors currently exist on only some platforms. Nor do the differences necessarily come from technical limits—often the host simply has not built it: the part of a plugin that depends on local execution cannot land in a host that provides no runtime environment.

When evaluating a migration, it is worth listing the capability inventory first: which interfaces the target host exposes and which file and execution capabilities it supports, and only then deciding which plugins are worth bringing along. If the checklists do not line up, the best format conversion in the world is meaningless.

With an Unstable Upstream, Migration Is Never One-and-Done

Even if the migration succeeds this time, a single upstream update can void it. DeepSeek Harness updates frequently, and previously installed plugins mostly break; one plugin author has said outright that their library no longer updates because they cannot keep up with upstream. Part of the problem is design: the plugin system offloads complexity onto developers, and paired with rapid iteration, compatibility becomes a continuous cost rather than a one-time investment.

The standards layer demands multi-track maintenance too: keeping a CLAUDE.md alongside the AGENTS.md and updating both together; and Agent Skills still lacks support on some hosts. The maintenance burden lands directly on every developer who wants to go cross-platform.

Migration Costs Are Falling; Capability Differences Will Not Disappear

Model capability is making the “moving” itself ever cheaper. A concrete case is a Markdown editor swapping kernels: migrating from Milkdown to CodeMirror 6, with the goal of making the rendered output and the source a single source of truth rather than two states that have to be kept in sync. By the developer’s estimate, that work would originally have been measured in weeks; handed to a model, one pass produced a usable result, needing only some leftover bugs fixed. Obsidian plugin migration can even be handed over to the agent to judge and execute in its entirety.

But this solves the question of how to move, not the question of whether anything is left after the move—capability differences are decided by the hosts’ product design, and they will not vanish because conversion tools get stronger.

A Ready-Made Distribution Ecosystem

For an individual developer who wants to distribute plugins, Obsidian shows there is an opportunity outside the official agent ecosystems: the listing process is simple, community plugins are distributed as open source, and the user community is active. One developer’s Obsidian plugin drew more than two thousand downloads in two weeks, with feedback in the user group that was direct and specific.

This opportunity has structural reasons behind it. Obsidian is a mature, listed application spanning desktop and mobile; attach a plugin to it, and you simultaneously inherit its user base, its data organization, and its distribution channels, without having to build an audience from zero. Some call it a “small operating system”—it ships with a complete distribution ecosystem, and developers just plug in.

This is one person’s experience, and the scale and speed may not be replicable for other plugins or platforms. But it shows that the entry points for plugin distribution are not limited to the official marketplaces of the various agents: a mature software ecosystem is itself a channel, especially when the plugin serves the everyday work of that ecosystem’s own users.

Sources

From Prescribing Steps to Aligning on Goals

Thu, 08 Oct 2026 16:00:00 GMT

While developing a save feature for an RSS reader, the requirement was to save articles as Markdown or PDF. After the feature was done, the model added a remark: users might not realize the article had already been saved—should this button become a “done” indicator? The requirement hadn’t changed, but the delivery gained a layer of consideration for the user’s situation. Moments like this put an old question back on the table: when collaborating with a model, exactly how much do you need to prescribe?

The End of the Line for Instruction Execution

The common pattern of collaborating with models used to be step-by-step prescription: do this first, then that, what format to use, what not to touch. The finer the prescription, the more two problems surface. First, writing out every step is nearly impossible—there will always be branches you didn’t anticipate. Second, the person making the request may not understand some of the steps themselves, and a layperson’s literal instruction can end up steering execution the wrong way.

Recent usage experience shows a change: models no longer blindly follow literal requests. They complete the requirement and then consider from a wider perspective what the design is ultimately meant to serve, and when necessary they say “this can’t be done that way.” The old people-pleasing, step-by-step execution often made collaboration feel clumsy; now it is more like offering a solution after understanding the intent.

Alignment Replaces the Step List

Reflected in daily usage, the focus of prompt writing has shifted. It used to be about guiding, agreeing on conventions, and strictly constraining every step; now it is mainly about alignment—making clear what you want to do, why, and what counts as good, without prescribing exactly how to do it.

This doesn’t mean prompts are useless; it means the position of two kinds of information has changed. The parts describing “how to do it” are fading in importance, while the parts describing “what to do” and “what counts as done well” matter more. Time saved from prescribing steps is best spent stating the goal itself clearly.

As Models Get Stronger, Weak Requirements Show Their Cracks Faster

Aligning on a goal presupposes that the goal itself is sound. From usage observations in the same period, there is a typical predicament: asking for too much while lacking a concept of what to build, burning through a subscription quota in a week, and still ending up with something that doesn’t meet the requirements. A model will not invent a clear goal on the user’s behalf; when the expression is muddled, the muddle gets amplified by execution too.

Professional judgment has not, therefore, been devalued. One user with development experience described another route: use a faster model to get a result that scores sixty or seventy out of a hundred, then rely on your own professional judgment to iteratively adjust it up to ninety-five, with total time actually shorter. Judgment and acceptance criteria still live with the people who understand the domain—the stronger the model gets, the more the definition of “good” is supplied by humans.

The Boundaries Are Still Drawn by People

Handing judgment to a model also requires spelling out the scope of that judgment. When a whole suite of Obsidian plugins was moved into a different runtime environment, the handoff was: judge which features are unrelated to note-taking, and decide on your own to remove them. The model carried out the pruning and the migration, but the scope of “related to note-taking” itself came from an understanding of the business—what gets delegated is judgment within execution, and the prerequisite for drawing boundaries is still the human’s understanding of the matter.

Steps Go Stale; Rules Don’t

Another signal comes from accumulated procedures. One user found that applying a video-production Skill prepared for an older model to a newer model actually made the results worse. This observation deserves to be recorded as a phenomenon, without rushing to infer a cause—why the model is affected internally cannot be verified from the outside. At the minimum, it is a reminder: operational steps written for a model’s capability gaps at the time may turn into constraints as the model grows stronger.

When accumulating instructions, it is worth distinguishing two kinds of content. One kind is “how to do it” operational steps; they are tied to the model’s capability level at the time, go stale, and need periodic cleanup. The other kind is stable business rules—terminology conventions, constraints, formats, acceptance criteria—which are worth writing down no matter how strong the model becomes. Deleting the latter along with the former by mistake, and enshrining the former as long-term rules, are the same mistake in opposite directions.

Moving from prescribed steps to aligned goals is not a matter of managing less, but of managing in a different place. The question still open is which constraints are worth writing down explicitly—there is no universal answer, only judgment made project by project.

Sources

An Attempt at Swapping a Markdown Editor's Kernel

Thu, 08 Oct 2026 16:00:00 GMT

A subtle problem hides inside WYSIWYG editors: what you see and what is actually stored in the file may not be the same data. One refactor that migrated a Markdown editor from the Milkdown kernel to CodeMirror 6 went straight at this root cause.

Two Copies of State, Countless Details

In the original kernel, the rendered content and the raw source were two separate sets of state. When you edited something, the UI could look updated while the source might not actually have been changed. This was not an isolated bug but a breeding ground for a whole class of problems: two representations need to stay in sync, and syncing brings questions of timing, granularity, and conflict handling—more details than you can count. Fix one, and another pops up.

The goal was therefore clear: make the source the single source of truth, with rendering derived from it. This is the route that mainstream editors like Typora have already proven. The most direct way to get there was to swap out the underlying kernel—continuing to patch the old architecture amounted to endlessly patching the gap between two copies of state.

The Model Proposed the Plan—and Estimated the Timeline

Even the plan for this refactor came from the model. The developer was not familiar with kernel selection; it was the model that proposed swapping kernels, listed the string of problems the swap would solve, and estimated the effort as “probably a week.” The developer repeatedly checked “can I actually hold this together?” and only started after getting affirmative answers. The model used was DeepSeek Flash as it stood at the time.

The one-week estimate was made on a human’s rhythm. The developer reminded it, “you’re an AI—one day should be about right,” whereupon the model wrote the bulk of the migration in a single pass. There were some bugs, but the skeleton took shape in one go. The gap between estimate and execution is itself evidence of a shift: what used to block this kind of refactor was mainly the file-by-file rewriting workload; once that part is compressed, what becomes truly scarce is judgment—whether to migrate, where to, and what counts as done.

“The Code Is Written” Does Not Mean the Migration Is Done

The step most easily skipped in a migration is acceptance testing. Code generated in one shot will have bugs; the editor feeling “fantastic” after the kernel swap and solving a pile of old problems is a usage-level impression. The editor’s quality ultimately has to be judged by long-term use and regression behavior: were the old editing behaviors preserved item by item, did the old Markdown pain points regress—nested structures, paste, undo, tables. This attempt did not demonstrate full test coverage, so the conclusion it can support is “the migration’s main body is complete and the experience has clearly improved,” not “kernel migrations are now easy.”

The same night’s discussion offered a useful point of comparison: before a game project swapped its implementation language, it first used unit tests to lock in the existing logic, which made the replacement “effortless.” Both cases point to the same thing—behavioral constraints and regression checks define whether a migration is complete better than “the rewrite is done” does. The deliverable of a migration is not just new code; it is also a body of evidence proving the old behavior wasn’t broken.

Where This Experience Applies

Another migration appeared in the same discussion: moving a whole suite of Obsidian plugins into a different runtime environment. The handoff approach was to let the model itself judge which features were unrelated to note-taking and drop them, completing the migration in one pass. Clearly, what a model can take on isn’t limited to mechanical rewriting—it also includes pruning judgment during a migration, provided the boundary of “what counts as relevant” is stated clearly.

The discussion also produced a more aggressive remark: that quite a few cross-platform technology stacks “no longer have a market.” That claim needs to be handled with care. One editor’s successful kernel swap shows that on this specific pain point—duplicated state—replacing the kernel beats continued patching; it cannot be generalized to all frameworks having lost their value. Whether a given framework is worth using depends on whether the problem it solves still exists in the current project, and on whether staying on the original architecture or migrating costs more—these have to be calculated per project, and one attempt cannot settle the question.

The initiation and execution of a migration can be handed to the model, but “what counts as done” is still defined by humans. That responsibility hasn’t disappeared now that execution is faster—if anything, faster execution makes it easier to overlook.

Sources

From an Old Game Script to a Playable Prototype

Thu, 08 Oct 2026 16:00:00 GMT

A game script and worldbuilding document sat on a hard drive for a year. Nothing followed after it was finished last year; this holiday it was handed to a model, and the very first version that ran was already playable.

Existing Lore Replaced Communication from Scratch

The starting point this time was not a vague idea but a finished script and setting document. The model read through the existing script and lore, started writing right away, and the first version had almost no obvious flaws—it was immediately playable, and all that followed was a few rounds of iteration.

What the script and lore did here was equivalent to a requirements document written in advance: the worldview, gameplay rules, and goals were already on paper, so the model didn’t have to guess what to build from a general wish. Between idea and playable there used to be a stretch of road—“translating the setting into development tasks”: breaking down features, setting priorities, spelling out how each system behaves. This time, that stretch was largely skipped.

The division of labor in later iterations is also worth recording: the human pointed out where performance tuning was needed and where the lore logic had to change, and the model expanded such a brief instruction into a full implementation. Requirements could be issued very briefly because the context was already complete inside the project—the script, the existing code, and every previous round of changes replaced the paragraphs of explanation that would otherwise have gone into a requirements document.

One description of the experience compared it to “a game company CTO with a multi-million salary finishing months of work in a few dozen minutes.” That is an experience-level analogy, not a verifiable benchmark; all it conveys is the subjective feeling brought by the iteration speed.

When the Performance Problem Showed Up

Once the prototype was running, the problem became performance. The initial implementation drew with Canvas; after a request to improve performance, the implementation was switched to PixiJS. During the tuning, the executor explained what it was doing as it went: where CPU time was going, how that related to the screen refresh rate, how the algorithmic path could be optimized, how many milliseconds could be won back.

This is a typical prototype path: first make the thing run, then optimize item by item against frame time and the critical path. “Playable” takes priority over “smooth,” and performance problems only earn the right to exist once something is playable—for a prototype meant to validate an idea, reversing the order means nothing gets validated.

The Fork in the Road After the Prototype

The next consideration was shipping on Steam and the App Store. Asked about this, the model recommended moving to the Godot Engine. Meanwhile, for a project already finished in some language and with enough unit tests to lock in its logic, replacing the implementation language was considered something that could be done with ease.

One thing has to be made clear: all of this remains at the stage of next-step ideas. As of when this attempt was recorded, the game is a playable experience prototype; it has not been listed on any platform yet, and no final technology stack for release has been decided.

“The Code Is Great” Is, for Now, Only a Rumor

There is another claim circulating about this attempt: the resulting code is of international standard. Here the levels of evidence must be distinguished. What came out is the functionality; the code itself has not been read. The alleged standard comes partly from the experience of using it—few defects, fast iteration, professional explanations—and partly from other people’s assessments of the model’s coding ability. A good product experience does not entail high code quality; to support a judgment like “the code is elegant,” someone actually has to read the code, and project-level evidence is needed.

Until that evidence arrives, what this attempt can confirm is: from an old script to a playable prototype, the implementation stretch has been compressed into a few conversations over a holiday. And the decisions about whether it is fun, whether it’s worth further investment, and whether to head toward Steam or some other direction—those remain in human hands.

It’s also worth remembering what the prototype validated and what it did not. What it proves is that lore written a year ago can become something that runs without obvious defects; it does not prove the game is fun, let alone that anyone will pay for it. Game feel, content depth, retention—those answers have to wait until more people have played. The prototype lowered the threshold for “getting it made”; the threshold for “making it worth it” hasn’t moved.

Sources

Making Software into Tools That Agents Can Actually Use

Thu, 08 Oct 2026 16:00:00 GMT

Building a 3D model with an agent can look nothing like what you would imagine: Blender’s interface sits utterly still, stuck on the welcome screen, while the agent beside it writes code continuously—it is using bpy, Blender’s built-in Python interface. After a while it announces the model is done; open the file, and there it is, complete. Across the whole process, the reliance on the graphical interface amounts to nothing more than opening the file at the end to confirm the result.

This case is worth unpacking carefully, because it shows what actually happens when software is genuinely “put to use by an agent”: the operations bypass the interface and go through the programming interfaces the software exposes; and the results can be inspected—only then does the loop actually close.

The Interface Is Not the Entry Point for Agents

Graphical interfaces are designed for humans, relying on visualization and immediate feedback to help people understand state. The more efficient path for an agent is to bypass that layer and call the interfaces directly. One fallback route is Computer Use: model vendors could not wait for software to be retrofitted one product at a time, so they trained models to operate human interfaces, making legacy software usable. Software proactively adapting itself is the other route, and the two are advancing in parallel. But as long as the software exposes an interface, driving the UI is merely a transitional form—behind every click there was always a callable capability.

Operating through interfaces also differs in efficiency. Modeling with bpy consumes almost none of the overhead of “looking at the interface”; token efficiency is high, and the number of intermediate MCP screenshot confirmations is small. Godot and other game engines have a similar structure: finish the work and open it to see the result—there is no “operating an interface” step in between.

This suggests a division of labor: let code handle the operating, and let the interface handle the viewing. Software can keep polishing its interactions to be human-friendly while building a separate layer of infrastructure for agent calling efficiency—two channels serving two classes of users, with no need for either to accommodate the other.

Capability Interfaces and Inspectable Results

The first criterion for whether software is usable by agents is which capability interfaces it exposes. Command-line tools have a natural advantage: in video editing workflows, Codex plus FFmpeg can cut footage directly—not because it operates the interface of some editing application, but because FFmpeg itself is a text interface. By contrast, graphical software that has not opened up an interface cannot be plugged into the same workflow, no matter how polished its UI. This has nothing to do with whether a piece of software is pleasant to use; it is purely a difference in how open the interfaces are.

The second criterion is that results can be inspected. An agent’s output has to be verifiable before a task loop closes: the model is built, so open the file to confirm; the layout is generated, so take a screenshot and compare. Inspectability determines whether an agent can correct itself, and it determines at which points a human needs to step in.

Bundling an Agent In and Opening Capabilities Up Are Two Different Things

Software embraces agents in two ways that are often conflated. The first is putting an agent into your software: a built-in assistant that improves the experience of your own product. Editing software shipping its own agent falls into this category. The second is opening the software’s capabilities so external agents can call them.

The difference shows up most clearly in closedness. One editing-software example: it has a Skill-like capability system, but at the time of that recording it could only be used inside the vendor’s own agent—external Codex could not call it. The capabilities exist; they are just locked inside the vendor’s ecosystem. The other approach is DaVinci Resolve splitting its capabilities into MCP, which any model can connect to; at the time it also placed MCP in the paid edition—openness itself became a paid feature, a sign that software vendors have begun treating “callable by agents” as a capability that can be priced.

The two approaches answer different questions: the built-in assistant serves the users of your own software; opening capabilities lets the software enter other people’s workflows. For users who work with multiple agents, it is the second that decides whether a piece of software can appear in their task chains at all.

The Host Also Has to Keep Up

Even when software opens up its capabilities, the host agent still needs an execution environment to receive them—a link in the chain that is also frequently missing. A counter-example from a vertical design agent: the connected model plainly has coding ability, yet the product actively restricts programming; a reference image for layout can be uploaded, and the agent can even see it sitting in the folder, but when it comes time to actually use it, it cannot—incomplete file system support. Even if the modeling software exposes bpy, a host like this has no way to use it. Ephemeral virtual machines add a persistence problem: every spin-up is a different environment, and context is hard to carry forward.

Software Becomes an Agent Plugin

Putting the two threads together yields a directional claim: the old pattern was software pulling agents in; the coming pattern is software turning itself into an agent plugin—no longer waiting for some built-in assistant, but making its own capabilities into tools that every agent can call. Product ideas already exist around this direction, such as a replacement for closed-ecosystem editing software built to support external agent calls. Whether the idea holds up depends on whether it can answer the three questions laid out above: are the capability interfaces complete, are the results inspectable, and can the host environment keep up.

Those three also make up a checklist for evaluating any software’s “agent usability.” Only when all three are met does software stop being merely an interface for humans and become a tool genuinely usable in agent workflows.

Sources

The Storage Bill After Vibe Coding

Thu, 08 Oct 2026 16:00:00 GMT

A 512GB laptop replaced by a new 2TB machine — three months later, 1TB is already gone. It is not downloaded movies; Vibe Coding changed the rate of production: projects, worktrees, generated assets, and intermediate artifacts pile into the drive at unprecedented speed. The bill has changed, and it is worth working out what it consists of.

What is eating the space

A good part of the eaten space can grow back. Package installers and dependencies left behind by every terminal install, caches accumulated by agents driving a browser over and over — in one observation, Chrome’s cache alone exceeded 60GB; chat-and-office apps with built-in browsers pile up in similar ways. Delete these and they regenerate, yet they occupy the most visible space.

The other part is hard to regenerate. Developers know system images well: to test across several OS versions, a few iOS and iPadOS images add up to forty or fifty gigabytes, and Xcode itself is no lightweight; chat apps’ local data is often the single largest item — for many people the single biggest item of all is WeChat. Then there are worktrees and furiously generated project files — the new variable Vibe Coding brings: where you once could not start more than a few projects a month, you can now run a pile of them in parallel in a single day.

All of these numbers come from observations on personal machines, not statistical conclusions; usage varies enormously from person to person. But the direction is shared: per-machine capacity has gone from “enough for many years” to “needing to be replanned every year.”

Caches can be deleted; raw footage cannot

These data cannot all be treated the same way. Caches and installers are regenerable data — the cost of deleting them is only a re-download. Project files and records are hard-to-regenerate original data — delete them and they are gone.

The trouble is the middle ground. Content creators know this best: 10 to 20 minutes of raw video is 20 to 30GB at recording spec. These raw files “cannot be deleted, but keeping them is not right either” — redoing them costs too much, keeping them keeps eating space, so they sit there until a later decision. One drive holds regenerable and non-regenerable data mixed together — that is exactly why cleanup has become hard.

The risk of automated cleanup has already shown itself: ask an agent to “free up more than 100GB,” and it goes directory by directory and does clear the space — at the cost of deleting nearly every frequently used app, ending in a full reinstall. Under capacity anxiety, “one-click cleanup” sounds tempting, but telling which files can regenerate and which are the only copy is still a judgment for a human to make — and this article offers no unreviewed cleanup operations.

Storage should be tiered

Since the data differ in nature, the way they are stored should be tiered.

The top tier is local hot data: projects currently running and frequently changed files stay on the fastest SSD. The next tier is the home archive: things not touched daily but checked now and then go on the NAS — direct access over the LAN, latency is no issue. Some people are already mount-syncing local Memory to the NAS, so personal data has one centralized copy at home.

Below that is the cold archive: data like raw video that “you definitely do not want to lose, but only retrieve a few times a year at most.” The cold-storage idea is this: an order of magnitude cheaper than ordinary cloud drives, at the cost of not being instantly downloadable — to retrieve a volume, submit a request and wait about a day. Trading a tenfold price difference for waiting sounds workable; the objection is just as direct: most users will not wait even 24 seconds, and waiting kills the demand outright. This remains an idea to this day — no validated product sits on a shelf. The old physical-media approach has its limits too: a DVD holds less than 7GB, not even one episode’s worth.

The bill beyond capacity: backup and retrieval

The drive bill has more on it than capacity. Backing up means at least two copies: buy a NAS at home and the drive may fail, so backup means buying another drive — the cost nearly doubles; a cloud subscription means paying monthly — one example from the time of recording was a household 2TB iCloud plan close to full, with the next tier up more than tripling the monthly cost. This is one individual’s bill; it is not budget advice for anyone.

Another item is easier to overlook: being able to find things again. In the multi-machine era, files are starting to scatter across more places — tools and outputs cloned into cloud computer VMs, cold backups handed to agents. After handing each episode’s cold backup to an agent, one practical question arises: which directory the backup actually landed in is unknown to the person who handed it over. Stored does not mean managed; if you only discover at the moment of recovery that you cannot say where it is, the value of the backup is discounted. High-frequency auto-syncing has its price too — there are already cases of drives worn to death by read-write.

Tiering is therefore not just about saving money; it is risk management: non-regenerable data goes somewhere steadier, with redundancy, and regenerable data does not occupy expensive space. As for those raw files that “cannot be deleted, but keeping them is not right either,” the real answer may not be a bigger drive, but a much cheaper destination where slower retrieval does not matter — it does not exist yet, but the demand has already arrived.

Sources

An Agent Can Run Errands for Me — Where Should It Stop?

Wed, 07 Oct 2026 16:00:00 GMT

Hand over the whole business of booking a hotel: tell the assistant the travel dates and the budget, then wait for the result. It sounds effortless, but the middle is full of decision points — which neighborhood, what price range, which cancellation policy, and on whose behalf what was confirmed with whom. Delegation is not one sentence; it is a string of questions that need boundaries drawn: when an agent runs errands for a person, from which step onward should it stop and ask a human?

An assistant, not an alter ego

With personal agents on the rise, an old question has become practical again: are these products the user’s assistant, or the user’s digital alter ego? The consensus of the current wave of products lands on assistant — managing email, managing schedules, booking flights and hotels: the chores that used to be carried by a secretary. The difference between an assistant and an alter ego is not the capability list; it is will: the assistant carries out the user’s decisions and comes back for instructions at the major junctures, while the alter ego forms judgments on the user’s behalf and speaks in the user’s place.

This positioning directly shapes the design of permissions. Being an assistant means the agent can be granted capabilities, but should not be granted, by default, the power to make decisions on the user’s behalf. The depth of delegation comes in tiers too: sorting email, summarizing a schedule — a mistake can be redone; book the wrong room, and the money is already spent and the itinerary may already have changed — risk rises with the degree of irreversibility, and the checkpoints should follow the risk. Which decisions still belong to the owner needs to be drawn explicitly by the product — and each user needs a list of their own in their head.

Price is only one constraint

One line of inference goes: an agent can search the entire web, it will always find a cheaper channel, orders will naturally flow to the lowest bidder, and the channel landscape will therefore be reshuffled. That inference reduces booking a room to a price comparison.

The actual logic of use is more complicated. One rhetorical question raised in the discussion: what if cheapness comes at the cost of a terrible experience? After the stay, the user will say, never book through that channel again — every booking there has been lousy. Beyond price there are location, preferences, cancellation policy, and channel reliability, and that information is scattered across the trip itself and across past feedback. What booking a room requires knowing is not just the current going rate but the owner’s habits — the ideal is for those preferences to be in the context before the order is placed, rather than being learned the hard way from one wrong booking.

The feedback loop is therefore part of the delegation system, not an add-on: the outcome after each stay has to flow back into the next decision, or the agent will keep repeating the same “cheap but wrong” choice. Delegation that optimizes only for price quietly pushes the hardest judgment back onto the user.

Taken apart, delegation has at least four tiers, each with its own risk. Reading and organizing — reading mail, arranging a schedule, summarizing orders; the risk lies in privacy. Executing and ordering — booking hotels, buying things; real money is spent, and a confirmation point is usually worth keeping. Committing to others — canceling an order, rescheduling, answering someone “I will be home tomorrow afternoon”; real-world obligations are created in the user’s name, and the cost of walking them back happens in the real world. Sharing information — telling other services or other people your itinerary, address, or finances; once given, it may never be retrievable.

Different tiers should authorize differently: reading can be one grant valid long-term, orders confirmed one by one, and commitments to others and sharing information should carry the highest bar. There is still a great deal of open product space here. One concrete example is Instinct and its friends network: friends who join can ask the assistant about all sorts of information about the user, and on that basis the product advises adding only genuinely close friends. Framing information access as “close friends only” is itself a design attempt at sharing permissions — the boundary has to be narrower than a social app friend list to be safe, and whether that setting holds up remains to be verified.

Which side it stands on

Traditional intermediaries and agents have their own interests; which channel gets booked is not necessarily the one best for the user. The new generation of booking assistants deliberately keeps its distance from that model, summed up as “entirely on your side, centered on your interests”. A positioning can be claimed in words, but a stance cannot rest on claims alone: where the revenue comes from and which channels it cooperates with will all affect how neutral the recommendations are. Users have few ways to verify, and the most practical one is the freedom to give feedback and to switch — if an assistant cannot survive the correction “don’t use that channel next time”, then standing on your side is just talk.

Where it stops is the product

Making the agent stop and ask is not a lack of capability; it is the structure a delegation relationship should have. The real question was never “can everything be done for me”, but which confirmation method each class of errands corresponds to: what gets one-time authorization, what gets a nod each time, and what stays in the owner’s hands forever. The line between an assistant and a digital alter ego is drawn precisely by these stopping points, one by one.

Sources

Carry Your Memory to the Next Agent

Wed, 07 Oct 2026 16:00:00 GMT

Say you have used an AI assistant for a year, and it remembers your projects, your writing habits, the topics you keep coming back to. Then a better agent appears, and the problem is no longer “should I switch” but “I cannot take it with me.” The memory lives inside the original product; switching tools means losing it all.

Who owns the memory

In cloud products, memory is stored on the server, bound to your account. That brings two headaches. First, the quality of the memory depends on whether the product is willing to do it well — if it does not, the user has no other way. Second, the product and the model behind it can change, and once data is handed over there is no guarantee you can get it back — a service that works well today may be redesigned, restructured, or shut down later, and the next, better one cannot read what was accumulated here.

One response is to maintain a local Memory and local context, on the expectation that dedicated products will appear to do this well. That is a judgment about product direction, still to be validated — but it points to a stance: personal context should have a home independent of any chat window, any product.

A file system as the foundation

Someone has already built this home as a file system: a database plus documents, with Memory as a pile of files. It is probably the least fashionable form, and the hardest for any single company to lock down — where the files are, what format they are in, whether they open: all plain to see.

Syncing is the first problem to solve. Syncing the files to a private GitHub repository is one option, but the practical problems are specific: the files are numerous and fragmented, and the repository quickly becomes bloated; worse is multimodal material — people who work with images and video often have no way to put those things into Git. So another approach appeared: write a mount that syncs the local Memory automatically to Xiaomi Smart Storage at home, without passing through any third-party service.

It should be noted that this is a personal practice, not a validated general-purpose architecture. What it demonstrates is that “an individual can hold their own context”; as for what structure the files should use, how the sync frequency should be set, and how different kinds of material should be indexed, there is no standard answer yet.

Tools change; the organization can stay

File-based memory has one easily underestimated advantage: it can move house wholesale.

One actual migration attempt took a set of plugins developed for Obsidian and gave them to an agent to port into another runtime: the agent judged which features had nothing to do with notes and removed them itself, then migrated everything in one pass. The tool changed, and the accumulated things — the plugins, the directory structure, the organizational habits — came along. This Memory folder’s way of organizing was originally carried over from an Obsidian notes folder; the software can change, and the organization does not depend on any one piece of software.

Memory, in implementation terms, is “a thing made of Markdown and Git” — or simply, files. The closer it stays to ordinary files, the lower the migration cost and the smaller the chance of being held hostage by a single product.

What goes into memory, and who uses it

A Memory actually in operation falls roughly into a few categories: your own projects, published work and content, the understanding you have formed, and records of daily life. Health data is in there too, synced once a day on a schedule and written back into Memory, then later used for analysis and visualization.

Another use of this file system is letting multiple agents share the same context. One approach is to load the usage quotas of several models into a single virtual machine and let them work out the arrangement themselves: whoever can write, writes; sitting idle is a waste. Tasks are no longer bound to a particular model or product — because the context lives in the file system, any agent that connects can read it. Portability therefore changes not just “switching tools” but also the way “using several tools at once” works.

Syncing is not backup

Finally, two things need to be told apart. Syncing solves “every location has the latest copy”; backup solves “what is lost can be recovered.” Files auto-synced to a NAS are gone entirely if the NAS has only one drive and it fails; high-frequency read-write also genuinely consumes the drive’s lifespan — there are already cases of heavy users wearing drives out by writing large amounts of raw data every day.

Collecting is not reliable memory, either. Stuffing things into Memory is easy; whether what was stuffed in can still be found, whether it is already outdated, whether it is worth keeping — these take another round of curation. Carrying memory to the next agent depends not on the act of copying files over, but on a library that is maintained continuously and can be handed over at any time — only if it belongs to you can it be said to follow you.

Sources

Life in the Inbox, Life in the WeChat Groups

Wed, 07 Oct 2026 16:00:00 GMT

The day before school started, an AI assistant with email access sent a reminder: the school has emailed — which uniform to wear tomorrow, which materials to bring, and a consent form that needs a parent’s signature. The technical difficulty here is not high; what is hard is the precondition for this to work at all — the school notifies parents by email. In a different setting, the same reminder might be buried in a parents’ WeChat group, and the assistant simply cannot reach it.

Capability lives where the information lives

For users whose statements, orders, and school notices all arrive by email, granting the assistant email access covers a sizable slice of life’s information flow. In one trial, Dots was granted access to Google services all at once, and the three things in the school email were automatically organized into reminders; this kind of experience comes naturally within the email ecosystem, because the information is centralized, the interfaces are open, and the formats are relatively tidy.

For many users in China, the same matters are scattered elsewhere: bills in the payment app, orders in the shopping apps, and school notices very likely in a WeChat group. The assistant cannot see those places, and no matter how strong the model, it can only give generic answers. This is not a gap in models; it is a gap in where the information sits — the first boundary of a life assistant is drawn by where the information lives.

To-dos inside group chats

Group chats carry part of this life information. The parents’ WeChat group is the example most often raised: message overload is the state of almost every group — teachers post notices, the parents’ committee posts sign-up chains, and the important to-dos drown in a flood of small talk and forwarded posts. If an assistant could read these groups, pick out the items that concern your own child, and help follow up, the value would be obvious — and so is the difficulty: the context is in the platform’s hands.

In-app assistants are another path. Cases recorded during the show: one user asked Xiaowei inside WeChat to find a certain group and post a notice; someone else ran into a device problem, asked Xiaowei directly inside WeChat, and got an answer. These capabilities happened on a case-by-case basis; they do not mean the platform’s interfaces are already broadly open. The advantage of in-app assistants is that the entry point sits inside everyday software; the disadvantage is that every step of capability is constrained by how much the interface exposes, and that can change at any time.

Vertical apps solve it first

In the places general assistants cannot reach, vertical products delivered answers first. Observations from recording time: ask a general agent to shop on Taobao and it cannot manage, while the AI inside the Taobao app does far better; for travel bookings, Fliggy’s AI is smooth; for medical consultations, vertical healthcare products answer in more detail than general replies. Capability grows where the data, the interfaces, and the context are. Hence one judgment: a truly general life agent does not exist yet — the context of every scenario is held by its own platform.

A more direct example comes from financial data: WorkBuddy connected to market data that could not be read anywhere else, users flooded in for that one capability, and other products promptly followed by wiring up the same source. The payoff comes from connecting data and interfaces, not from generic conversational ability.

Openness decides who gets to build a life assistant

The individual-level conclusion: the more context an AI has, the more it can help. This also explains the difference in product form between the two markets. Overseas, the connections between information services are relatively open — software can authorize one another, and both startups and big companies can obtain context; in China, interfaces are fragmented and data is not shared, startups cannot get context, and everyone keeps to their own walled compound. So connecting and authorizing rise from technical details to make-or-break product questions: the assistant has to fight for permissions at the phone’s operating-system layer, or it can do nothing at all. These are observations from recording time; the scope of interface openness is changing item by item.

Channel habits differ accordingly. One recorded signup experience: overseas booking assistants rely on iMessage or WhatsApp conversations; for users in China the signup bar is high, and once inside they do not know what to chat about with it — a life assistant cut off from the channels where the information lives loses its scenarios.

Closing

The competition among life assistants is, first of all, a competition over where the information sits. That email-ecosystem users get the complete experience first does not mean the other side lags forever: group chats, mini programs, and all kinds of apps hold equally complete context, and once a platform opens its interfaces, the positions can be reshuffled. The genuinely unresolved question is this: when life’s information is scattered across a dozen apps that do not talk to each other, who is responsible for connecting it — the operating system, the super-app platforms, or some assistant product willing to do the dirty work.

Sources

From a Blank Chat Box to the First Useful Task

Wed, 07 Oct 2026 16:00:00 GMT

A new AI app installs, and you open it to an input box. For people who cannot get through a day without agents, that is fine; for most people it is a problem: what should the first sentence be? The core claim of this round of personal agent products is precisely to put AI into the hands of those people — and whether it ends up being used depends on when the first useful task happens.

Where the first task comes from

An empty input box carries an assumption: that the user knows what they want. Actual observation says the opposite — a good share of people open a chatbot or an agent with no idea what to ask of it. So the starting point itself becomes an object of design.

One approach is to list scenarios. In one experience recorded during the show, Muse used a tab to list concrete everyday problems: the credit card was overcharged — can the AI get the money back automatically; a party is coming up — can the AI arrange shopping for the supplies. Each scenario starts executing the moment you tap it; the user does not have to compose the wording first. These scenarios are curated, close to real pain points of local daily life, and skewed toward life rather than work. Another approach is recommendation: drawing on long-term memory, pick out content the user is likely to be interested in, providing a starting point for the moments when they do not know what to do.

What the two entry points share is translating “what can I help you with” into a first step that can be tapped right away. The blank chat box has not disappeared; it just no longer carries the opening alone.

Life tasks do not need a workbench

Personal agents can be this simple partly because of another product line: agents are splitting into two kinds. Life-facing products keep getting simpler — practically, you open them and just chat; developer- and productivity-facing products keep gaining freedom — plugins, model selection, custom workflows, the works.

This split matches the nature of the tasks. Life tasks have no project, no codebase, no deliverables; the user does not need to manage sessions, does not need to understand context windows, does not even need to know which model is underneath. All that freedom in productivity tools is pure burden here. So the interaction of personal agents tends to fall back to conversation itself — back to the original chat-and-go form, with the complexity kept inside the system.

The counterexample makes the same point. In one experience recorded shortly after launch, Dots was placed in a sidebar already crowded with entry points; users could not tell it apart from the neighboring products, and getting started became harder. More entry points do not mean a lower bar; for life scenarios, every extra concept to understand costs one user who would have started. These are the product states recorded during the show; each product will keep evolving, and none of this is a final verdict on any of them.

Where the entry point sits is part of onboarding too. One recorded piece of product experience: users stay anchored to the contact lists in the apps they already use every day — one product made its assistant a “contact” inside WeChat, scan a QR code and you can chat, and the conversion cost dropped sharply as a result; in-app assistants follow the same logic, with the entry point inside the app people open every day, and the location itself saves the user one migration.

Hand it over, but keep it visible

Once the first task is underway, the dividing line of experience is the execution process. Two common kinds of frustration are both about communication: one is failing to help while creating a new problem; the other is parroting — restating what the user just said, offering no conclusion, then suggesting “maybe you should go do this”. The second drains patience especially, because what it spends is the user’s attention and time.

The better-performing products draw distinctions in their execution structure. Still the Muse experience: internally it has only two roles — one communicates with the user and assigns tasks, the other executes in the background; a small area in a corner of the screen keeps showing what the background is doing and which items are waiting for approval. With the conversation on the left staying alive and the status on the right checkable, the user can hand things over with peace of mind.

How assistance is requested matters just as much. Some steps the agent cannot do, and the user has to fill in one small move — how that request is phrased decides whether the user feels “it is helping me” or “it is bossing me around”. The quality of this stretch of interaction does not depend on model capability; it depends on whether product design treats people’s feelings as a first-class object.

Sessions for the system, a person for the user

With longer use, an organizational problem appears: does everything need a new session? Task-based products that split sessions per task have their reasons, but in life the counterpart of a conversation is “a person”, not a directory of files. Some products have begun shifting the unit of organization from the session to the person: you keep talking to the same person, and the system automatically organizes and distills the context generated along the way. A useful analogy is WeChat — its conversation list has always been people and groups, never topics and projects.

That said, a single session is not a cure-all. Programming and long-running professional work still need their own workspace and isolated context; cramming them into the same chat window only makes them interfere with each other. The sensible way for the two to coexist: hand life to one ever-present conversation, hand professional work to project-based tools, and do not force the two into one entry point.

Closing

From a blank chat box to the first useful task lie three layers of design: a starting point that needs no wording, an execution you can watch and correct, and an organizational structure the user never has to maintain. Only when all three are in place does the second conversation happen. Onboarding, then, can be redefined — not the user learning the product, but the product completing a full loop within the first few minutes.

Sources

From Selling Tokens to Delivering Services: Where AI Applications Make Money

Wed, 07 Oct 2026 16:00:00 GMT

Want to use a multimodal model in your product? First you wade through an ocean of documentation to find the model’s name, then work out how to call it; once you finally get it connected, the time to first token can be on the order of a hundred times worse than other providers’ — one real integration experience from recording time. Between buying tokens and turning them into an experience lies a whole stretch of engineering. The question of where profit lives is hiding in exactly that distance.

The resale math does not add up

The most direct business idea is resale: get a discounted price, sell at a markup. The reality is that the discount is thin. At recording time, someone reported being quoted a twenty-percent-off rate for reselling mainstream models’ APIs. The baseline for a viable business is roughly a forty percent gross margin; a twenty-point spread means losing money on every deal. For top models, the official channels already offer discounts themselves, leaving middlemen no room at all. It is even more true when models are in short supply — with no spare capacity, vendors have no reason to give discounts.

Another common accounting move is collecting upfront: bill a full year’s subscription at once and book it in the current period. That is cash flow, not profit — the service has not been delivered, and the costs are still ahead. Treating those numbers as profitability was a common error in that period’s application-layer funding stories. With capital once again concentrating into a few tracks, there is less room to subsidize losses with fundraising, so the profit question can no longer be dodged.

Margin only opens up once models get cheap

The turn comes from the supply side. A wave of low-priced, high-speed models around recording time gave the application layer real margin room for the first time: for the same reply, the same judgment, cost fell to a small fraction of what it was, leaving room to maneuver on service pricing. One case relayed in the discussion: an enterprise services company used to pay model vendors more than every dollar of revenue it took in; after switching to a self-trained version based on an open-source model, its gross margin finally turned positive. That is the relayer’s account, not independently verified, but the mechanism is clear: when model spending is large enough to swallow gross margin, an application company’s earnings have really been working for the model vendors all along.

This is also the context for the line “don’t be shy about selling tokens.” All the engineering the application layer does — interfaces, caching, scheduling, verification — ultimately exists so that users are willing to consume tokens there. Only by admitting this can you work out which part of the money you are actually earning.

Tokens are a unit of account, not a product

Comparing tokens to money was fashionable at recording time: model capability as the hard currency of the digital world — even a payments company’s acquisition of a model-routing platform was read as an early bet on “token settlement.” The metaphor has explanatory power, but it misleads easily — a currency’s value lies in being universal, while the application layer’s value lies precisely in not being universal.

Users have never paid for tokens themselves, but for the certainty behind them: availability, latency, output formats, fallbacks when things break, and the assurance that results can be safely handed to the next step. The same tokens, fetched from a cloud vendor’s console versus from a product that just works, are entirely different experiences. Cloud vendors sell APIs the enterprise way, while users often just want to get things running — that gap is the opportunity.

Earning the money in the last stretch of distance

Hence so-called experience arbitrage: integrate the models that are hard to integrate, smooth out the parameters that are hard to tune, so that users and agents can call them directly. It is most visible with multimodal and content-generation models — strong capability, but the interfaces are scattered across each vendor’s docs; whoever assembles them into a frictionless service is earning money for engineering and experience. The position is not short of people trying it; what it lacks is people who treat the interface service itself as a product. The direction favored in the discussion was a one-stop interface covering an entire class of multimodal models — video, images, and more — precisely because that part is the hardest to read and the most laborious. Opportunities like this need no exclusive models — only the stretch of distance that turns “it works” into “it’s good to use.”

The cost structure is still shifting. Inference costs are falling, while the compute hardware that running agents at scale needs is getting more expensive, so the build-versus-rent math is rewritten in real time as prices move. What does not change is the position: a pure discount-resale business has no moat; profit belongs to those who turn tokens into dependable services. The cheaper models get, the clearer the value of that distance — it is the application layer’s real source of gross margin.

Sources

Give the Agent a Computer That Stays On

Wed, 07 Oct 2026 16:00:00 GMT

Hand an agent a task, come back the next day, and pick up where you left off: is the software it installed yesterday still there? Do the accounts it logged into still work? Where did the files it generated go? The answers depend on whether it runs in an ephemeral sandbox or on a computer that never goes offline.

What remains after the task ends

The most common execution environment is the ephemeral sandbox: each conversation spins up a virtual machine, and different conversations or processes may land on different machines. The moment a task ends, the environment is reclaimed; anything installed and any intermediate state are not kept. This approach is cheap, and the price is that context does not persist and nothing accumulates between tasks.

Not every product leaves the execution environment in the user’s hands. Some vertical agents simply offer no way to run code: a reference image can be uploaded but never retrieved — the file system is effectively decorative. The problem is not that the model lacks coding ability; it is that the product never gave it an environment to operate on. More extreme cases have appeared too: content inside the environment simply vanished before the user could save anything.

Against this backdrop, the pitch for persistent environments is direct: the computer given to the agent should always be there, and it should come with a promise that data will not be lost. This step is no longer just a feature difference — it is treated as the product itself. Grok Bot puts this “cloud computer” on the table as a named component, while in other products the same thing hides behind layers of entry points, and users may not realize they already have one.

Sandboxes and always-on computers are two product generations

Agent execution environments have taken three steps in recent years: from conversation only, to running a piece of code, to owning a computer of its own — one that can install software, open websites, and log in with the user’s accounts to get things done. In the first two steps the environment is an accessory; in the third it becomes part of the product, and the vendor’s thinking shifts from “helping you complete a task” to “managing a machine on your behalf.”

The difference between an always-on computer and an ephemeral sandbox shows up in concrete details of use: the environment keeps running from the start of a task to the end, installed Skills and logged-in account states are still there, and next time you continue where you left off; each ephemeral environment wakes up as another process, with the previous context nowhere to be found. Manus’s early approach was one computer per task, reclaimed when the task ends — an environment, but no persistence. What separates these two experiences is not a parameter; it is whether the computer is actually its own.

That said, “persistent” is not a default promise across all products. Among cloud environments, the sandbox of Dots is stricter: no SSH access, no third-party software installs, plus frequent restarts and reallocation; whether what you wrote survives a restart depends on each implementation and needs to be confirmed version by version. When choosing which environment to put your work and data into, persistence is a property that must be verified separately, not a guarantee inherent to the category.

An always-on computer unlocks new task types

Ephemeral sandboxes suit “run once”: give a task, wait for a result. An always-on computer opens a different class of task — work that needs continuous presence and runs on a schedule.

One retold use case comes from an independent developer of Mac cleaning software: he handed multi-platform marketing promotion to an always-on agent computer, which visits niche forums in Europe and the US on a schedule and lets the agent judge each forum’s tone — some like independent developers telling their story, others prefer knowledge-heavy material — then posts according to when people actually browse. All he provides is the content. The key to this kind of task is not how clever any single action is, but that the environment can stay up: triggered on a schedule, observing continuously.

Tasks that need logged-in states depend on persistence just as much. Having an agent keep a set of accounts logged in, or open a browser and try out a batch of products one by one while recording the results, presupposes that tomorrow’s computer is the same one as yesterday’s. A sandbox cannot do this, because every time it wakes up it is a stranger.

Cost: the generation that cannot be given away free

Persistent environments are expensive in time. An ephemeral sandbox is destroyed after use; a cloud computer has to stay on, so the cost structure is entirely different. Some products offer no free tier at all — you pay from the moment you arrive, because running a virtual machine is a real, ongoing expense. Others make an enormous resource commitment, providing virtual machines and generous model usage to huge numbers of users at once and treating it as a long-term investment in an entry point — Muse is the latter, and it is clearly not something every vendor can replicate.

The cost gap is starting to show up in product tiering: whether there is a computer at all, and whether it is persistent, is becoming one basis for how agent products are priced and positioned. Openness is diverging too — some products let users browse the complete file list of a cloud VM from a phone and download individual files, while others keep permissions tight. When evaluating these products, who controls the environment and whether files can be taken out matter as much as its ability to run tasks.

The hardware route is diverging as well. Besides Linux virtual machines, there is now a model of serving whole Macs: vendors buy a batch of Mac Minis and connect macOS environments, remote desktop included, into the agent. Renting Mac environments is an old business; what is new is that it has been wired into the agent execution layer.

From one cloud computer to a set of computers

The first stage of persistent environments is one cloud computer: clone in your usual command-line tools and scripts, then from outside instruct it in a sentence to check sources, produce images, or publish content — no need to build a dedicated channel back to the machine that is always on at home. A second stage is emerging: agents are beginning to register and manage multiple machines — one cloud computer plus, say, a Mac Studio that is always on at home, with tasks able to land on any of them.

Further ahead is managing a fleet. Vendors’ roadmaps already include the idea of an agent managing every computer in a company or a household — these are plans, not shipped capabilities. Individual experiments are heading the same way: hand the login details of several VPSes to an agent to manage as a whole, have it keep track of what services run on each machine, restart the ones that die, and handle failover across machines — effectively an operations engineer on call at all times.

The end of this path carries new questions. Once cold backups are delegated to an agent, the person handing them over may not know which directory the backups landed in, or whether they can be restored when something goes wrong; the more management you hand over, the less you may understand the environment. Giving the agent a computer that stays on answers “what remains when the task ends.” The next question is: who takes stock of what remains, and who answers for it.

Sources

Why Write an Independent Blog When You Already Have a WeChat Official Account?

Wed, 07 Oct 2026 16:00:00 GMT

Assembling a set of AI sources exposes an obvious gap: major overseas AI media, podcasts, company blogs, and product release pages almost all offer RSS, while official announcements and release notes from vendors in China generally do not. Some updates even put the date in the title and contain no timestamp anywhere in the body. For feed readers and automation tools, these are two entirely different internets.

The difference is not one of technical capability. RSS readers were once popular on the Chinese internet too—readers like Zhuaxia flourished for a time—until that layer of open infrastructure was absorbed by platform competition: content got fenced into each platform’s own app, and subscription lost its place. The WeChat official account platform is a typical case. It offers original-content protection, so that after publication no one can copy your piece wholesale; in an environment where plagiarism-by-rewriting costs almost nothing, this closed design has real, practical reasons. The price is that official account content is barely open to the outside web: the biggest obstacle for anyone building an RSS reader is that official accounts simply cannot be subscribed to, and publicly offering a scraping service would raise compliance problems as well.

Where Independent Blogs Used to Lose

From the economics of readership, independent blogs have long been at a disadvantage, and they lost for structural reasons. Readers used to be distributed through platform recommendation feeds; independent web pages had no distribution channel of their own and could only queue up in search results. Official accounts, meanwhile, sat behind the most mature monetization engine in Chinese self-media, while open subscription never found a business model of its own—Substack-style newsletters built on RSS and email subscriptions are among the few exceptions. Openness shrinking without commercial support was the actual outcome of the last round of competition.

Yuan Chaofa’s comparison works as a specimen: he has long run an independent blog and an official account side by side, and the same article draws far fewer reads on the blog than on the account. It is hard not to wonder whether the effort of maintaining an independent blog is worth it at all compared with publishing only on the official account. If readers were only human, that conclusion would be difficult to argue with.

Agents Become New Readers

The arrival of agents adds a new variable to this question, because it changes the premise of “having no distribution channel.” Agents do not find content through recommendation feeds; they only look at whether content is reachable. One observation that has come up repeatedly: ask an agent to look up the articles of an author who writes only on WeChat official accounts and summarize the writing style, and it cannot find them; switch to an author with an independent blog, and it reads the entire blog, arriving at a much better-grounded judgment of the style. The reason is simple—official account content is nearly unsearchable from outside the platform, while the open web can be crawled and read by agents. Agents are constantly scanning open content, and this happens whether or not any human reader is present.

“Letting the internet and agents know who I am” describes exactly this shift: open content gains a batch of readers that require no manual operation, readers that take no part in the allocation of recommendation feeds and recognize only an address and a format.

It should be noted that these are, for now, isolated observations, and they do not constitute a promise about traffic outcomes. The position of independent blogs in search engine rankings has not changed because of this, and how the various agents index and cite open content is still in flux. Treating open web pages as a guaranteed “AI traffic entry point” goes beyond what the available evidence supports; what can be confirmed today is only that open content can be read, while closed content never even gets the chance to be found.

What Form Should Openness Take

If you accept the premise that “content should be readable by agents,” the next question is in what form. RSS remains a low-cost answer: it simply sits there, and any feed reader or agent can discover and read it on its own. By contrast, wrapping your sources in an MCP service actually requires the user to complete an installation first—one more threshold. Another idea floating around is to use the official account API to automatically sync the content you are authorized to publish into an RSS feed. That is a proposal still under discussion; whether it can be made to work reliably depends on the platform’s interfaces, and it should not be treated as an existing capability.

Whichever form you choose, the boundary should be drawn at content you have the right to publish. Content published inside a platform is subject to that platform’s mechanics, and converting other people’s closed content into an open subscription goes beyond what an individual creator should be doing. This site’s approach is to put content on the open web: every episode offers a web version and a Markdown transcript, with stable paragraph anchors so both humans and agents can cite them; blog posts also ship with Markdown versions. All of this is content the site itself has the right to publish, so the cost of openness stays under control.

Can Openness Pay Off

Whether open content can be made to work commercially, the previous generation of the internet never gave an affirmative answer: the Web 2.0 era had both the RSS standard and subscription habits, and in the end it exited the stage because the money never materialized. Whether this generation will be different—whether a more open generation of creators and services can capture some kind of dividend—is a question that has no answer yet.

For the individual creator, the part that can be reckoned is this: maintaining an open web page within the bounds of what you have the right to publish carries a modest marginal cost, and it serves both classes of readers at once—humans and agents. The part that cannot be reckoned is the return. Whether the call to give content an RSS feed will be widely answered, and whether openness becomes worthwhile again in the agent era, can only be left for later to verify.

Sources

Story, authorship, and audience in AI video

Mon, 05 Oct 2026 16:00:00 GMT

One educational demo is worth describing from a distance: someone asks an AI voice how humans walked out of Africa and evolved; the voice explains on the right while the visuals generate in real time on the left, changing with the content. Interrupt mid-way and ask a different question, and the visuals immediately switch to the new topic. A year ago, real-time generation of this kind was still dreamlike, subject-less blurry imagery; now it already has the look of a produced show.

But the question this demo answers is “can the visuals keep up with the narration,” not “is the content worth watching to the end.” Only by separating the two can you see where AI video actually stands today.

Grabbing attention and finishing a story are two different things

Much of the visual impact of real-time generation comes from the act itself — “the picture changes with the words.” You marvel the first time; by the second or third viewing it feels familiar. Novelty is a one-shot resource; it cannot sustain continued watching.

A video worth finishing needs another layer. In a short drama or a feature film, the audio, the video, and every frame’s transition form a whole; tearing the audio and video apart, converting each into text annotations, and handing that to a model to understand loses a great deal of information, and the resulting edit can only be mediocre. This is why omni-modal understanding models are seen as infrastructure for short-drama editing and automated advertising — they do not generate video, but they can understand it as a whole.

A parallel shift is happening on the generation side. Video models used to compete shot by shot: physical fidelity, prompt adherence, pixel density — whoever looked more real. The new change is no longer aiming to perfect a single shot, but generating multiple shots from one sentence and assembling them into a complete story. This is the same line observed in coding ability: models moving from executing instructions item by item to understanding intent and arranging globally — the finished film is conceived first and each shot realized afterwards, rather than disconnected clips being produced one after another.

The top works already have authorship

AI short drama is currently the form closest to “content” rather than “demo.” What has been observed is that hit AI short dramas appear on short-video platforms almost every week, of a quality high enough to make you forget they were made by AI. One figure that was cited: top AI short dramas on Bilibili can exceed ten million views in a week — that is an observation about top works and cannot be extrapolated to the whole industry; plenty of low-quality filler content exists too, and the “short-drama factories” that churn out volume and the premium works are two different markets.

The more notable judgment is this: finely made AI short dramas should not be read through the logic of traditional short drama; they are closer to top web novels — with their own authorship and creativity rather than a pile of cheap thrills. Authors who tell good stories and can serialize on a stable cadence (say, one episode every two days) are thought to be able to earn paid viewership similar to what web-novel readers give their authors. The “short-drama platform like Qidian,” monthly tickets, and usage-based payment extrapolated from that judgment all remain speculation for now — existing mainstream platforms still lean on an institutionalized, traffic-buying logic, and a reward path for individual authors has not been proven.

On the audience side there is one clear observation: the “AI flavor” of early AI dramas put people off, but when they clicked in and found the plot decent, the AI flavor was ignored. What audiences ultimately consume is the story; the generation technology is only the medium.

One event, many forms of expression

The spread of expressive capability shows up most vividly in breaking news. During the period when the Pinglu Canal was in the news, the same subject appeared in multiple forms — standard blockbuster-style edits, animation-style AI short dramas — and the finished quality across the board was generally high: both the editing, footage, and narrative craft of traditional teams, and expression done entirely by AI.

Half a year earlier, the right to express an event like this was still concentrated in the hands of a few teams with editing and footage capabilities. This is not the progress of a single team but the overall lowering of the threshold for expression. It carries a new problem with it: audience attention is finite, and once supply explodes, the filtering and recommendation systems come under more pressure than the creators.

The audience decides how far it goes

Low thresholds answer “can it be made”; the audience answers “is it worth continuing to watch.” Sustained viewing data says more than a viral hit: some AI dramas are never phenomenal, but their numbers are stable and people keep watching. Stability means predictable viewers and predictable room to monetize — exactly the property that separates serialized content from one-off virality.

As for the structure of opportunity for creators, two opposing pictures currently exist. One holds that lower thresholds let people who could already tell stories earn unprecedented returns — what they always lacked was not ability but a means of turning stories into moving images. The other speculation holds that once content production is highly automated, opportunity concentrates in a tiny top tier that collaborates well with AI, and ordinary creators become harder to see than ever. Existing observation can neither confirm the former nor refute the latter.

Only two things are certain: a viral hit does not equal an industry-wide opportunity, and treating individual top performers as the general level will misread the market; and story quality together with sustained supply — the two things not yet automated — still decide whether a work gets followed to the end.

Sources

After the Software Is Built, There Is Still Distribution

Sun, 04 Oct 2026 16:00:00 GMT

Build a piece of software, make an app, sell it to other people — for a long time this was the standard picture of the software business. That picture needs to be re-examined today: with the barrier to creation so low, “making something” is increasingly hard to count as value in itself, and how the work enters users’ lives — distribution — has become the real bottleneck.

This is not a mindset problem; it is a structural one. The friction of creating has all but vanished — writing a tool, cutting a video, generating a short drama now cost nothing but time and a small fee. But not a single bit of the friction in distribution has gone away: finding people willing to look, choosing the right venue, timing it well, building trust — every one of these still needs a human to do it.

Supply is growing; attention is not

The change is most visible on the content side. New AI-made short dramas break out almost every week, top titles rack up view counts in the tens of millions, and the quality has risen to the point where they can no longer be dismissed as “low-capacity filler.” On the other side, the observation is: among these AI dramas, the ones with the healthiest numbers are not the batch that went viral overnight, but the ones whose viewership has stayed steady over the long run with people always watching — only stability makes monetization possible, provided it really is stable.

A clear asymmetry has opened up between supply and demand: the volume of creation is multiplying, while attention, spending power, and the number of consumers have not expanded in step. The same holds in business at large — capital is concentrated in a handful of validated tracks, leaving little room for “build it first and figure it out later.”

This asymmetry decides one thing: finishing the work is only half the job. The other half — getting it seen — will not happen automatically just because the work is good.

Distribution is becoming a process you can break down

Does distribution have to rest on talent and luck alone? One secondhand case offers a different picture.

As retold, an independent developer set up a resident agent on a separate computer to visit niche forums in Europe and America on a schedule. The model first sizes up each forum’s temperament — some forums like indie developers telling their story, others prefer substantive, knowledge-driven posts — and then times its posts around when people actually browse. The developer only supplies the content itself; what is being promoted is his own software, Mole, and the vehicle doing the executing is a resident agent such as Grok Bot.

Before anything else, the nature of this case must be stated: its presentation on this show is itself a retelling, relayed after an in-person meeting. The original promotional results, whether the forums’ rules even permit this, and how those communities feel about machine participation in their content — none of it can be verified. So you cannot infer from it that “automated posting drives growth” — there is no evidence supporting that, and platform rules and community norms could impose hard constraints at any time.

What makes it worth noting lies elsewhere: distribution was broken down into executable steps. Read the context, choose the timing, place the content, wait for feedback — every step has a clear input and output. This kind of work used to depend on a marketing firm’s experience and headcount; now at least some of the steps can be handed to a program that follows a process. Being process-driven is not the same as being effective, but only once something is process-driven can its effects be measured and improved.

Users buy outcomes, not software

Back to the opening judgment: build an app and sell it — that arbitrage no longer holds up well today. One reason is that tool-shaped needs are being solved by users themselves with models: if they can put it together on their own, why would they buy your software?

From there comes a distinction: a tool, a service, and an actual outcome are three different things. A tool is software the user has to operate. A service is a process done on the user’s behalf. The actual outcome is what the user ultimately cares about — the problem solved, the content seen, the thing done. Distribution is precisely part of the service and the outcome, not an afterthought tacked on once the software is delivered. The AI-drama example makes the same point: what actually accumulates value is not any single viral episode but the continuous supply and the stable viewing relationship.

Distribution therefore deserves to be designed as part of the product, not treated as a one-time action on launch day. It comes with its own constraints: platform rules, community culture, and the scarcity of attention will not loosen automatically just because technology advances.

Distribution will not disappear; it will only change form. The genuinely open question is: in an environment of supply overload, what kind of distribution can be process-driven without exhausting the audience’s trust? No one has that answer yet, and it is worth anyone who has just finished a work thinking about it further.

Sources

Beyond Token Usage: The Other Hurdle in Team Delivery

Fri, 02 Oct 2026 16:00:00 GMT

The speedup on the model side continues: newer generations of models not only generate faster, they also hold their own ground when facing disagreement, sticking to their arguments instead of changing what they say to go along with the user. By that logic, once the code-writing step is accelerated, software should ship faster.

Yet a widely circulated claim says exactly the opposite: many non-technical roles have genuinely saved time after adopting AI, while the people writing code have gotten more exhausted. The reason for the exhaustion is not hard to infer — when the cost of a single task drops low enough, a person opens more projects and tries more ideas at the same time, has more things to keep an eye on, and the total volume of errors grows too. The speedup happens on the individual output side, but between there and software actually reaching users lie building, testing, signing, review, release, and making multiple people’s changes compatible with each other. Most of these steps are outside what a model can do, and they have largely not gotten any faster.

Iteration speed is an organizational capability

In many organizations, the road from spotting an early signal to turning it into a usable product is still long. One piece of direct evidence: big teams with the best models and the most senior engineers often iterate more slowly than small teams. The slowness is not on the model side, nor in the talent supply — what is genuinely hard to explain is why identical staffing produces completely different rhythms.

Some pin their hopes on “usage”: since models bill by the token, crank usage to the max and let AI into as many steps as possible. But simply piling up usage has not bought a matching delivery speed. The discussion calls this Token Maxxing, and the conclusion is that it doesn’t work — the companies in question have all taken efficiency steps, yet the real question, “how should the organization actually operate,” still has no answer. Usage measures input; delivery measures outcome. What’s missing between the two is precisely the organizational layer.

The collaboration architecture is the harder part

Writing code can be done by one person; delivery almost always requires a group. The more people involved, the harder collaboration gets — that is a lesson that has long held true.

There are two external observations worth noting. First, from the outside, OpenAI’s Codex team is not small, yet it maintains a fast iteration pace and relatively little internal friction, while some comparable teams that were once fast have slowed down. This contrast can only tell us that their collaboration architectures differ; their internal practices have not been disclosed in enough detail to copy. Second, abroad there is a class of design engineers: people with engineering ability, design ability, and product judgment at once. Once AI fills in the remaining steps, they can ship releases on their own. What this role demonstrates is the value of a closed loop — when a piece of work is held by the same person from requirements definition to final release, the handoff cost disappears.

It bears emphasizing that neither of these is an organizational prescription that can be directly applied. “Everyone should become full-stack” is not this article’s conclusion; at most it points in a direction: in organizations with slow delivery, the bottleneck usually lies not in individual capability but at the seams between people. How to redesign those seams has no universal answer today.

The individual side happens to offer a counterpoint. In one experience with Codex scheduled tasks, a task produced no results for several days; only after asking the agent to check itself did it turn out that over those days it had casually fixed a few display bugs along the way. Between a single user and a single agent, the closed loop can be so small that no organization is needed at all. The difficulty of organizational delivery is that the same loop must span many people, and every handoff point is a potential loss of speed.

Judge delivery by more than usage

If you measure AI-driven progress by token consumption, lines of code generated, or number of calls, you are only measuring the speed of the individual output side. Organizational delivery capability calls for a different set of metrics: how long the cycle from idea to launch takes, whether the release pipeline runs smoothly, how many conflicts arise when multiple people’s changes merge, and how quickly problems get fixed once they appear.

These metrics are rarely discussed publicly today, and they are also harder for the “usage” narrative to obscure. For teams bringing AI into their development process, the question worth answering first may not be “how many more tasks can we hand the model,” but “how many hands does an idea pass through now, from proposal to launch.” This hurdle is not in the model’s next update — it is in the organization’s own design.

Sources

A product promo video made with code, images, and music

Thu, 01 Oct 2026 16:00:00 GMT

A product promo video usually implies a small team: script, voiceover, music, motion graphics, and editing, each owned by someone. Now a different path has appeared — the whole video is drawn and written by a program, yet at first glance it looks nothing like the work of code.

The trail starts with the music. Someone produced two software promo videos in a row, and at first the background music was taken for ready-made tracks from a stock library — until it turned out that every video’s music was different, and each one landed precisely on the rhythm of the visuals. Asked where it came from, the answer was: written in Python.

Music: the score first, the sound second

In the past, asking AI to make electronic music usually produced a few notes looping back and forth over a mechanical drum track — instantly recognizable as generated. This time the approach was different: the model first wrote the music as a score, then converted it to audio via MIDI.

A score is a structured representation, and for a model, writing one is close to writing code — every note, duration, and dynamic can be specified precisely. That explains why the music lands on the video’s beats: the rhythm was not aligned in post-production; it was designed against the video’s tempo at the moment the score was written. The sound follows the structure of the visuals, rather than the music coming first and being made to fit the picture afterwards.

Sound effects follow the same logic. In one finished piece, even the typing sound sits on the BPM metronome — effects are not casually layered on afterwards; they are arranged as elements on the timeline. Every component of the audio layer obeys the same beat line, which is the direct reason the piece sounds “complete.”

Visuals: texture, motion, and overall orchestration

What makes viewers “momentarily forget it is made of code” is the texture in the imagery — a crayon-like feel, paper-like grain. These usually appear in handcrafted motion graphics or video-model output, but here every layer of texture was drawn by a program.

Another common technique is SVG animation: grass that grows with the music is actually a Bézier-curve animation; a sailboat is drawn line by line in a single continuous shot, with the surrounding waves generated from lines as well. Individually these frames are not photorealistic; what makes them pleasing is how the elements are orchestrated — when they appear, how they transition, how they land on the music.

Orchestration capability also changes the trade-offs. One case started from a codebase: the model was given an existing software codebase to make a promo video. The interface components were already there; it orchestrated the page actions, composed the score, and organized the pacing, and the finished video exceeded expectations. Model vendors themselves release feature videos this way — the launch content is produced by the model, no one spends much dedicated effort on it, yet the videos get richer with every release.

Orchestration also shifts the old calculations: next-generation models can assemble an entire piece straight from low-level graphics and audio libraries, bypassing the higher-level tools; the skill pipelines previously built for promo videos actually got in the way — applying the old workflow template to the same task worked worse than letting the model improvise. A template freezes in the capability limits of the previous generation of models; once the model gets stronger, the constraints become negative optimization.

Image models are still called in from the sidelines

This path is not “everything in pure code.” In one fully observed case, the maker provided only the script and the music; the model chose a sticker style on its own and produced, from scratch, a complete video with a plot and full transitions — along the way it called an image model to generate pictures, while the rest of the animation was pure code. The division of labor is roughly: image models handle the concrete forms that code struggles to conjure out of nothing, and code makes them move while maintaining the rhythm of the whole piece.

Controllable editing of image assets is where the weakness still lies. Image editing had a well-known problem: generate or modify from one reference image a dozen or more times, and the person in the picture drifts slightly, gradually changing. The new generation of editing achieves “things that shouldn’t move don’t move at all” — change one region and everything else stays pixel-identical — but other regions show artifacts and colors that gradually turn muddy, so it remains some distance from being usable. For promo assets, predictable local editing matters as much as generation; otherwise every revision means re-checking the whole image from scratch.

Whether it looks good is an experience judgment

“Motion graphics at eighty out of a hundred are already good enough to take client jobs,” “no different from music written by a person” — statements like these are impressions formed after watching the finished pieces, not benchmark results. They carry limited information, but they can be checked: publishing the finished video, the prompts, and the production time is more convincing than any adjective. Taste here is not mysticism but a set of concrete questions that can be verified with the eyes — does the texture look hand-drawn, are the beats landed accurately, does the story flow. Until more finished pieces are made public, evaluation of these works should stay at the level of “experience reports,” not capability ratings.

Combining the pieces into a finished work

Look back at how this promo video is constructed: the music comes from a score, the visuals from vector animation plus a few generated images, the structure from overall orchestration. Each kind of material has one expression form that suits it best — sound via scores, graphics via paths, key imagery via image models — and code stitches them into the same timeline.

Compared with earlier generations of generative tools, the real change is at the orchestration layer: instead of generating disconnected clips segment by segment, it works like an editor — the finished film is already conceived in the mind before pen touches paper, and only then is each element’s timing decided. Whether this path can be reproduced reliably on every project depends on the material type and the requirements for the final piece; what is certain is that “made entirely in code” was never the point — the point is that every part got the right expression form.

Sources

AI Memory Needs a Completion Button

Tue, 29 Sep 2026 16:00:00 GMT

You mentioned something to your AI assistant in passing, and for days afterwards it keeps bringing it up. The matter is long past, or long disconnected from the rest of your life, but the reminders will not stop. That is not the assistant having too good a memory — it is a system that cannot tell three things apart: what is merely information to remember, what is a goal in progress, and what is a task that should end once it is done.

A memory, a goal, a task

Everyday matters fall into at least three classes. One class is memory: where you live, what grade your child is in, what you are allergic to — information that is stable over the long term, does not expire week by week, and cannot be called “completed”. One class is a goal: something in progress with an endpoint — preparing a move, getting a chronic problem sorted out — that needs to be continuously tracked. And one class is the task: paying the insurance premium tomorrow, renewing a contract next month — a single action that ends when it is done.

These three call for different treatment, but when all of them are spoken into one chat box, the system often has only one way to handle them: write everything down. The memory is stored, the goal is stored, the task is stored — and “when is this matter done” is not stored anywhere. An example from one product discussion is typical: after you tell the assistant something, it “nags you about it every single day”, and what it nags about has long stopped having anything to do with what you are actually doing. The information is not wrong; what is wrong is that it has no way to end.

Checking a box tells the system: this matter is over

The checkmark on a to-do list looks like an action; it is in fact a status signal: this thread of attention can be closed. In one product experience recorded during the show, Muse broke long-term goals into a list on its page; when something was done you checked it off, and after the checkmark the system stopped dwelling on it.

The value of this design is not an extra checklist, but giving memory an exit: the relevant information can settle and stay, yet “reminders about this matter” should have a way to end. Without that exit, the user is left with a single tool — repeatedly clarifying out loud “no need to bring this up again” — and each clarification itself becomes new context.

To put it the other way around: assistants complained about for “remembering too well” do not lack a stronger memory model; they lack an interface element so simple it is almost not worth designing — a button that moves a matter from “being attended to” to “ended”.

Why pure chat cannot manage to-dos

One attempt was recorded: putting away TickTick and managing to-dos entirely through conversation. A year on, the conclusion was that nothing had been managed well, and the list app was taken back up.

The failure was not the model; it was the shape of chat. A conversation is a stream that flows forward — what was said sinks into history, and finding it and confirming it both take effort. There is nowhere to check something off when it is done, nowhere to schedule it when it is not, and a day later you cannot recall what you asked the assistant to do. After interacting, a person needs a result that can be revisited and verified — and that result has to live somewhere outside the chat stream. The recent revival of note-taking and to-do apps is related to exactly this gap: the more people interact with AI, the more they need an interface outside the interaction where results can be checked.

The simplicity of the sticky note, the hard problem of generalization

The to-do need itself is utterly mainstream. A former Google Calendar product manager relayed his team’s research in a conversation: the tool ordinary American users rely on most is not any calendar software — it is the sticky note stuck on the fridge. Filling a calendar to the brim is a minority need; most people’s to-dos are on the level of “pay the water bill tomorrow”, with no use for a methodology or a complex interface.

The difficulty is that a pure program cannot handle generalization. What counts as “done”, when something expires, how to follow up when plans change, which part of a sentence is a task and which is just venting — the rules are hard to write completely, and any rule set that is complete fails on the next slightly different sentence. This is exactly the place a model can fill in: turning a natural sentence into a record with a state, an endpoint, and an exit, then letting a simple interface handle the display and the checkmarks. The program handles form, the model handles understanding — each doing the part it is good at. This is a direction inferred from existing products; actual capabilities are subject to what each product ships.

Ending, not forgetting

A completion button does not solve an efficiency problem; it solves an awareness problem: the system finally knows that this matter is over, as far as the user is concerned. The layering that follows is clear — information settles into memory, with no deadline; goals carry progress and update as they advance; tasks get checked off and closed, and the reminders stop with them. Mix all three into one “memory”, and the assistant has no choice but to be always-on about everything.

The question that remains open is who draws the boundary: before the user checks the box, can the system first judge that a thing is actually done? And are there matters whose way of ending is not a checkmark but simply expiring? The completion button is only the first step; managing task states is the real product problem behind it.

Sources

To-dos, memory, and visible results

The Product Design Behind a Single Authorization

Mon, 28 Sep 2026 16:00:00 GMT

Ask an agent to plan a trip to Shanghai: who to see, at what time, at which place. It needs to call a maps service, so the task stops right there — the user has to go to a developer platform, apply for an API key, copy it, paste it, configure it, and only then can the task continue. For a connection you might use once a year, the setup cost far exceeds the task itself, and most people give up here.

Authorization should appear at the moment of need

Other products have moved this step into the middle of the task. In one experience recorded during the show, when Grok Bot needed to read a Gmail inbox, the interface popped up an authorization card and a single tap completed it; Muse went one step further — when the user said “help me sum up what I should do”, it asked whether to connect to Gmail, and “one tap on OK and it was done”. What both share is the progressive approach: it appears when needed, and it authorizes when needed.

The opposite is the checklist-style design: connectors are gathered in a store or a settings page, to be picked and preconfigured by the user in advance. The problem is not just a few extra steps. One flaw that was pointed out: some agents don’t even know which connectors they have — when something isn’t connected, they just answer “I don’t have that” instead of suggesting a connection. Where the authorization entry point lives determines whether the user walks along with the task, or has to build a stretch of road before setting out.

Once authorization is smooth, the shape of tasks changes too. In one experience recorded during the show, a user asked Grok Bot to test the top ten products on Product Hunt one by one, and it actually opened a browser — after obtaining authorization to the Google account, it logged into each site in turn to run the tests. Under a checklist-style authorization flow, this kind of task would almost never even be started — the preparation of permissions alone is enough to make people give up. Embedding authorization into the task doesn’t just save a few steps; it makes a whole class of tasks that people simply wouldn’t have asked for before actually feasible.

Connection itself can be a service

Back to the trip-planning example: applying for the key, configuring it, even paying the maps service — all of it could be carried by the product, exchanged for credits or a subscription. As one discussion put it, spending a few extra credits for this is perfectly acceptable; paying for the result is a natural exchange. The value of a task lies in its result, and making users spend attention on infrastructure amounts to leaving the hardest part with the person least equipped to handle it. Most external services get used only a few times a year at most; preparing a whole configuration for them is never worth it.

Following this logic to its conclusion leads to a more radical judgment: in the products of the future, concepts like MCP, Skill, Connector, and Key should no longer be exposed to users. That is an opinion, not an established fact, but it points in a direction — what ordinary users want is “the thing got done”, not a vocabulary of integration terms. How capabilities are presented belongs in the same discussion: the same capability, buried deep under menus in one product, given a name and an entry point in another, differs completely in discoverability.

Progressive authorization is easily misread as “less authorization” or “automatic authorization”. Not one step of confirmation was skipped in the experiences above: the card still pops up, the button still needs tapping, and the user still knows which service the agent will access and as whom. What gets compressed is the preparation cost and the terminology learning — not the decision.

This is exactly the step that cannot be skipped. The lighter and more frequently authorization is woven into tasks, the more each individual authorization needs to make clear what the user is agreeing to. A flow that always asks for a tap is, at the same time, an always-visible disclosure; simplify it into silent pass-through, and the few seconds saved will be paid back at the price of trust. The standard for judging whether a product got this part right is not the number of steps, but whether the user understands what is happening at the moment of authorization.

Count the connection cost as part of the full service

A single authorization is a matter of seconds, but it decides whether a task can be finished in one go. A complete personal agent service is therefore more than model capability plus a runtime: it also includes connection to the outside world — the user names a thing, and the product is responsible for clearing every checkpoint along the way. The yardstick for this part of the experience is concrete too: count how many times a task gets interrupted, and how long it takes to resume after each interruption. The product design of the authorization step is, in the end, scored by that number.

Sources

Local Inference Is Worth More Than the Money It Saves

Sun, 27 Sep 2026 16:00:00 GMT

Two identically named machines can be used in completely different ways. One 128GB desktop runs open-source models as a local inference box; another 32GB machine in the same series never runs local models at all — it serves as an always-on development machine and has not been shut down since the day it was bought. These two cases from recording time show that “buy an always-on computer” and “run models on it” are two separate decisions. Always-on devices have their own constraints, but those constraints have nothing to do with models: smaller-memory machines tend to hit the ceiling on heavy engineering workloads, and cooling becomes the bottleneck before compute does. To discuss whether local inference is worth it, it is best to pull the tangled needs apart item by item.

The savings math mostly does not balance

The most-cited reason for local inference is saving money. One extreme calculation concluded that a high-end desktop running models around the clock would break even in about two years; at ordinary people’s actual usage frequency, the payback period has to be counted in decades — because the device cannot run at full load all the time. Counted purely in saved API fees, self-hosting is almost never worthwhile for an individual.

Vendors do the math differently. When request volume is large enough, moving some tasks onto users’ devices is actually cheaper: at recording time, one vendor built a local model into its browser product, auto-configured after installation, so that specific tasks complete on-device; browser makers have long shipped small models that download on demand. On-device compute is an expensive idle asset for an individual, but a lever for spreading costs for a platform — the same hardware, viewed from the two sides, produces completely different accounts.

What you can run is decided by VRAM and quantization

The first gate for local inference is VRAM. Slightly larger models do not fit on a single consumer GPU, and multi-GPU setups exceed what an individual can take on in both cost and complexity. Quantization therefore becomes key: one case circulating at recording time was ternary quantization of a 27B model, shrinking it to about 5.6GB with a claimed 98.2% of aggregate performance retained, runnable on a single GPU. Claimed numbers like that come from the vendor’s own evaluation; whether they hold on specific tasks still needs re-testing. Speed, too — one user got roughly thirty tokens per second on their own machine and concluded “it’s already usable”; that is a single case on specific hardware with a specific model, not a general benchmark.

Judgments about parameter scale also change with time. The wave of Flash-tier open-source models around recording time noticeably expanded the options for desktop machines: one user tried installing several open-source models in turn on a large-memory machine — mid-sized model families through the new Flash tiers — and concluded that the machine could run them at acceptable speeds. That also means the feasibility list for local inference needs to be recalculated regularly; old conclusions cannot be carried over as-is.

Some value does not convert into the payback math

Counting savings alone misses local inference’s real points of difference. Data never leaves the machine: tasks involving personal records or private files need not be uploaded to any service. Offline availability: when the network is down or a service is discontinued, local models and pipelines keep running. Control: you decide when to upgrade and when to replace, unaffected by vendor decisions — a cloud model’s version and pricing can change at any moment; local weights will not.

These three values depend heavily on the specific person and situation. Professions handling sensitive data, places with unreliable networks, and wariness of depending on a single vendor’s pricing all shift where the balance sits; for users without those constraints, they are worth almost nothing. Cloud models also have a lifecycle problem: gains in inference efficiency push vendors to keep delisting older versions, and any workflow depending on a specific version faces migration at any moment; local weights are untouched by such arrangements. That is why the same payback calculation leads different people to completely different conclusions — the difference is not just the electricity price, but all these factors that cannot be converted into money.

Edge and cloud are a division of labor, not a replacement

Local inference does not have to shoulder every task, either. The more realistic division of labor: the mechanical, high-frequency everyday operations inside software — organizing files, renaming things, running a one-off classification — go to small on-device models; the heavy lifting of creating complex systems and products stays on large cloud models. The value of an always-online device lies here too: it stands by at all times for requests that do not need top-tier intelligence but do need an immediate response.

Worth noting: the always-on execution environment itself is becoming a business of its own. Demand for always-on cloud-hosted machines is expected to grow fast as agents spread — agents need a “computer that never goes offline,” but that computer can be rented rather than bought. That makes the local trade-off clearer: put the non-price values — privacy, offline use, control — back on the scale, then decide which parts are worth keeping in your own hands.

Sources

What Is Jev For? Give the Model the Judgment, Give the Program the Result

Fri, 25 Sep 2026 16:00:00 GMT

More than three hundred memories sit inside an AI assistant. Which ones are worth keeping, and which are just stale trivia? Asking the model to write a summary does not complete the cleanup. What the program ultimately needs is a keep-or-drop decision for each memory: a score, or a retention verdict.

That is exactly the kind of task Jev targets. Selection, scoring, and yes-or-no judgments all become results a downstream program can consume directly. Inside an agent that already understands requests and plans steps, this capability can take over the smaller, more frequent slice of the work.

From three hundred memories to ten thousand contacts

In one trial against Cola, more than three hundred memories were handed to Jev for scoring. The model singled out roughly eighteen items it considered important, leaning toward abstract information and discarding fragmentary trivia.

The result offers a way to observe the model: how it understands “important,” and whether that matches what the memory owner needs. Eighteen is the outcome of this one pass, not a tested optimum.

Another experiment ran at larger scale: tagging roughly ten thousand WeChat contacts based on chat history and shared groups. There were twenty-odd candidate labels—CTO, founder, and similar roles—and one person could match several at once.

The task was first imagined as one call returning multiple tags, then restructured into per-label judgments: does this person match the first label, does this person match the second, and so on. A multiple-choice question became a series of yes-or-no questions.

The split fits the model’s output format better. Judgments across different contacts and labels have no dependency order, so calls can fire in parallel without waiting for the previous one. The model produces results; the program handles scheduling and aggregation.

As of when this experiment was recorded, the ten thousand contacts had not all been processed, and the comparison against other small models was unfinished. The case already demonstrates the task-splitting approach; accuracy and total processing time remain to be verified.

Frequent judgments are the ones that scale

Tagging contacts is one use among many. Scanning each day’s chats for to-dos and important information involves the same kind of repeated judgment; scoring contacts by rule and tidying up a friends list share the same structure.

What these tasks have in common is volume: the same judgment runs many times. Only then do the time and cost of a single call accumulate into a perceptible difference.

Conversely, if a step accounts for 1% of the total workload, cutting its cost by 90% improves the whole by only 0.9%. Swapping the occasional call in a workflow for a faster model may not justify adding a whole new integration path.

When choosing scenarios, it is worth seeing clearly where the judgments happen, how many times a day they run, and how much overhead they actually account for. Memory screening is good for observing a model’s trade-offs; bulk tagging is better for testing throughput. The two need not be measured with the same yardstick.

A returned result is not a correct judgment

Structured output solves how the program receives an answer, but whether the answer is trustworthy needs another layer of verification.

A classification can be perfectly well-formed and still put the wrong person in the wrong bucket; a score can come back stably and still mismatch the user’s sense of importance. No longer retrying on format errors does not mean the program can skip checking judgment quality.

Claims of “no hallucination” therefore need careful reading. If the promise covers output format, it cannot be stretched to mean every answer is correct. The contact-tagging task still comes back to concrete questions: who got mislabeled, which labels are easy to confuse, and whether the errors affect downstream use.

The materials behind this trial also list limitations around multi-hop reasoning, complex references, arithmetic, and date handling. A question that takes several relational hops to answer should not be treated as a simple judgment just because the output is short. Irrelevant context can also hurt accuracy; up-front cleanup and filtering still matter.

Finding its place inside an existing agent

In practice, a reasonable first step is having the existing agent read the model documentation and build a prototype for a concrete scenario. But once the prototype runs, differences in request types, calling conventions, and the existing workflow still need handling.

A standalone demo only has to prove that a usage is possible; a daily workflow has to process real data over and over. Where the model gets invoked, what it returns, and how results flow into the next step all need to be explicit.

That also defines where Jev is worth trying: judgment steps that are hard to fully specify as rules, need semantic understanding, and run at high frequency. Complex reasoning can stay with other models; deterministic computation can stay with programs. Whether a given step is worth replacing should be answered jointly by that step’s quality, speed, and integration cost.

From memory scoring to contact tags, what always needs verifying is the concrete task. Returning a score is only the starting point; whether that score helps the program make better trade-offs decides whether it earns a place in the workflow.

Sources

Why Using an Agent Makes You Want an Ultrawide Display

Thu, 24 Sep 2026 16:00:00 GMT

A web page takes up a 16:9 area, with chat and a session list beside it. This is a concrete vision of a working interface—and enough to make someone consider a 5K ultrawide display.

The need came from using the browser built into Codex: web pages still need enough width, and the conversation needs to stay in view. When the browser and the agent share one window, the space that used to belong mostly to web pages has to be renegotiated.

A wider screen really can show all these areas at once. But whether the workspace feels right also depends on where windows appear, and how the pages in front of you relate to what you are doing.

Web pages and conversation start competing for space

Using a browser on its own, a page can occupy most of the window. Add a chat area and a session list, and keeping the page at its original width means widening the layout on both sides—or, if the total width stays fixed, compressing one of the areas.

In that layout, a wide screen has a clear purpose: view a page on one side, converse with the agent on the other, and switch back and forth less. That explains why a change in how software is used leads to thoughts of buying a new display.

Keeping every area open at all times, though, makes the interface feel crowded. Feedback on this kind of usage includes both wishes for more screen width and complaints about areas taking up room and windows being split and merged repeatedly. They reflect the same interface under different ways of working.

For work that needs a page and a conversation visible together, more horizontal space may help; if the window arrangement changes often during work, width is only one factor.

Where a window appears needs to be predictable

More disruptive than a shortage of space is clicking a link and not knowing where the page will show up.

Two situations came up in this experience: a page sometimes opened in the side browser, sometimes in a separate window. The merged-versus-split state changed too. The user had to deal with the page’s content while also relocating windows and re-understanding their relation to the current session.

Such problems do not disappear when the screen gets wider. An ultrawide display can hold more areas; window behavior still has to be stable. Only when the outcome of each action can be expected does the extra space become easy to use.

So evaluating an interface like this means looking beyond whether pages and chat fit side by side: can work continue smoothly when you open a link or switch pages?

Which task should a tab follow?

Once the browser enters the agent, the relationship between tabs and projects deserves reconsideration too.

If a piece of work already has its own project and sessions, its web pages still live in a separate tab list, and the user has to maintain the connection between the two. Putting the browser inside the same application only brings the surfaces closer together.

The deeper idea is letting tabs link to projects: switch to a piece of work, and its conversations and pages can be found as one group. The project provides the organization, the tabs hold the actual pages, and together they form the context of that work.

What is discussed here is a workspace design, not a complete capability that shipped at the time. Its value lies in reducing the split between two management systems, letting pages be organized by task instead of merely occupying another visible area.

This can happen alongside a wider screen. Width makes more content visible at once; project linkage makes that content relate to each other. With both space and organization in place, the browser and the agent start to form a coherent experience.

From browsing pages to organizing pages around tasks

Adding an AI assistant to a browser and adding a browser to an agent start from different points.

The former builds on existing browsing habits, adding an entry point to ask questions or get help beside a page. The latter starts from tasks and conversations, treating pages as things to open, view, and operate while getting work done.

Both routes may end up putting pages and chat together, but the organizational center of gravity differs. For task-centered usage, whether projects, sessions, and tabs can work together matters more than adding another chat panel.

Standalone browsers still have their place. Watching videos, scrolling feeds, and reading articles do not all require setting up a task first. In-task page operations and everyday content consumption can keep separate entry points.

The urge to buy an ultrawide display therefore offers a concrete angle of observation: as agent capabilities enter daily use, even what belongs on screen—and where—starts to change. Pages, conversations, and tasks can share one screen; the next product question is how to make them all belong to the same piece of work.

Sources

Speech recognition is already accurate — so why is voice input still clunky?

Wed, 23 Sep 2026 16:00:00 GMT

Anyone who has built their own transcription setup can feel the progress in speech recognition directly: newer models handle proper nouns better and cope with spoken language better, and the speech field is still thought to hold plenty of low-hanging fruit, because most top talent has gone over to language models. The recognition side is genuinely getting better.

But day-to-day input is a different story. Over the same period, new players like NetEase Youdao have entered the category one after another, yet a single desktop may still keep two or three voice input tools installed at once — installed, then uninstalled. Beyond accuracy, where exactly is the friction?

Voice tools and keyboards got bundled together

Voice input products come in two forms: standalone software, and features that live inside a keyboard. Each used to mind its own lane; the trouble starts when they cross the line.

One trial on a phone went like this: Doubao has solid speech recognition, but it bundles voice with its own keyboard, and that keyboard’s vocabulary and word prediction haven’t caught up. The user only wanted the voice part, but typing kept producing errors; after a few of those, the instinct isn’t to report the problem — it’s to uninstall.

That experience forces a choice on the user: is a voice tool meant to replace the keyboard, or complement it? One pragmatic answer is to keep one of each — the keyboard handles typing, a standalone app handles voice, with no three-in-one ambitions. When users have to manage these tools by deciding how many to keep, it’s a sign the boundaries between products aren’t yet clear enough for anyone to keep just one.

Custom vocabulary is the mile beyond recognition

Progress on the model side reduces recognition errors, but proper nouns — people’s names, project names, jargon — still tend to need a custom vocabulary as the safety net. The product gap here is actually more obvious: the WeChat keyboard is already good enough at speech recognition; it just doesn’t support a custom voice vocabulary. If that feature shipped, standalone tools like Typeless would stop being a necessity for many users.

Proper nouns thus set up a contest between two routes: models keep improving and cut corrections off at the source, or products open up vocabularies so users don’t have to wait for the models. For now, the latter is cheaper and faster — and it is exactly the part many products haven’t built.

When the text appears, and how much it gets cleaned up

Another reason a voice tool gets installed and quickly uninstalled: you can’t see the words as you speak. You talk for two or three minutes, nothing appears on screen, and the whole thing arrives in one dump. Without real-time feedback, the speaker has no way to know whether recognition has gone off track, and realizing mid-sentence that something is wrong means starting over.

Real-time display isn’t a hard requirement for everyone, though. When someone complains about it, other users’ first reaction is to wonder whether the tools they use daily do the same — they never treated it as their main pain point. Preferences about “cleaning up” the text split more sharply within the same group: heavy users can’t live without long-form polish and want filler and repetition removed and the layout reflowed; the same feature in other tools is seen either as overreaching or as doing only the bare minimum; and some users feel that at the transcription level everyone is about equal, with no fundamental difference in long-form capability.

There is no single right answer for how much to clean up. Too little polish and the text still needs manual rework; too much and the product starts making decisions on the speaker’s behalf, changing what was actually meant. This is closer to a parameter that should be adjustable than to a setting the product picks for everyone.

On phones, the OS is the first roadblock

On the desktop, the friction is at the product level; on the phone, it starts at the system level. Using a third-party keyboard’s voice input on an iPhone means going back and forth through Settings to manage permissions; keeping it always-on raises a different set of worries. Both per-use authorization and a persistent background presence were seen as unacceptable, and the end result was that voice input simply wasn’t usable on the phone at all — someone used to speaking to type switches back to an iPhone and instinctively makes the wrong gestures, then finds the cursor jumping between input fields.

In-app entry points therefore become a way around the system. The microphone button built into chat apps is many people’s most frequent voice input method on the phone, and the later addition of press-and-hold-to-talk with the mouse on desktop was considered intuitive. The problem with these entry points isn’t the interaction itself but the details: repeated usage tips get tiresome. The lower the threshold of an entry point, the more it gets used — a position these products earned for themselves outside the keyboard.

The friction list decides what stays

Put the frictions above side by side and it becomes clear that the competition in voice input left recognition accuracy behind long ago: whether vocabularies are open, whether text appears in real time, whether the level of cleanup is adjustable, whether system permissions can be worked around — each one helps decide which tool a user keeps and which gets uninstalled.

Almost none of these problems requires new technology. What they require is for products to hand control back to users — allow voice-only without hijacking typing, allow custom vocabularies, allow watching the words as you speak, allow adjusting how much the text gets cleaned up. Recognition is already accurate enough; for everything else, the contest is over who removes the friction first.

Sources

Icons, book illustrations, and publishing: what AI-generated vector graphics are for

Tue, 22 Sep 2026 16:00:00 GMT

Enlarge an AI-generated image a few times and the edges start to blur. On screen it may still pass, but once it enters icons, print publishing, or large-screen display, blurred edges make it a reject. These scenarios never needed “an image” in the first place — they need a set of shapes described by curves and editable afterwards: vector graphics.

Image generation models output pixel arrays; vector graphics take another road. Formats like SVG record paths and shapes, scale without distortion, and every anchor point and color can be modified at any time. However strong image-generation models get, they cannot change the fact that their output is pixels. Vector generation therefore becomes a problem of its own.

How hard can drawing one small icon be

The SVG icons common in interfaces are far harder to draw than they look. In a frame a few dozen pixels square in Figma, you trace Bézier curves point by point with the pen tool, or cut and combine basic shapes with boolean operations. Skilled hands work faster, but people who are genuinely good at icons are rare — one figure cited from experience: twenty icons take a day.

The difficulty comes from size and tolerance for error. An icon is only a few dozen pixels, so a deviation of a few is plainly visible, and a slight error in a curve’s arc bends the whole glyph. Unlike illustration, which tolerates mistakes through overall atmosphere, an icon demands precision in every stroke. More troublesome still, icons rarely exist alone — a set shares its grid, stroke widths, and corner-radius rules, so changing one means preserving the consistency of the whole group. None of these constraints can be satisfied by “drawing something that looks right”; they all live at the path level.

That is exactly why icon work is difficult for image-generation models to do incidentally: pixel output gives you no anchors to adjust, and every regeneration makes the style drift again. Bézier curves and boolean operations are the basic vocabulary of this work — and they happen to be what code is best at manipulating, since a path is data: coordinates, arcs, and composition relations can all be read and modified by a program.

General-purpose models have never been particularly good at this task. Ask a large model to draw everyday interface icons, and the shapes often will not hold while the details blur into a mess — a repeated observation from daily use, not a benchmark conclusion.

What the specialized model demonstrated

A demonstration by a model built specifically for SVG (Arrow) left a deep impression on those watching: a pelican riding a bicycle, its feathers traced stroke by fine stroke, the wheel spokes dense and deliberately exaggerated — a detail density far beyond the general-purpose models compared live alongside it. An assessment like “ten thousand times better than every model” is rhetorical exaggeration and should not be taken literally; what can be confirmed is only that, in the demonstration, its control over strokes and detail clearly exceeded the level people are used to seeing.

As for whether it is comprehensively stronger than general-purpose models, there is currently only a demonstration and no systematic comparison. That judgment should be left to actual samples of editability and output quality. A different trajectory is worth considering, though: this capability might be absorbed by frontier models and become part of general ability — there is already precedent of a model turning a photo into a line drawing via code. A specialized model’s room to survive depends on cost (small parameters, low training cost) and on whether it can occupy a stable position in design workflows. There are real signs on the demand side: a wave of AI products aimed at design and at replacing existing design tools is emerging, and they have a genuine need for a supply of editable vector assets — that may be the commercial reason for a specialized model to keep an independent form.

From icons to publishing illustrations

The value of vector graphics goes beyond icons. Print publishing is the most demanding scenario: illustrations headed to press must adapt to different layouts and paper, stay sharp at any enlargement, and remain editable in detail afterwards. Using image generation for book illustrations is not dependable; vector graphics are this industry’s native language.

Attempts to turn text into vector graphics automatically already exist. A service called Napkin converts selected text into diagrams, but its layout options are quite limited. If vector-generation models matured enough for wide use, there would be room to imagine new ways of illustrating print publishing — as of now, though, this remains speculation, unverified in practice.

Large-screen display is another natural scenario. From a phone icon to a conference hall’s big screen, the size span a single set of graphics has to cover keeps growing, and an infinitely scalable vector format is the only option that never needs redrawing.

The form it takes inside a workflow

Keeping a dedicated model around just for drawing SVG is unrealistic for most users. The more natural form is to provide it as an interface — an MCP tool or a similar skill call — so that existing agents can reach for graphics whenever they need them. One concrete gap is presentation generation: existing skills call an icon library to cover common needs, but when richer, more content-fitting graphics are required, the icon library runs out, and custom generation is exactly what fills that gap.

Custom generation for the moments icon libraries fall short, and the missing execution environment for design agents, are two sides of the same need: design work requires not just “generating an image” but a complete flow in which what is generated can be edited afterwards, dropped into layouts, and arranged alongside other assets. Whether models like this are useful comes down to two concrete things: whether the SVG they output is clean and editable, and whether it holds up under enlargement and modification in a real layout. Both questions are still waiting on more samples of actual output.

Sources

The difficulty of drawing icons and the SVG specialized model’s demo

Evaluating Models with Real Tasks

Mon, 21 Sep 2026 16:00:00 GMT

The same background-research task — searching the web for everything about a few specific people — handed to two different runtime frameworks produced wildly different results: one gave up after a quick look, at what the user estimated to be a twenty-out-of-a-hundred level; the other managed to find WeChat official-account articles that even a careful human would struggle to track down completely, and pulled back their full content. This was one case observed at recording time, but it points to a fact often overlooked in evaluation: what determines the result is not just the model, but also the layer wrapped around it.

The object of evaluation: model plus framework

The runtime framework is exactly that layer. Around the time of recording, an evaluation of coding frameworks compared precisely task completion rates and token costs: putting different frameworks into the same tasks to see who gets the job done with less consumption. In the results, the same model on a different framework could differ noticeably in cost; the efficient frameworks did not win by piling on features — they won with lighter prompts and only the necessary tools.

This is a reminder that whenever you cite any evaluation, what you are really reading is “how some model plus some framework performed on some class of tasks,” not “how strong some model is.” How many prompts a framework carries, its tool configuration, the weight of its architecture — all of it gets written into the final score. Discussing model capability apart from how it is used is like judging a car only by its engine specifications.

Perceived capability is not all capability

Public-facing model evaluation also faces an unavoidable constraint: ordinary users can only perceive what is visible. So evaluation demos keep escalating on 3D — it is complex enough, and both the process and the result are easy to verify at a glance. When one generation of models shipped, multiple public benchmark scores were already near perfect, so the community turned to 3D modeling and small 3D games to tell them apart, with a single game extension consuming only a small fraction of the subscription quota.

These demos have value: they turn abstract capability gaps into something you can verify with your own eyes. But what they measure is also the deliberately perceptible part. A model being excellent at 3D demos shows it invested training in a specifically reinforced direction; it does not show that writing, retrieval, or long-task execution is equally strong. A demo is a curated slice of capability; the parts outside the slice still need real tasks to fill in.

The quality of the questions determines the value of the score

Model vendors optimizing for public benchmarks is an open secret. One example mentioned in the discussion: after a coding benchmark released a new version, every vendor’s models performed well on the old questions, but scores dropped noticeably on the new questions that had not been chased yet, with only a few models holding steady across both versions. Whether a score holds steady is really a contest of the time gap between question-setting and benchmark-chasing.

So when reading benchmarks, it is worth asking one more question: how long has this question set been out, and has it been trained against? Performance on fresh questions carries more information than high scores on questions that have circulated for ages.

Different capabilities need different tests

Evaluation is not one exam; questions are set separately for each capability. In the impressions from recording time, writing and coding corresponded almost to two different groups of models: models leading the coding boards were not necessarily good at writing, and some models recognized for their writing did not owe it to their overall scores. Models good at writing were swapped in wholesale across a site’s content-production pipeline, while frameworks with strong retrieval were kept for research — each matched to a different test task.

The same goes for numbers vendors claim. One quantized small model announced that it retained 98.2% of the original model’s aggregate performance — that figure comes from the vendor’s own evaluation; whether it holds must be re-tested in your own tasks. The same model, on your data, your prompts, and your acceptance criteria, may perform worse — or better.

Rankings have ever-shorter shelf lives

Static leaderboards rest on one more premise that is failing: stable model versions. Shipping a Preview first to sound out reception, replacing version numbers with dates, announcing continuously updated online services — these practices keep multiplying, and some models update several times a week by default. Once version numbers vanish, leaderboards lose a fixed evaluation target — you can no longer pin a bad verdict on a particular version, and you cannot pin a good one on it either.

Rankings go stale fast, and the alternative way of verifying is more direct: free trials let every user form their own impressions at low cost, and feedback from real users in the community surfaces problems faster than leaderboards. Evaluation has not disappeared; it has dispersed from the hands of a few institutions into every real use.

The workable way to consume model information therefore becomes: first be clear about what your task is, then find the test or trial closest to it, and treat leaderboards as leads rather than conclusions. The unit of evaluation is ultimately the task, not the model’s name.

Sources

Before You Ask AI to Build a Game, Break the World into Scenes

Fri, 18 Sep 2026 16:00:00 GMT

Asking AI to build “a complete planet” sounds perfectly reasonable: isn’t there a planet in the game? One real attempt ended with a large amount of quota consumed and no planet built. The problem was not that the model wasn’t capable enough—it was that the task itself had been described incorrectly.

A Planet Is Not Modeled as One Solid Piece

Game worlds are never built at real-world scale. In that attempt, the requirement was “model everything on the planet,” but the game’s actual implementation was engineered: there is a planet on the outside, a cutscene plays when the player enters, and then the game loads one region at a time, each with boundaries. The complete visual impression is assembled from a planet shell plus five or six scenes inside it.

Asking a model to model a planet at true surface area is something AI cannot do—and neither can a human. “Build a planet” and “build a game world made of region-by-region loading” differ by several orders of magnitude in scope—the former is physically infeasible. The task description directly determines the size of the task, and whether it has a solution at all.

A wrong requirement costs more than just failure. From usage observations around the same period, one common complaint was that a two-hundred-dollar subscription quota ran out within a week, and the output still didn’t meet the requirements. The underlying causes were exactly this: asking for too much, lacking a clear concept of what to build, and people still using “you are a such-and-such” style prompt templates, spending large amounts of text constraining parts of the model that never needed constraining.

By contrast, another session cost far less: a small Roguelike game first consumed 3% of the quota, then was extended into an endless game in the vein of Vampire Survivors—constant enemy waves, leveling up, picking weapons—which took another 2%. That 5% of quota corresponds to a task with clear boundaries that can be described step by step. It should be noted that a subscription quota’s percentage is not a universal cost unit; it depends on the subscription tier, model pricing, and the specific task, and cannot be converted into “how much does it cost to make a game.” All it can convey is relative scale—with the same goal of having AI make a game, different task expressions can differ in consumption by many times.

Give the Model a Code Interface It Can Write To

Beyond how the task is expressed, the tool interface also affects the cost of this kind of work.

One reason the 3D modeling went so well this time was the scripting infrastructure Blender has accumulated over the years. The model didn’t build things by clicking around a graphical interface—it used bpy, Blender’s built-in Python API. It was writing code the whole time; the UI sat frozen on the welcome screen, and after a while it announced the model was done. Opening the file, the model was complete. The process required almost no screenshot-based confirmation, and token consumption was low.

Game engines have similar affordances. The Godot Engine also provides a programmatic interface; once the model finishes, you open the project and see the result directly, skipping the entire interface-manipulation process. For a model, describing geometry, lighting, and scenes in code is more precise and cheaper than clicking step by step through a GUI.

This points to one direction software could adjust toward: expose core capabilities as code interfaces the model can call directly, and leave the UI for humans to view interactions and content. Of course, this path depends on the software having a mature scripting interface in the first place—not every category of tool can copy it. In graphical creative software, the manipulation interface itself remains part of the expression.

From Digital Models to Physical Objects (An Extension)

The downstream of 3D modeling is 3D printing. Models for printing used to come mostly from the community, and when someone else’s model didn’t fit your needs, it was very hard to modify: one person made a charging dock clip that turns an iPhone into an alarm clock, modeled around the iPhone 18, and adapting it to a different phone model was nearly impossible. Once modeling capability is plugged in, this kind of modification can be handed to the model, and a printer’s companion software can be operated through computer control as well—lowering the learning barriers around loading filament, supports, and other operations that used to require dedicated study.

But successful modeling is only the first step. Materials, support structures, print settings—these physical-world factors still determine whether the final print works and how it looks. Between a digital model and a physical object there remains a stretch that requires hands-on verification; smooth modeling does not guarantee smooth printing.

Sources

The agent workflow behind a podcast episode: from recording to multi-platform publishing

Thu, 17 Sep 2026 16:00:00 GMT

For a podcast episode, the most time-consuming part is often not the talking. Recording software has to be launched, audio and video need to be edited, five platforms each have their own upload process, and the website needs a searchable transcript. None of these steps involves a line of code, and in the past every one of them had to be clicked through by a person.

This is the actual path one episode took from recording to publication. One caveat first: it is a retrospective summary of experience, not a how-to guide. Tools, interfaces, and platform rules are all changing, and a single case does not make a reproducible recipe. What it can show is which gaps Computer Use filled in, and what it left for humans.

The steps beyond writing code used to be done by hand

Once agents entered daily work, writing code itself became highly automated; the problem sits at both ends of the pipeline. Recording means opening local software, and publishing means operating a stack of unfamiliar admin consoles. These steps cannot be done by writing code, so the current task has to stop and the work switch to manual operation. Almost all of the interruption time in the workflow was spent here.

One practical approach was to simply hand the computer over to Codex: launching recording software no longer meant figuring out where the menus were yourself — the agent moved the mouse and clicked its way through. The same went for editing: when a graphical editing app felt awkward to use, switching to the FFmpeg command line actually returned the work to the mode agents are already good at. In the same round of experimentation, someone also had an agent submit the listing materials for two iOS apps and an Obsidian plugin item by item, doing only the final acceptance review personally.

The value of this kind of delegation is eliminating the switch. Tasks no longer break off because “this step isn’t code,” and you no longer have to relearn the operation of every piece of software.

Five platforms, one publishing run

The first episode went live on five platforms: Xiaoyuzhou, Bilibili, Spotify, Apple Podcasts, and YouTube. The person responsible for publishing had never used the creator console of any of them, and did not study each platform’s feature differences one by one — they only stated requirements and prepared the materials; the uploads and form-filling were done by the agent.

What this changes is more than time. One person maintaining five platforms used to mean five separate sets of procedures, and every new platform raised the cost again. When the operation itself can be delegated, the number of platforms no longer translates directly into workload, and the choice of where to publish can weigh the audience more heavily than the operating cost.

Worth noting, though, is the other side of the cost structure. This publishing run and the website build used the newest model released in that very period — more expensive per token, but with noticeably fewer retries and a higher chance of getting it right on the first attempt, so the total spend stayed under control. Tokens saved and person-hours saved are, in the end, the same thing.

The website and the searchable transcript

Beyond publishing, the website took on another share of the work. Every transcript segment carries a stable anchor, keywords in the text are clickable and aggregate under the same tag, and listeners can trace any passage back to its source. Features like these are uncommon in general-purpose podcast products, and the threshold for custom development used to be hard to cross; this time, the website went onto the same delegation list as the publishing.

For a podcast, a searchable transcript means the content can be cited on its own. When an article discusses a particular exchange, it can link to the exact passage instead of vaguely pointing at a whole episode — the links at the end of this article are exactly that usage.

A throttling with no answer

The workflow did not go smoothly everywhere. All five platforms accepted the episode, but one of them throttled it after the agent-published release. The cause was never verified: it could have been a judgment about the content, a detection of the publishing method, or entirely unrelated to automated operation. Attributing the throttling to automated publishing is, for now, only the publisher’s own speculation — it cannot be written up as a penalty reason confirmed by the platform.

What the incident did prompt is a discussion worth recording: if platforms want to push back against low-quality content, reviewing the content itself makes more sense than reviewing the act of publishing — the same show recorded by the same real people does not become low-quality because the publishing method differs. This remains an argument, not a description of any platform’s rules.

What remains for the human

Looking back over the whole chain, three human roles remain: deciding what content to make, preparing and vetting the materials, and accepting the final result. Which platforms to publish to, in what order, and whether to publish at all are all authorized by a person. What the agent covers is everything from launching software to clicking submit, after that authorization.

The sample here is one episode and one operator, so the conclusions should stay within the bounds of a single case. What it does show: when the operations beyond writing code can also be delegated, the most human-intensive part of the pipeline shifts from “operating” to “deciding.” Which platforms will tolerate this approach long-term, and how much time other kinds of shows could save, will take more episodes to answer.

Sources

Should a Small Team Still Write Its Own Agent Framework from Scratch?

Tue, 15 Sep 2026 16:00:00 GMT

Take apart an agent application built by a small team and the genuinely differentiated part usually turns out to be a very thin layer. The basic capabilities—the task loop, tool calling, context assembly—now have multiple off-the-shelf sources: vendors’ Agent APIs, continuously iterated open-source harnesses, CLIs that can be embedded into your own product. How much of writing a framework from scratch is still worth doing depends on what each of these alternatives has taken over.

The Loop Is Easy; Long-Term Use Is Hard

A working agent loop is not complicated: hand the task to the model, parse which tools it wants to call, execute, stitch the results back into the context, and run another round. What really separates the players is the detail accumulated through long-term use. Agents look simple, and extended use reveals how hard they are—the organization of sessions and projects, cache hit rates, optimizations that work in concert with the model, all of it hidden behind “it runs.”

Codex is a specimen of this kind of accumulated detail: it provides dedicated tools that can pull out all of its own Projects and Sessions, show progress and status, and even locate a reconnection problem that appeared somewhere inside a long conversation. These capabilities come from keeping complete records for model training from the moment of architectural design, plus continuous iteration over a long period. Even if a small team writes a loop of exactly the same shape, it can hardly invest the same level of maintenance across all of these details.

And the complexity keeps growing. A self-built harness usually starts from the simplest loop, then keeps acquiring features, and once it grows complicated enough it needs to be encapsulated—which is precisely one of the vendors’ motives for turning it into a managed service.

The Shell Involves More Work Than You Think

Once execution is handed to a mature framework, what an application team has left is often summarized as “building a shell.” That summary understates the workload of the shell, and one case of actual development makes the point: CodePilot originally adapted to Claude Code alone; back then the Agent SDK did everything else well and the team only had to mind the UI. But as the various frameworks waxed and waned, users switched from one to another from day to day, and the shell was forced to adapt to every backend: building runtime routing to dispatch user input to different CLIs and frameworks; handling each vendor’s incompatible API formats, return data, and billing schemes; and on top of that the product’s own distinctive features and legacy debt—the adaptation work kept snowballing.

Deepening vendor lock-in makes the problem worse. Agents are binding ever more tightly to their own models, the various coding plans are mutually incompatible, and adaptation costs keep climbing. The “adapt to everything” shell grows more and more painful to maintain, yet nobody dares adapt to only one vendor—the one being mocked today may turn the tables a few days later on the strength of quotas or capability.

Three Options, Three Scopes of Responsibility

There are at least three possible routes, each with a different scope of responsibility.

The first is the managed service. An Agent API or an official harness packages the model, the tools, and the execution environment into a closed loop, and the team simply calls the service. The price is deep binding: the model and the agent are co-optimized as a matched pair, and people who support the official pairing often cite the cache-rate example—the same model gets better cache hits inside the official host, though the exact numbers vary depending on who is telling it. The advantage of the pairing also extends to integration coverage: in Chinese information retrieval, the plugin for DeepSeek’s official pairing can reach content that external tools cannot, such as the full text of WeChat official accounts.

The second is the SDK and the CLI. You embed the execution engine into your own product; the model and the base loop are maintained upstream, while the runtime shape, the interface, and the data remain under your control. This is the middle path, but following upstream is itself a burden: the DeepSeek Harness ships a dozen or more versions in a single day, and when the layer underneath a plugin moves, everything on top breaks; GUI adaptations die the moment the host interface shifts, which is why the community consensus has become to build against more stable exposure surfaces like MCP or the CLI; and if you want stability, you do what Linux users did in the early days—wait for someone else to package a distribution.

The third is building from scratch. It has not become pointless—when the execution environment is unusual, the security boundary is strict, or the product is itself a piece of framework research, building your own is still reasonable. But for most user-facing applications, the basic execution capabilities already have cheaper sources, and the criterion for building in-house has shifted from “no one else has it” to “does this layer really differentiate the product.”

After Handing It to Infrastructure

A further idea is to treat the entire execution layer as infrastructure: in the past, building an internet service meant renting a host from a cloud provider to deploy your program; in the future, what you rent might be an “agent host” or an agent environment that drives a large share of the business. The analogy is still a vision rather than reality, but the directional signals have appeared—agents are increasingly treated as a technology rather than a product, users no longer care which model is behind the scenes, and services expose only what is distinctive about themselves.

For application teams, what actually remains is, paradoxically, clearer than before: product definition, interface, vertical data and context, evaluation and delivery. Looking back, the investment many teams made over the past year in building their own harnesses resembles tuition paid—tuition that bought the ability to answer a question honestly: outsource the execution capabilities that can be outsourced, and concentrate resources on the layer that no one else can replace. As for which layer is irreplaceable for you, every team has to answer that with its own scenarios.

Sources

The Model Name Didn't Change — So Why Did the Workflow?

Mon, 14 Sep 2026 16:00:00 GMT

An API model once had only two fixed names for a long stretch: one for chat, one for reasoning. Callers wrote their prompts against the names and got their pipelines working — until one day the output was off. The name had not changed; the model behind it had been swapped, with no notice of any kind. This was the common experience in the year before recording, and it is where many “models got dumber” discussions started.

A model’s name is the most basic contract between users and the service. To discuss why that contract has loosened, we need to separate the things that have been bundled together.

Version numbers are disappearing

Rolling releases are becoming the industry default. Vendors ship a Preview first to sound out reception; some replace version numbers with dates; some announce continuous online updates with no more version numbers, updating several times a week by default. For vendors, this exposes the pace of post-training iteration directly to users; for users, it means “which model am I actually calling” no longer has a definite answer.

For evaluation this is double-edged: you can no longer pin a bad verdict on a particular version — and you cannot pin a good one on it either. A fixed public belief like “that version of the model was strong” is losing its carrier.

How loosely a vendor treats names follows the weight of its business model. The same vendor, when it released models early on in a “just try it” spirit, largely ignored user demands; as commercialization deepened and it began serving enterprise customers, its responsiveness to feedback visibly improved, and controversial changes got rolled back. The closer a model service comes to being public infrastructure, the less the stability of its name is a technical detail — and the more it is a promise.

Four things behind one name

What users perceive as “it changed” is really four different things, each changing on its own.

First, updates: the backend model is quietly replaced, and behavior changes with it. Fixed names were designed so callers could upgrade without noticing; the price is that behavioral differences are left for users to discover on their own.

Second, routing: in a controversy shortly before recording, a model ID was temporarily pointed at another, cheaper model, then switched back a few days later. Name, price, and actual model briefly fell out of sync — and for anyone programming against the name, that is an interface change. Though brief, the discussion still flagged the difference in kind: continuously updating your own model is one thing; pointing an ID at a different model is another — the former is iteration, the latter changes what the name itself means.

Third, pricing: enterprise-facing services need stable prices. When models roll update after update, how are ten thousand enterprises supposed to adjust their pricing and budgets along with you? It is a genuine burden. That is why some argue that vendors that want enterprise revenue need to offer stable versions; those unwilling to are effectively ceding that market to third parties — and third-party resale usually pays for it in speed and cache efficiency.

Fourth, compatibility: prompts, plugins, and workflows are all built on specific behaviors. Worth noting: the share of a product’s behavior driven by prompts has actually declined over the past two years, as more constraints get internalized into the model; but workflows’ dependence on predictable behavior has not fallen — it has risen.

The “got dumber” debate: start with checkable observations

In the same period, “models got dumber” discussions kept resurfacing in the community. The impression itself deserves to be described precisely first: the same model, well reviewed at launch, is later widely judged worse than before. The explanations in circulation include routing simple questions to smaller models, throttling the amount of thinking, adjusting output strategy, and so on. These come from the community’s reverse-engineered guesses about the service; no vendor has confirmed them, and they cannot be treated as conclusions. The confirmable facts are far fewer: quality problems caused by bugs did happen — users reported them en masse and the vendor investigated and fixed them; restrictions on abnormal usage patterns are product policy, a separate matter from model capability; and users’ felt experience is real and deserves to be taken seriously.

Accusing vendors of “deliberately dumbing the model down” is hard to prove and does not help solve the problem. What is actually missing is evidence: outputs from the same task, the same settings, at different times. Only with that comparison in hand can you distinguish whether the model changed, the routing changed, or the way you use it changed. Community sentiment reacts fastest in this process, but the sample is biased — good as a lead, not as an attribution.

Keep your failure cases

For workflows that depend on models, the workable move is to fill in what the vendor does not provide: record the version info, parameter settings, and outputs of every call. When something goes wrong, check the records first to confirm “what changed,” then decide whether to change the prompt, lock in a third-party stable version, or adjust the pipeline. Providers running internal evaluations need the same thing — reproducible scenarios, not conclusions drawn from a single experience.

Model names will most likely keep getting more abstract — dates, codenames, continuously updated major versions. Once the contract loosens, part of the responsibility for reliability shifts to users: whoever keeps the records is the one entitled to judge “what exactly changed.”

Sources

Cheap Models Are Opening Up New Use Cases

Sun, 13 Sep 2026 16:00:00 GMT

A video plays while it is still being generated, with the visuals following the narration; interrupt it mid-stream, ask a different question, and the picture restarts immediately. This real-time demo, captured at recording time, was powered by MiniMax’s accelerated models together with fal.ai. Similar demos had appeared before, but most stalled at the private-beta stage: compute consumption was staggering, open access was limited, and generation quality could not sustain real use. The difference this time is that cost and quality crossed the line at the same moment — the visuals became, at minimum, watchable, and by the estimate at recording time, inference costs had dropped to a level that could support an all-day livestream.

The first thing falling prices change is not how smart models have become, but which tasks start to be worth handing to them.

Trying itself has a cost

Whether a new model makes it into real use often depends not on benchmark scores but on whether users are willing to spend time trying it. Trying a model means buying quota; if you cannot afford it, you may simply never try. A capable-but-expensive model goes unnoticed because nobody can afford to use it. At recording time, several Flash-tier models were free to try, and the reasoning behind that was exactly this: only when users form their own impressions do real cases emerge from the community — a loop more effective than advertising.

Products have adopted the same logic. Some rotate free models daily, letting users give direct feedback on which ones worked and which did not. By the operators’ observation, this kind of real feedback is more accurate than leaderboards, and models that performed well during their free periods did retain users. Free lowers not only the monetary cost but also the psychological cost of “wasting an afternoon picking the wrong model” — only when trying becomes nearly free do models genuinely enter ordinary users’ shortlists.

High-frequency, low-risk tasks get handed over first

The first tasks cheap models take over are the ones with low value per call and high repetition. Replying to a single message with a pricier model is fine, because it happens only once; but let an agent run a whole task while calling a frontier model at every step, and the cost quickly becomes unmanageable. The savings on any single call look trivial; in high-frequency settings they become the decisive difference.

Speed amplifies that difference. At recording time, one user described the experience of writing code with a Flash-tier model: several hundred tokens of output per second, and if a version was not right, just start over immediately. Once things are fast, the human’s role shifts from waiting to filtering — a user with professional judgment can push a seventy-or-eighty-out-of-a-hundred result up to ninety-five, provided the iteration pace keeps up with their thinking. This is still a single case, but it points to where cheap models really shine: not replacing the best model, but making “try a few more times” affordable.

Being cheap does not mean one-sided compromise, either. Some users found that certain Flash-tier models were actually less sycophantic: they held their own arguments, said plainly when they disagreed, and only then helped carry the task out. Beyond output quality, this willingness to say “that’s wrong” is part of why some users are comfortable handing their daily tasks to these models long-term.

Expanding downward, not competing upward

Understanding cheap models as low-cost stand-ins for frontier models understates their impact. A more accurate description: cheap and open-source models do not compete for top-tier capability; they expand downward — more people, more scenarios, more experiences of actually using models. Things once priced out of reach — real-time video generation, assistants called many times a day, tidy-up tasks running on your own device — are becoming routine one by one.

This explains why so many vendors launched Flash-tier models in the same period. The name borrows the connotation of “fast,” but the actual positioning is already a small, low-cost, always-available tier: fewer parameters, faster output, lower prices, with capability retained as much as possible. Some large models, precisely because they are too big and expensive to run, must spin up a smaller tier to cover high-frequency scenarios.

The rise of cheap models does not threaten the frontier models’ position, either. Work that must be solved in one shot, where every extra revision costs, still deserves the strongest model; the two kinds of demand sit at different layers of the same pyramid. The deeper cheap models penetrate, the more likely the people at the bottom convert upward and start paying for higher value.

Scenarios open up, but the task remains the boundary

Being cheap opens the door; the road beyond it is still determined by the task. However smooth the real-time video demo, there is a cap on generation length per run; Flash models are fast enough, but once output gets faster, people run more attempts, so total consumption does not necessarily fall. Letting agents automatically switch between models at different price points is the natural next idea, but it is still not easy today: deciding which model a task should use is itself a hard problem, and most of the time it is still humans doing the switching.

For users, the more workable question is not “which model is strongest” but which judgments in your own tasks are high-frequency, low-risk, and batchable — those are the first spots worth handing to cheap models; the steps that need an answer in one shot, where mistakes are costly, belong to stronger models. What cheap models open up is a set of scenarios, not a takeover of all tasks.