What Tuesday's tool news means for how you buy software

Across Tuesday's announcements, one thread runs from the billing page to the model that does the work: vendors are rethinking how AI is priced, which engine should answer a given request, and how a business can tell whether the output can be trusted. A tool choice is no longer just features against price. It is now a question of what you pay per unit of work, which model runs that work, and whether the vendor hands you controls to keep both in check.

That shift matters to anyone comparing tools this week. The feature list still counts, but the cost model underneath it is moving, and it moves faster than most procurement cycles. Reading the day in that light makes the separate stories hang together.

How AI gets priced is changing

For two decades the default way to buy software was a seat licence: a fixed monthly fee per user, the same whether that user did a little or a lot. AI breaks that assumption, because the cost of serving a request is no longer close to zero. A single long answer can cost the vendor real money, and a heavy user can cost many times what a light one does. When the underlying cost varies that much, a flat per-seat fee either overcharges the quiet accounts or loses money on the busy ones.

Stripe reported from its Monetize 2026 event that this is already happening in practice. "As usage, costs, and customer expectations change, AI companies are moving beyond traditional SaaS pricing." [1] The post describes vendors combining subscriptions with usage-based billing and building spend controls into their products.

For a buyer, the practical lesson is to read the pricing page as carefully as the feature list. A usage component means your bill can move with your activity, so the question becomes whether the vendor shows you the meter and lets you cap it. A plan that mixes a base fee with metered usage is selling you two different things at once, and they fail in different ways. We have written before about how a plan's real promise hides behind its headline number in what a subscription plan is really selling, and about the ways a pricing page can mislead in how pricing pages fail. Both apply directly here. A business that pays for AI by the unit of work should expect the same transparency it would demand from any utility bill.

Letting you pick the model for the job

The second story of the day is about which model runs your request. The common assumption is that one large, general model should handle everything. In practice a smaller model tuned for a narrow task can be faster, cheaper and sometimes more accurate on that task, while a larger general model is better for open-ended work. The trade-off is real, and increasingly vendors are choosing to expose it rather than hide it.

Salesforce set out its reasoning for giving customers a choice. Its post explains the thinking through its Chief Data Officer: "Salesforce Chief Data Officer Michael Andrew explains how purpose-built models like Koa and multiplayer AI in Slack fit together." [2]

For a buyer, model choice is both a feature and a responsibility. If the tool lets you route simple work to a cheaper model and reserve the expensive one for hard problems, that control directly affects the usage-based bill from the first story. If the tool hides the choice, you are trusting the vendor's routing to match your budget. Neither is wrong, but you should know which one you are buying. The same discipline applies to deciding what the machine should be allowed to do at all, which we covered in what AI should and should not do in your business.

Skills arrive in the Gemini app and Workspace

Google Workspace confirmed that skills in the Gemini app are rolling out. "As previously announced, skills in the Gemini app are starting to roll out today, with an expected completion by mid-November." [3] The post also notes that the ability to share skills and other features will follow in the coming weeks.

The idea behind a skill is to package a repeatable instruction so a person does not have to rewrite it every time. That is useful, but the detail worth noting is the phased rollout and the sharing feature arriving later. A capability that is announced is not the same as a capability that is available to your whole team on the day you sign up. When you evaluate a tool mid-rollout, test what is live for your account, not what the announcement describes, because the two can be weeks apart. Shared skills in particular change how a team keeps its work consistent, a theme we explored in keeping a small team aligned without meetings.

Finding secrets with less noise

Security tooling faces a quieter trade-off that every buyer eventually meets: catch more problems, or raise fewer false alarms. Push too hard for detection and you drown the team in noise until they stop reading the alerts. Tune for quiet and you miss real problems. The two pull against each other, and most tools settle somewhere on that line.

GitHub reported a change to its secret detection that it says improves both at once. "GitHub's context-aware secret classifier improves detection quality, raises weighted acceptance by 11.5%, and reduces median scan execution time by 86%." [4] Context-aware here means the classifier weighs the surrounding code, not just the pattern of the string.

For a buyer, the number to probe is the false-positive rate, because that is what decides whether a team keeps using a security tool or learns to ignore it. A faster scan matters too, since a check that runs in the background without slowing work is one people leave switched on. When you compare security features, ask how the tool handles noise, not only how much it claims to catch.

From radar to real time

Salesforce also published a longer piece framing a shift from systems that report what already happened to systems that watch a business as it runs. It opens with a historical analogy: "In 1935, the British Air Ministry asked physicist Robert Watson-Watt for a death ray capable of downing enemy aircraft." [5] The point of the story is that the useful invention was detection in real time rather than the weapon that was first requested.

The lesson for a buyer is to separate reporting from monitoring. A dashboard that summarises last month is useful for review. A system that reacts to what is happening now is a different kind of tool with different costs, because real-time work is exactly the usage that drives the pricing shift in the first story. If a vendor promises real-time intelligence, ask what it costs to keep running, not only what it can show.

Reading the day together

The five stories point the same way. Pricing is moving to the unit of work, so the controls that cap your spend now matter as much as the feature list. Model choice decides how much each unit costs, so a tool that exposes the choice hands you a lever on the bill. Rollouts arrive in stages, so test what is live rather than what is announced. Security tools live or die on their noise, not their reach. And real-time features are powerful precisely because they consume the usage that everything else is now priced on.

A business choosing tools this week does not need to predict where all of this lands. It needs to ask the same few questions of each vendor: what do I pay per unit, which model runs it, what can I cap, and what is actually available to my team today. Those questions cut through most of the noise. For the previous day's items, see Monday's briefing.