Claude Duet starts work before you ask

Claude Duet gets proactive

An assistant that starts work while you're away could clear your to-do list, or leave you with another pile of decisions. Claude Duet puts that trade-off into a working preview.

Our main story today is Claude Duet, and whether an assistant that watches for work can save organisations more attention than it consumes. Anthropic opened its waitlisted preview on 21 October, bringing a different rhythm to the familiar exchange between a person and an AI assistant.

Duet monitors connected work apps, prepares tasks and keeps working in a cloud-hosted browser after you step away. The shift is in who gets things started. You don't have to notice every piece of work, describe it in a prompt, then sit there while the assistant handles it. Ongoing observation and preparation become part of the service.

That's an appealing proposition for administrative work. Finding the task can be part of the task: reading a conversation, recognising that something needs a response, and assembling enough context to prepare one. If an assistant can do that reliably, the person comes back to work that's already been advanced. There's less restarting from a blank page.

Anthropic describes a clear division of authority. Duet can read, draft and prepare independently. Sending messages, making payments, signing documents and deleting material require approval. That gives the assistant room to make progress while reserving those consequential actions for the user. A prepared response can be useful even when you want the final say over what leaves your account.

The interesting design question is what arrives at that approval point. A well-prepared proposal could be quick to assess. A proposal based on the wrong reading of a conversation could send you back through the original material to work out what happened. Both create activity; only one saves much attention.

Anthropic acknowledges that Duet can misread conversations or urgency. Those are especially relevant limitations for a proactive assistant, because choosing what deserves action comes before drafting the action itself. Misjudging urgency could put an unimportant task in front of you while something else still needs your attention. The quality of that prioritisation will shape how useful the background work feels.

There's also a visibility gap in this preview: Duet can't yet show users its browser. You therefore don't get that view of how the cloud-based work is progressing. For an organisation evaluating this workflow, that affects how easily someone can understand a proposed action when the result needs a closer look.

Access is initially limited to US Pro and Max subscribers admitted through the waitlist. Australian subscribers don't have access through this launch, and broader availability hasn't been announced. Background checks also consume the existing subscription allowance, so the cost of keeping an eye on work shares a budget with the tasks you explicitly request.

My test for Duet would be the amount of attention left over after a day's work. How often does a prepared task need only a quick decision, and how often does it require reconstructing the conversation? Organisations could gain something valuable here: less effort spent noticing and preparing routine work. The strongest sign of success would be fewer things you have to keep in your head, alongside useful work ready when you return.

Railway's secret-exposure investigation

We'll leave Duet there; the shorter news starts with something more immediate for developers running applications on Railway.

Railway disclosed possible unauthorised access to customer environment variables on 21 October, including decrypted contents for some variables. Its initial assessment pointed to a subset of users, with the full scope still under investigation. The company recommended precautionary credential rotation for all users, along with a review of logs.

Environment variables are values an application receives from its hosting environment. They can include the credentials that let it connect to other systems: an AI service's API key, a database password, or access to a private software registry. Those connections are why a hosting incident can reach beyond the application running on that host.

For a developer, the practical work follows each credential to the service it opens. Rotating a database password means replacing that credential and updating the application that uses it. An AI API key belongs to a different service and needs its own replacement. Reviewing the relevant logs helps establish whether those connections have been used unexpectedly. Railway hasn't yet established which secrets were accessed across the full affected population.

Deployment recovery is progressing. At 8:59 am Sydney time on 23 October, Railway's update said builds were enabled for Hobby, Pro and Enterprise customers. Free and Trial builds remained paused, as did new signups. That timestamp is useful if you're comparing the report with what your account can currently do.

Restored builds let affected developers resume deployment work. Credential rotation addresses the separate question of access to connected services. A build completing successfully tells you the deployment path is functioning; the credentials inside that deployment still need the attention described in the disclosure.

For organisations using managed hosting, my takeaway is that the list of secrets stored there is also a map of potential dependencies in an incident. An application might be modest, yet hold access to a database, model provider and software registry. Knowing which credentials belong to which service makes the recovery work much more concrete, and helps avoid overlooking a connection once the application is running again.

NVIDIA maps business meaning

Getting an agent into company systems is one job. Helping it understand the records is another useful piece of work.

