Claude's price cut, robots learning new tasks and Waymo's software review

Claude's new price and access split

Anthropic's latest AI release makes difficult technical work cheaper to attempt. It also puts two versions of the same underlying model behind different access rules.

Our main story today is Claude Fable 5.2 and Mythos 5.2: how the new prices, safeguards and data terms change the choice for organisations doing demanding engineering work.

Anthropic released both on 9 November. Fable is available across its platform and major cloud providers for advanced technical work. Mythos uses the same underlying model, with different safeguards, and requires verification for cybersecurity or life sciences. Access to Fable gives you a route into the new model family; Mythos has its own eligibility process.

That arrangement is an interesting part of the release. Two product names can suggest two different levels of intelligence. Here, the underlying model is shared, while the safeguards and access conditions differ. Fable retains stronger safeguards around cybersecurity and biology. For an organisation choosing between them, the work it wants to do is central to which product it can use.

The standard API price is eight US dollars per million input tokens and forty dollars per million output tokens. Tokens are the chunks of text a model receives and produces. Optional fast mode doubles those rates to sixteen dollars for input and eighty for output.

Those separate input and output prices matter for technical work. A request that supplies a large amount of code and asks for a short answer has a different cost shape from one that produces a lengthy implementation. The number of requests is only part of the bill. How much material goes in, how much comes back and which mode you choose all contribute.

Anthropic reports output speeds up to thirty per cent faster than its 5.1 models. Faster output could make an engineer's interaction feel more responsive, particularly during a long answer. A complete coding job also includes running tools, checking the result and making any corrections. The useful measure for that engineer is how long it takes to reach a result they can use.

I'd assess the lower prices in much the same way. Cost per completed job captures whether a difficult task became more affordable. It also gives an organisation a sensible way to compare standard mode with the more expensive fast option. A time-sensitive task and an overnight job may justify different choices, even when they're using the same model.

There's a concrete data-handling condition alongside the pricing. Anthropic specifies thirty days of safety-monitoring retention for customers outside eligible zero-data-retention arrangements. That affects which internal material an organisation can send, especially when its own rules limit how long another service may hold it.

Anthropic also has Enterprise Frontier Safeguards in private beta. That arrangement runs monitoring over data stored in the customer's infrastructure. For organisations assessing the release, it's a separate option to investigate, with private-beta access still a practical limit. The generally available model and that monitoring arrangement are at different stages of availability.

For an engineering leader, I think the opportunity is to revisit demanding coding or research work that was previously difficult to justify at the price. There's now a lower-priced option to put against those jobs. The decision can stay specific: the task, the permitted data, the access route and the cost of a usable result.

That leaves room for different answers inside one organisation. An engineer working with shareable code may be able to use Fable immediately, while a project involving restricted research or tightly controlled material has additional conditions to resolve. The release expands the available choices, and the useful purchasing decision starts with the work already waiting to be done.

Google's specialised TPU systems

That covers the model choice; the shorter stories start one layer down, with the hardware that runs it.

On 9 November, Google announced TPU 8tx and TPU 8i Max. These are two specialised system configurations built around its existing eighth-generation TPU silicon. A TPU is Google's accelerator for machine-learning workloads.

The two configurations address different constraints. TPU 8tx combines TPU 8t silicon with fifth-generation AMD EPYC host processors and hardware-level confidential computing. The design is intended to protect data and model weights while they're being processed.

That last part is useful to understand. Data can be protected while it's stored and while it's travelling between systems. Inference, the process of running the model to produce an answer, also requires computation on that information. Confidential computing addresses protection during that processing stage. Model weights, the learned values that drive the model's behaviour, are included in Google's stated design.

For an organisation handling sensitive inputs, that puts another part of the computing environment into the purchasing discussion. The model service, the host and the accelerator together determine how the workload runs. A hardware configuration designed around confidentiality could become relevant where protecting the input or the model itself is a central requirement.

TPU 8i Max takes a different approach. It packages two TPU 8i chips together. Google reports twice the compute, twice the SRAM and twice the high-bandwidth-memory bandwidth of TPU 8i. SRAM is fast memory close to the processing hardware; memory bandwidth describes how quickly data can move to where it's needed.

Larger contexts give a model more material to work with in a request. Serving those requests puts memory and data movement alongside computation as things an infrastructure buyer has to consider. Extra arithmetic capacity is useful when the workload can use it; extra memory resources and bandwidth address other parts of the job.

