Gemini 4 Carbon opens up, Australia plans AI oversight, and robots learn touch

Carbon and the cost of finishing the job

A model can use more tokens and still make a difficult job cheaper, if it saves enough failed attempts and rework. Gemini 4 Carbon is now available for developers to put that equation to the test.

Our main story is Google's move to open paid access to Carbon, and the question it raises for builders: when is extra reasoning worth paying for? On 10 November, Gemini 4 Carbon moved from restricted testing to general availability through Google's API, the interface developers use to connect a model to their own software.

Google positions Carbon for difficult coding, debugging and scientific reasoning. It also says Carbon uses more tokens than Argon for extended reasoning and verification. Tokens are the chunks of text a model processes and generates, so that extra work has a direct bearing on the bill.

The interesting part is the kind of work Google is targeting. A difficult debugging task can involve several plausible explanations for one failure. Finding a candidate fix is one step; checking whether it solves the original problem without breaking something nearby is another. Spending more computation on that process could be worthwhile if it reduces the number of times a developer has to send the problem back.

That's the comparison I'd want to make with Carbon: the total cost of getting a useful result through the normal review process. A low-cost response that needs three more attempts has a different value from one that gets the job done. Equally, extra reasoning adds expense when the simpler approach already works. The workload decides which side of that equation you're on.

Public API access makes that comparison much more practical. A developer can bring the model into an existing application and try it against the difficult cases they already understand. For debugging, that might mean a previously resolved fault with a known test outcome. For scientific work, it could mean a reasoning problem whose result can be checked.

There's also a useful distinction between paying for the model's work and paying for the whole task. The model bill is visible straight away. A developer's time spent checking an answer, explaining missing context or repairing an incomplete change can be less obvious. If Carbon reduces that work, a higher token bill could be a sensible trade. If it leaves the same clean-up behind, the economics look different.

This gives organisations a more selective adoption option. They could keep a familiar model for routine work and assess Carbon for the awkward cases that consume disproportionate attention. There's no need to assume every request benefits equally from a longer reasoning process.

The release doesn't yet settle Carbon's reliability or cost on any particular organisation's workload. But access has changed in a meaningful way: builders can now investigate that question inside the software and review practices where the result will be used. My view is that difficult tasks completed successfully, with verification included, are the useful unit of comparison. That makes room for a more capable model to earn its price without making the token count the whole story.

Australia's proposed AI regulator

That leaves Carbon with a practical test to pass. The shorter news starts with Australia's proposed rules for frontier-model suppliers.

On 10 November, the Australian Government announced plans for mandatory obligations on frontier AI companies operating in Australia, enforced by a new targeted regulator. The rules would arrive through forthcoming Australian AI Standards legislation.

The proposed duties include independent model evaluation, rapid incident notification, security controls, management of serious risks and published safety frameworks. For a company buying access to a powerful model, those duties could change the evidence available before signing a contract, and the information it receives when something goes wrong.

Independent evaluation would bring an assessment from outside the model supplier into that picture. Published safety frameworks would describe how the supplier approaches risk. Incident notification would address a different moment: a problem has emerged, and the people responsible for oversight need to hear about it quickly. These measures concern different parts of a model's life in use.

The government has also accepted all 18 recommendations from a rapid review following an OpenAI agent's access to government websites, including the Medicare Statistics Reporting Service Portal. That gives the announcement a concrete operational backdrop: AI agents interacting with services that already exist, with institutions having to account for those interactions.

For Australian organisations, the immediate distinction is timing. This is proposed legislation. The regulator and penalties aren't operating under this announcement, and it establishes no new compliance deadline. Commencement, detailed coverage thresholds, penalty amounts and the precise incident-reporting deadline remain to be specified.

Those details will determine which suppliers are covered and how demanding the obligations become. A business choosing a model provider can still see the proposed direction: external evaluation and incident disclosure could become conditions of market access.

I'd expect that to make supplier evidence a more concrete part of procurement. Buyers could ask how evaluations apply to the model they're purchasing and how incident information reaches them. The useful commercial question is whether a supplier can support those expectations throughout an ongoing service relationship. The legislation will decide the formal obligations; the proposal already gives buyers a clearer idea of what to ask about.

Qantas combines modernisation and outsourcing

There's a much more immediate human consequence in the next technology overhaul, at Qantas.

The airline has announced a multi-year partnership with Accenture to modernise back-end systems and data, alongside a reorganisation of corporate services expected to affect about 850 roles over the coming years. The first changes are expected by mid-2027.