NVIDIA expanded its Agent Toolkit on 21 October with Agent Knowledge Foundation. It brings together retrieval, prediction from structured data, and libraries that map business records into concepts an agent can use. The aim is to give agents a better foundation in an organisation's own information.

One component is called Auto-Ontology. An ontology is a map of concepts and their relationships: customers, products and orders, for example. It gives software a way to connect a record to its business meaning, rather than treating everything as another passage of text to retrieve.

That distinction is useful. Finding a document that mentions an order can answer one kind of question. Understanding how an order relates to a customer and a product can support questions that cross those records. Retrieval helps locate relevant information; the concept map helps describe how pieces of information belong together. Structured-data prediction adds another component for working with those records.

Auto-Ontology generates an initial map. NVIDIA's documentation gives business experts the job of testing, refining and certifying it. That leaves an important part of the work with people who understand how the organisation operates. A label can be easy to recognise while its exact meaning still depends on the business using it.

Consider the ordinary word customer. A business may need to distinguish the person using a product from the organisation paying for it. That's an illustration of the kind of meaning a useful map has to preserve. Automatically identifying a customer concept is a starting point; getting the relationships right is what makes it useful in a particular organisation.

NVIDIA says the components can work with existing data platforms and agent frameworks, and names integrations and deployments involving Palantir, Databricks and Snowflake. Organisations can evaluate these pieces alongside their current systems, while preserving access controls over the underlying records.

I'd put the opportunity in reducing translation work between business knowledge and software. More documents alone won't resolve an ambiguous relationship between records. A tested map could make agents more useful on questions that depend on those relationships, and make the contribution of business experts easier to reuse across agent projects.

Node.js security updates

There's some less glamorous engineering news that deserves a place beside all these new agent tools.

The Node.js project issued security updates on 21 October for its 22, 24 and 26 release lines. They include a fix for a high-severity vulnerability in Brotli decompression that can permit remote code execution. The published fixed releases are 22.23.4, 24.22.1 and 26.12.1.

Brotli is a compression format. A decoder takes compressed data and expands it for the program using it. In this case, the advisory describes an out-of-bounds write: the decoder can write beyond the memory area intended for that operation. That memory error is the route to the serious consequence described in the advisory.

The flaw affects all three listed Node.js lines. Whether a particular application exposes the vulnerable decoder to an attacker depends on how it handles input. That makes the data path relevant: which parts of the application accept compressed material, and where is it decoded? The fixed runtime removes the vulnerable implementation from that path.

The update also addresses hostname-verification and permission-model flaws. So there's more in this release than the Brotli fix, even though remote code execution is the most consequential headline. The practical target is the Node.js runtime your service actually uses, including the copy inside a deployment image.

This can be easy to miss when application maintenance centres on package updates. Application dependencies and the runtime are separate layers. Updating the packages listed by your project doesn't replace Node itself. Likewise, changing the runtime on a developer's machine leaves a deployed image unchanged until that image is updated and deployed.

For developers building agent features, I'd give this the same priority as maintaining the systems the agent can call. A new model or workflow still runs on ordinary software infrastructure. The concrete completion check is the runtime version in the running service, because that's the copy processing its data. That keeps the maintenance work tied to the deployed application, where the fix is needed.

Google buys electricity flexibility

Now to the electricity behind computing, and a deal that gives flexible demand a bigger commercial role.

Google and Voltus announced an expanded agreement on 22 October to bring together flexible electricity capacity from homes and businesses in the US PJM grid region. Google describes the planned portfolio as a one-gigawatt virtual power plant, expanding an earlier agreement for 100 megawatts.

A virtual power plant coordinates lots of separate assets so they can help the grid at the same time. Here, those assets include batteries, thermostats and industrial equipment. The useful service is reducing grid demand during peaks, with participants receiving payments or savings on their bills.

The mechanism makes the name easier to understand. A battery can contribute stored energy; adjustable equipment can change when it draws power. Coordinating those choices can reduce the amount the grid needs to supply at a busy moment. The portfolio's value comes from bringing many smaller contributions together when they're useful.

Google is committing funding to that flexibility as part of meeting its data-centre power needs. For the owners of participating equipment, it creates a commercial opportunity around when electricity is used. A household or business with suitable assets may have something valuable to contribute without being a conventional electricity producer.

Timing is central here. A gigawatt is a measure of power capacity; the contribution over a day also depends on how long that capacity can be delivered. The announcement concerns procuring and coordinating capacity, with a full delivery timetable and price still undisclosed. Those details will determine how the planned resource fits into actual grid demand.