My reading is that these configurations give buyers a more practical set of questions than a single performance ranking. Does the workload need stronger protection during processing? Is it constrained by memory or by moving data? Those answers could lead to different systems, even for applications using similar models.

Google hasn't established pricing or a general-availability date for either configuration in this announcement. That keeps them in the planning and assessment category for now. An infrastructure team can map them to the workloads it expects to run, but a purchase comparison still needs the commercial terms and delivery timetable.

Robots learn from fewer demonstrations

Robots make the cost of learning a new task especially tangible: someone has to show them what to do.

NVIDIA introduced GR00T 2 at the Conference on Robot Learning on 9 November. The research combines predictions of future video with predictions of robot actions, aiming to transfer skills from human demonstrations and across different robot bodies.

The mechanism is the interesting bit. A robot has to relate an action to what happens around it. Predicting the visual result alongside the action connects those two parts of the problem. And transferring learning across bodies addresses another difficulty: a demonstration from a person, or a different robot, doesn't arrive in the exact form a particular machine needs to execute.

NVIDIA evaluated the system across fifty tasks. It reports average success of forty per cent without demonstrations of those tasks on the target robot. After five demonstrations per task and task-specific fine-tuning, average success reached ninety-five per cent.

That's a substantial change within the evaluation. It also describes a useful sequence: start with a model that has broader prior learning, give it a small amount of material for the particular task and robot, then adapt it through additional training. The five demonstrations sit inside that larger learning process.

Fine-tuning is the adaptation step. It changes the trained model using the task-specific examples. So the result gives robotics developers a concrete combination to examine: how many demonstrations were needed, what adaptation followed, and how successfully the robot then performed.

A practical attraction is the amount of robot-specific teaching. If you can adapt a system with a handful of demonstrations, the effort required to introduce another task could fall. That could change the economics of deploying robots for a range of jobs, where each additional task otherwise brings another round of data collection and training.

For developers, I'd put the strongest emphasis on that adaptation cost. A system that learns a new task with less specialised data may be useful even before you consider expanding the number of tasks it can handle. Less teaching effort could leave more time to refine the operation around the robot.

The reported ninety-five per cent comes from NVIDIA's controlled fifty-task evaluation. Reliability in a particular deployment remains something to establish for that setting. The immediate timing limit is straightforward: the research page says code will be available in December. Public reproduction has to wait for that release.

When it arrives, the valuable comparison will include the demonstrations and fine-tuning needed for a developer's own robot. That is where this research could turn into a shorter path from choosing a task to having a machine perform it.

Waymo's school-bus remedy under review

Once a robot is operating on public roads, the follow-up to a software change becomes a much bigger deal.

The US National Highway Traffic Safety Administration has opened a review of whether Waymo's remedy for passing stopped school buses was effective. The review began on 6 November and was widely reported on 9 November.

It covers two thousand eight hundred and ninety-five vehicles equipped with Waymo's fifth-generation automated driving system. The regulator says most of the identified incidents happened after the reported completion of the software remedy on 17 November 2025.

That timing is the reason for the new scrutiny. A remedy had already been deployed for the school-bus behaviour, and the regulator is now examining its adequacy. The central question is whether that change addressed the behaviour it was intended to correct.

Waymo told Reuters that it had improved its school-bus behaviour and had received no citations since March 2026. The investigation is ongoing, including the causes of the incidents after the remedy and whether further corrective action is needed.

For people following autonomous driving, the concrete development is a formal review of an existing fix. The affected population is defined by the fifth-generation system, and the focus is a specific interaction with stopped school buses. Keeping those details in view makes it easier to understand what the regulator is investigating as the case progresses.

For organisations operating automated systems, I'd take a practical lesson from the shape of this review: the evidence after deployment belongs with the fix. A completed software rollout records that a change reached the vehicles. Observations of the relevant behaviour then help establish how well that change worked.

That makes follow-up a continuing engineering job. In this case, it means accounting for school-bus incidents after the remedy and explaining what they reveal about the system's behaviour. The regulator's finding about their timing is consequential precisely because a remedy was already in place. The review can now determine whether that remedy needs further work, with the final outcome still open.

Instagram expands teen detection

A quieter change could affect the settings people encounter when they open Instagram.