Initial functions include finance, procurement, people and marketing. Transferred services would be delivered mainly from India and partly from Australia. Qantas says individual employee outcomes remain subject to consultation, with redeployment and retraining among the options it intends to pursue. The Australian Services Union disputes the offshoring decision.

The systems problem is substantial. Qantas says it has more than a thousand legacy applications and wants to connect its data and introduce further automation and AI. With that many applications in the picture, modernisation involves decisions about how information moves between systems, which systems remain, and who operates the resulting services.

The 850 figure belongs to the planned organisational change. Outsourcing is the mechanism being announced, while further automation and AI are part of the modernisation programme. The eventual mix of redundancies and redeployments will emerge through the employment process. That distinction keeps the people affected visible and identifies the business decision behind the change.

For other organisations contemplating a similar programme, the supplier relationship deserves close attention. Qantas is combining systems work with a change in who delivers corporate services. In that arrangement, a technical migration can also change who understands a process, where its knowledge sits and how an operational problem gets resolved. Those are consequential design choices for the buyer.

My reading is that the technology and staffing outcomes need to be judged separately. Connecting data could make automation more useful; moving a service to an external provider changes its delivery model. A successful outcome on one measure doesn't answer the other.

The financial terms and independently measured benefits haven't been established in the available reporting. For employees, the concrete near-term development is consultation over roles and possible job losses. For the airline, the work ahead is a multi-year transition across both its applications and the people who run corporate services.

IBM and Microsoft's enterprise agent offering

If you're buying AI for an established business, getting it connected can be a sizeable part of the job.

IBM and Microsoft are building an offering around that work. Announced on 10 November, Imagine Enterprise combines IBM Consulting's agents and industry assets with Microsoft's AI, data, identity and security technologies.

The companies describe a library of more than six thousand agents and assets, with initial industry frameworks for financial services, insurance and retail. That library includes supporting assets as well as agents. Access comes through IBM Consulting engagements, with deployment, co-innovation and self-management options. Forward-deployed engineers, who work closely with the customer on implementation, are available for qualifying engagements.

The appeal is easy to understand. An enterprise agent needs access to the information and systems involved in its job. Identity controls determine whose authority it uses. Data connections determine what it can work with. Deployment and ongoing management determine how the organisation keeps that service running. A packaged implementation offering brings those pieces into the purchasing conversation together.

Industry frameworks may also give a customer a more relevant starting point than an empty development environment. Financial services and insurance have their own processes and information needs. The useful question is how much of a particular workflow the supplied assets cover, and how much still needs to be built around the customer's systems.

The engagement options matter here. A company seeking hands-on implementation help has different staffing needs from one planning to manage the resulting system itself. The choice affects who does the integration work and who needs to understand it after deployment. Pricing hasn't been supplied, so buyers will need the engagement terms to assess that trade.

I think the strongest part of this proposition is the operational support around the agents. That could make an ambitious integration more approachable for an organisation that lacks the capacity to assemble every connection itself. The return still comes from a specific workflow: what it costs to deliver, how much work it completes and how much support it needs. A library of thousands gives buyers starting points; the value will be found in the few that fit their business.

A reusable sense of touch

Let's leave office software for a moment. Robot hands have a different integration problem: making sense of touch.

Robbyant's LingBot-Touch research, published on 9 November, aims to translate signals from different tactile sensors into a shared representation that robot-control models can use. The company has released encoder weights, the learned part of the model that turns prepared sensor measurements into that representation.

The researchers report pretraining on 4,983 hours of recordings from magnetic, piezoresistive and visuotactile sensors. These are different ways of measuring contact, so the signals don't arrive in one convenient common format. The evaluation covers 26 real-world tasks on two robotic-hand platforms.

The central idea is to make touch information more reusable across those differences. A robot's control policy determines its actions. A touch encoder supplies a representation of what the sensors are detecting. Separating those roles gives researchers a way to evaluate the encoder alongside control policies they already use.

That could reduce repeated sensor-specific development. If each new hand requires its own approach to interpreting touch, changing the hardware creates another integration project. A shared representation offers a possible common layer between sensing and control, even when the measurements underneath come from different hardware.

The released model bundle uses the Apache 2.0 licence and includes frozen encoder weights and inference configuration. A robotics developer receives a component to run within a larger system; the bundle leaves the robot controller and training pipeline to other work.

There are concrete input requirements. The encoder consumes adapted tactile measurements, and sensor geometry and measurement ranges need to be prepared correctly. It doesn't accept raw RGB images as a substitute for those inputs. Having compatible sensing hardware is therefore part of evaluating the release.