The companies describe the scale slightly differently. Google calls it one gigawatt; Voltus refers to an additional 1,070 megawatts beyond the earlier 100. The exact total remains unresolved, though both descriptions put this in gigawatt-scale territory.

What interests me is the way this spreads part of computing's electricity expenditure beyond the data centre. Companies expanding computing capacity have a reason to pay for flexibility elsewhere on the grid. For participating businesses, being able to shift demand could become a more valuable asset in its own right, alongside the equipment's everyday job.

Australia's iPhone distribution order

Back in Australia, an iPhone ruling puts a date on a potentially significant change in how apps reach people.

On 22 October, the Federal Court ordered Apple to permit competing app stores, direct app downloads and alternative payment services for users with Australian accounts. The broader changes are scheduled for 1 March 2027. These orders set remedies following the competition findings made in 2025.

There are three practical choices in that list. A developer could distribute through a competing store, offer a direct download, or use an alternative payment service. Those options affect how an app reaches its audience and how the developer collects payment. Security scanning and notarisation remain permitted under the orders.

For iPhone users, the useful date is March, rather than an expectation of new stores appearing immediately. Apple told Reuters it intends to appeal and seek a pause, according to MacRumors' report. Those proceedings could affect implementation; the reporting hasn't established that a pause has been granted.

More routes to customers could give developers more room to compete on distribution and payments. Whether that produces cheaper apps will depend on the arrangements that emerge and on developers' pricing choices. The tangible prospect for Australian users is a wider choice of where to get apps and how to pay for them, with the implementation timetable now worth watching.

Spotify filters recommendation spam

Finding something worth listening to is its own technology problem, especially when a catalogue keeps filling up.

Spotify reports that it excluded more than 50 million tracks categorised as slop or spam from recommendations during 2026. The figure appeared in its 20 October progress report. Separately, it reported removing more than 75 million spam tracks from the service.

Those numbers describe different actions. A recommendation exclusion reduces a track's access to algorithmic and editorial discovery while allowing it to remain in the catalogue. Removal takes it off the service. Keeping that distinction clear helps explain how Spotify is managing what listeners encounter, as well as what it hosts.

Its detection combines listening behaviour, upload patterns and metadata with external AI-detection tools. Spotify hasn't disclosed how many of the 50 million excluded tracks were AI-generated, or an independent false-positive rate. The headline count therefore describes a recommendation-filtering effort spanning slop and spam.

For listeners, that filtering can shape the experience without any obvious change to the size of the catalogue. For artists, a classification decision can affect whether a track gets discovered even if it remains available. That's where I see the consequential trade-off: filtering can make recommendations more useful, while a mistaken classification can cut an artist off from discovery. Accuracy at that decision point matters to both groups.

What Changes for You

If you'd rather keep coding prompts on your own machine, there's a new option with a fairly demanding hardware entry point.

Recursive released Flint's coding-model weights under the Apache 2.0 licence on 21 October, alongside local inference tooling. Developers can download and run the model, and OpenHands confirmed support on launch day. That makes an on-device coding workflow available for repository investigation, bug fixes and tests.

Flint is text-only and supports reasoning and tool calls. It has 39.8 billion parameters in total, with roughly 2.5 billion active for each token it processes. That smaller active portion describes the work happening per token; the complete model still has substantial hardware needs.

Recursive's rec launcher connects Flint to Pi or OpenCode. Its documented Mac requirements are an M4 Pro, M5 Pro or M5 Max, at least 48 gigabytes of unified memory, and about 30 gigabytes of free disk space. That puts the immediate audience among developers with fairly capable machines already available.

The practical change is where inference happens. Prompts can be processed on your device without being sent to a remote model service, and without a charge for each API call. Hardware, setup and review time remain costs. The surrounding coding agent also retains its own execution permissions, so local inference leaves the question of what commands it can run to the harness you're using.

There's one specification to check against the exact setup: the launch post advertises context up to 512 thousand tokens, while the model card documents 262,144. The checkpoint and runtime determine the capacity available to you.

For a developer with compatible hardware, the appeal is more control over source-code handling and recurring inference costs. The useful comparison is the work Flint can complete in your repositories, including the effort to review its code and tool calls. Owning the inference setup gives you a different cost structure and a local place to process the work.