On 9 November, Meta announced a worldwide expansion of AI age estimation on Instagram. It is intended to identify suspected teenagers who entered an adult birthday and move them into Teen Account protections.

Those protections already exist. They restrict contact, content and time-related settings. The new development extends detection, so more accounts may receive those settings even though the birthday supplied by the user hasn't changed.

That shifts some of the practical importance from what a person enters during sign-up to how the service classifies the account afterwards. For a parent or teenager, the visible effect may be a different set of account restrictions. The mechanism behind that change is an estimate of age, alongside the declared date of birth.

Meta also says it has begun using Apple's age-range signal in Australia as another input to age assurance. Participation in that signal remains optional. It gives the service an additional age-related signal to consider alongside its other inputs.

I can see the value in reaching teenagers who would otherwise miss those protective defaults. As detection expands, correcting a mistaken classification becomes more important too, because the classification changes how someone can use the account. Meta hasn't supplied a false-positive rate in this announcement.

The useful distinction for Australian users is that the global detection expansion and the optional Apple signal are two parts of the age-assurance approach. An account's supplied birthday is no longer the only information that can lead Instagram to apply its existing teen settings.

OpenSSH exploit needs a specific configuration

For anyone responsible for Linux servers, there's a security fix with a very specific scope.

GreyNoise recorded successful exploitation of an OpenSSH authentication bypass on a vulnerable sensor on 7 November. OpenSSH had released its 10.6p2 fix on 5 November. The practical concern is unauthorised access through the server's password-authentication path.

The affected setup uses musl-based Linux without PAM, the authentication framework used by many Linux systems. Password authentication has to be enabled. A login-capable account must have an asterisk in its password field, and another account must supply a suitable password hash. Those conditions together define the vulnerable configuration.

A password hash is the stored representation used to check a password. Here, the relationship between the account fields and the authentication configuration is important to identifying exposure. Administrators can narrow the investigation to systems that match those conditions.

Alpine Linux's advisory covers releases 3.16 through 3.24 and its edge branch. Fixes have been packaged for multiple branches, including backports. That means an administrator can use the patched package appropriate to the installed Alpine branch; the upstream release number alone doesn't describe every fixed Alpine package.

The advisory also makes the exclusions concrete. Alpine containers without the SSH server daemon are unaffected. Systems with password authentication disabled, and the PAM-enabled configurations described in the advisory, are outside the affected setup.

For an exposed system that matches, the required response is to install its appropriate patched package and restart the SSH server daemon. Both steps count. Replacing the package leaves the old daemon running until it's restarted, so a package update on its own doesn't finish the job.

I'd prioritise the internet-facing systems that actually match this configuration. The confirmed exploitation gives those administrators a reason to act promptly, while the prerequisites let them avoid treating every Linux host as the same case. The finishing check is that the running SSH service is using the patched software.

What Changes for You

There are also two releases you can put to work now, depending on whether you're building with AI or creating images.

Meta released Muse Ember on 9 November for repeated tool calls, coding subtasks and document processing. It's available through Meta Model API, Muse Code and Vercel's AI Gateway, with a one-million-token context window.

The developer pricing page lists ten US cents per million input tokens and fifty cents per million output tokens at the base tier. Above two hundred thousand context tokens, those rates rise to thirty cents and a dollar fifty. That higher tier is relevant if you're choosing Ember to process large amounts of material.

For builders, the opportunity is to assign routine steps to this lower-cost hosted model and reserve a stronger model for the steps that need it. Ember is proprietary, so access is through a service. The practical saving depends on which parts of your workflow it can complete at the required quality.

For visual work, OpenAI released Images 2.6 on 4 November, globally in ChatGPT and Codex across subscription tiers. GIF creation and photo markup are available in ChatGPT and the API. Markup lets you indicate particular areas for revision, giving you a more direct way to describe an edit.

Developers also get SVG output through the API, where the Flare and Sunburst models are available. SVG is a vector format: it describes shapes that can scale cleanly, which makes it useful in design workflows. API use is metered, and getting SVG output requires an API integration.

I think the useful advance is the path through the work: create an image, point to the part that needs changing, then obtain an output suited to where it will be used. A creator can use the editing controls in ChatGPT; a developer can connect vector output to an application. That could remove manual conversion steps between generating a visual and putting it into a design.