For robotics builders, I see the opportunity in avoiding some repeated work between the sensor and the controller. The published evaluation spans two hand platforms, so anyone working with different hardware still has an integration question to resolve. Even within that scope, a reusable touch component is an interesting contribution: it lets a developer investigate what better tactile information adds while keeping their existing control approach in the picture.

Outlook's exploited credential flaw

Back at the desktop, there's a specific Outlook security fix worth putting ahead of routine maintenance.

Microsoft's 10 November updates address an Outlook spoofing vulnerability with confirmed active exploitation. Opening a crafted message file can trigger a connection to an attacker-controlled location without the normal warning, exposing NTLM authentication material used by Windows authentication. The attack requires user interaction and network connectivity.

The affected products include specified versions of Windows Outlook in Office LTSC 2021 and LTSC 2024, along with Microsoft 365 Apps for Enterprise. Released fixes are available, and the appropriate update depends on the installed Office product and update channel.

That channel distinction is useful for administrators. A Microsoft 365 Current Channel installation and one on another enterprise channel can have different fixed builds. Matching the security release to the installation is how you establish whether that machine has the relevant fix. The linked Microsoft release matrix provides those details.

The consequence to focus on is the unexpected outbound authentication connection after someone opens the crafted file. That gives administrators a concrete reason to prioritise the affected Windows installations. The published record includes CISA confirmation that exploitation is occurring.

For an organisation triaging a large patch release, confirmed exploitation is a strong reason to move this fix forward. The action is specific: identify the affected Office installations and deploy the November security update that matches each product and channel.

OpenSearch upgrades with a way back

An upgrade is easier to schedule when you can try the replacement and keep a route back.

Amazon OpenSearch Service now offers clone-based version upgrades. Customers can validate a synchronised replacement cluster before switching traffic, then retain the previous cluster for rollback. That gives search-platform operators a way to compare real queries against the upgraded system before committing.

The new option follows defined upgrade paths. Those include Elasticsearch 7.10 to OpenSearch 1.3, and stages through OpenSearch 1.3 and 2.19 towards version three. Eligibility depends on the starting version and target; other paths use in-place upgrades.

During validation, the replacement supports reads only. You can inspect query behaviour, but writes are blocked during the eventual cutover. That leaves a specific interruption to plan around, even though much of the assessment can happen beforehand.

Retention is another setting with a direct consequence. Without a configured retention period, the old cluster is deleted immediately after cutover. Keeping it available for rollback means choosing that window in advance. Both clusters attract normal instance and storage charges during validation and for the period you retain the old one.

Availability excludes the New Zealand, Taipei, Thailand and Mexico Central AWS regions. For supported deployments, the operational trade is straightforward: a temporary second infrastructure bill buys time to test and a defined route back after the switch.

I like the practical change here. An operator can investigate query differences before those differences become the production experience. The length of the validation and rollback windows then becomes a cost decision, while the blocked writes remain a scheduling decision. Those are much more concrete choices to make ahead of an upgrade.

What Changes for You

There are also a couple of immediate access and upgrade decisions for anyone building with these tools.

For Gemini 4 Carbon, Google's introductory API price is two US dollars per million input tokens and ten per million output tokens through 30 November. The listed prices after that are four and twenty dollars respectively. A trial that runs across that date needs both rates in its budget. Google has also begun rolling Carbon out to AI Ultra subscribers. Antigravity's accompanying swarm capability is in preview, and the cyber-specific Carbon variant remains separately gated through the Fairwind Program.

For .NET developers, 10 November brought a release and a support deadline together. Microsoft shipped .NET 11 with C# 15, while .NET 8 and 9 reached end of support. The immediate decision for applications still on those older releases is a supported migration target. Both .NET 11 and the existing .NET 10 long-term-support release are supported until 14 November 2028.

C# 15 adds union types and closed hierarchies. These let developers define a set of possible outcomes and have the compiler check code against that set. That's useful when an application needs to handle each outcome explicitly.

The .NET 11 software development kit also includes an MCP server template. MCP is a protocol for exposing tools to AI applications, and the template gives .NET builders a starting point within their existing development tools.

Installing the new development kit leaves existing applications on their current targets. Migration requires a separate application change, and .NET 11 also changes minimum CPU requirements. Its Blazor AI components remain experimental.

For a working developer, I'd separate the support decision from the optional new features. A suitable .NET 10 migration can restore a supported footing, while a move to 11 can bring the new language and tooling capabilities. The choice can follow the application's hardware, dependencies and development needs, with the same published support end date for either target.