RAM prices have exploded over the past year, with some DDR5 kits approaching 500% year-over-year increases and a 128GB kit now selling for $3,399, which is more than 10 times its previous low. Tom's Hardware reports: Things improve as you step down the memory capacities and speed tiers, but not as much as we'd like. You're still looking at $392 for a memory kit that was just $72 last year. To reinforce the point, I pulled the latest average price data from PCPartPicker, comparing where we are today (August 2026) to exactly one year ago. This data is somewhat approximate, but it should be broadly accurate. [...] A standard 64GB (2x32GB) DDR5-5600 kit that would have cost you under $200 last summer is now demanding over $1,100. It is a 5x multiplier on a component that used to be a fairly boring and predictable line item in a PC build budget. If you plan to just wait it out on an older AM4 or LGA1700 motherboard with DDR4, you'd better hope your memory holds out too, because DDR4 isn't safe from the fallout. With DDR5 entirely out of reach for most builders, the resulting scramble for older platforms running DDR4 memory has created a massive knock-on effect, and as a result, DDR4 kits are up anywhere from 120% to nearly 180% across the board. Nowhere near as bad as DDR5 pricing, but it still stings when a kit that was $105 last year is $281 this year. This phenomenon is by no means exclusive to the US, either. German tech site ComputerBase have also been tracking this global trend, reporting just this week that average RAM prices in Europe have skyrocketed by 345% compared to September 2025. Their data shows the squeeze is bleeding into other components too, with hard drive and SSD prices both climbing over 125% in that same timeframe. In fact, the situation is so severe that hyperscale buyers have reportedly already locked in almost all of the global DRAM production capacity for 2027, handing over advance deposits to guarantee their supply of precious DRAM, which is now among the highest-value commodities in the world by weight; mainstream DRAM chips are worth over half as much per kilogram as solid gold.

Read more of this story at Slashdot.

Gemini in Chrome is now available to all Android users in the U.S.

Mistral is giving enterprise customers until August 31 to replace the Google Drive and Microsoft SharePoint Knowledge Connectors they use in Vibe Work with MCP-based alternatives. The company says in its Knowledge Connectors documentation that both existing connectors will be shut down and deleted on that date.

There is no automatic migration, so administrators will need to install the MCP replacements before every user reconnects their Google or Microsoft account. The move changes how Vibe Work reaches company documents, but Mistral has said little about the retrieval architecture behind the new connectors.

Mistral stores a searchable index

With the current system, an administrator chooses which Google Drive folders or SharePoint sites the organization wants to make available, then Mistral processes those files and stores the resulting index in its European data centers.

Once the index is ready, users connect their personal accounts, and when they search in Vibe Work, the connector checks permissions copied from Google Drive or SharePoint so the results include only files they can access, while scheduled synchronizations pick up later changes and deletions.

This setup lets Mistral handle retrieval by searching a prebuilt index whenever a user submits a query. The company says indexing can take anywhere from a few minutes to several hours, depending on how much data the organization includes, although that work is completed before users begin searching.

The company says indexing can take anywhere from a few minutes to several hours, depending on how much data the organization includes, although that work is completed before users begin searching.

MCP shifts retrieval off-platform

The company defines MCP as a common interface that lets models call tools and retrieve data from external services — the same protocol layer that is reshaping how AI products connect to external APIs across the industry.

In June, Mistral added Google Drive and SharePoint to a directory containing more than 60 integrations, but it did not explain how those two connectors retrieve documents or say who operates the underlying MCP servers. The setup can range from live calls to the source API to a server-managed search index, with any combination of the two in between. That flexibility is part of what makes MCP appealing in some environments and unnecessary in others, but it also means that the behavior of a given connector depends entirely on its operator.

Permissions rules remain unclearThe company doesn’t run the third-party servers behind these connectors, so it can’t promise how they will behave or what they will do with customer data. That gap between the governance Mistral once provided and what it’s now handing off to third parties reflects a trend in how enterprises are adopting MCP connectors without fully resolving the governance layer. As other platforms have learned, opening the door to external servers means trusting the protocol and the operator and building the guardrails to go with it.

The migration notice offers even less detail. It doesn’t say whether the Google Drive and SharePoint MCP servers retrieve files directly from Google and Microsoft. Any caching remains unexplained, leaving customers unsure where retained data would live. Mistral makes no promise that searches will be as fast or return results of the same quality.

Mistral makes no promise that searches will be as fast or return results of the same quality.

The outgoing Google Drive connector follows the sharing rules already attached to each file, including group and domain access. A file set to “anyone with the link” still isn’t automatically visible to everyone in the organization. SharePoint uses Microsoft Entra ID groups, so older groups created only within SharePoint aren’t picked up.

Mistral hasn’t said whether the MCP replacements will follow the same rules. OAuth can limit a server’s access to the connected user, but that doesn’t mean search results will be filtered exactly as they were in the outgoing index. The protocol wasn’t designed to enforce that kind of enterprise permission model; the connector’s retrieval layer has to do it.

OAuth can limit a server’s access to the connected user, but that doesn’t mean search results will be filtered exactly as they were in the outgoing index.

Deletion timeline still unresolved

The company says disabling a Knowledge Connector results in permanent deletion of the indexed data, but the deprecation notice does not say whether the August shutdown will trigger that process automatically or how long the deletion will take. It also leaves administrators unsure whether they should disconnect the old connectors themselves before the deadline.

Because the same connectors work in Vibe Code and Mistral’s workflow system, teams can use the same approach to expose external data across chat, coding and automated jobs — a pattern that is becoming more common as MCP connectors spread from chatbots into production infrastructure.

Mistral also recommends checking server output for signs of prompt injection — advice that underscores the still-emerging challenge of securing the space between AI agents and the external services they access.

The post What happens to your indexed data when Mistral flips the switch? appeared first on The New Stack.

Computing is undergoing a dramatic shift.

Software is no longer primarily created, consumed, and coordinated by humans. Increasingly, software discovers, orchestrates and interacts with other software, while humans provide direction and judgment. This new type of software artifact is an AI agent.

Agents are proliferating across every organization and they are reshaping how software gets built and used, how industries function, and how work gets measured.

Agents get their abilities through APIs. Agents can gather data, take actions, retain memory, or interact with humans or other machines or agents through APIs. As they get more capable, agents are changing our relationship with computing.

Agents hold enormous power and it’s only going to grow.

That power carries risk: If you do not control your agents, your agents control your company.

Organizations are facing multiple demands at once. They need to determine:

• Which agents they build and maintain
• Which agents they hire from outside
• What agents can see and do inside their walls
• Which data and APIs agents have access to inside the organization
• Which APIs they expose to agents outside the organization
• Rent AI for their agents or rent AI from outside

Existing approaches are insufficient

The fundamental question every enterprise is facing is no longer “How do I deploy agents?”. The challenge lies in being truly prepared for this new era and that involves answering:

How do I trust the agents I have?

• Who is using these agents? When are agents hallucinating? Who are they aligned with? If you do not know this, you are not in control of decisions.

How do I control what they can discover and access?

• Have I made my APIs discoverable and accessible for agents? Have I given them the right access? If you do not know this, you are not in control of actions.

How do I govern them?

• What happens when something goes wrong? Who holds accountability? Are they working for my organization or on behalf of an outside entity? If you do not know this, you are not in control of risk.

How do I know the ROI of my agents?

• How much am I spending and am I seeing the outcomes? If you do not know this, you are not in control of your budget.

How do I manage thousands of agents operating across the enterprise?

• How do I scale my agentic enterprise? What will break if and when we start to scale?If you do not know this, you are not in control of operations.

We are uniquely positioned to solve it

For more than a decade, Postman has helped more than 500,000 organizations discover, govern, and connect APIs. As agents become the primary consumers of APIs, that same foundation naturally evolves into the control plane for the agent economy.

We believe enterprise computing now requires a new infrastructure layer for the agent economy.

We have been building on several fronts, and together they form Postman’s Agent Stack:

• Passport: access management for humans and agents.
• Fabric: an AI-native gateway with support for AI, MCP, and APIs.
• Astro AI: an agent operating system to run and control agents.
• Fern: agent and developer experience, covering docs, SDKs, and CLIs.
• Postman Platform: the foundation that ties together the API Catalog, the Context Graph, and the AI Engineer.

Agents have made API-first a mandate. Earlier this year we rebuilt Postman as an AI-native API platform. We shipped the API Catalog, a system of record for APIs and services, and the AI Engineer, an autonomous engineer that runs on the Context Graph sitting on top of the Catalog.

Postman’s new AI-native platform is the foundational system for these new products. The platform is the supplier of APIs and API context for Fern, Fabric, Passport, and Astro AI.

We built the original Postman for our own needs, and we built the Agent Stack the same way – through our own transformation into an agent-native company. Fabric is where we run our AI workloads. AstroAI is where we run our agents. Passport is how we give agents and humans the right access to our APIs. Fern is how we publish our documentation.

The Agent Stack is how we are accelerating in the age of AI, while staying in control.

What is Postman.ai

We are launching Postman.ai as the central place to communicate our vision and views on AI, our research, and industry benchmarking. I am excited about the future where humans are the winners in this new era of computing.

-Abhinav

The post Computing is changing, so is Postman – Introducing Postman.ai appeared first on Postman Blog.

A Claude Code skill designed to help developers work with Anthropic’s API was consuming more than 200,000 tokens to load. With Claude Code v2.1.234, Anthropic says it has brought that down to roughly 25,000 tokens.

The change appeared in the Claude Code changelog on Monday. Anthropic attributed the reduction, which cuts the initial context cost by at least 85.7%, to loading the skill’s reference documentation on demand. In this case, a single bundled skill could consume more tokens than many coding sessions do from beginning to end.

Skill loaded everything upfront

The built-in /claude-api skill which loads reference material for developers working with the Claude API and Managed Agents, can be invoked directly, but Claude Code can also activate it when a project imports Anthropic’s Python or TypeScript SDK. Interestingly, developers had already traced the problem before Anthropic documented the fix.

In a GitHub issue opened July 7, a developer examining Claude Code 2.1.201 found that /claude-api embedded its shared reference files and the detected language documentation directly into the skill body. The report measured roughly 120,000 tokens of reference material in a single invocation. One migration document accounted for an estimated 36,000 tokens on its own.

One migration document accounted for an estimated 36,000 tokens on its own.

Once the rest of the skill loaded, even a one-line question could consume roughly 200,000 tokens before Claude started answering — the hidden overhead that, as with production AI pipelines more broadly, only surfaces once someone actually measures it. The issue was closed as a duplicate and marked “not planned,” despite similar reports still coming in.

A second bug report filed August 4, found a particularly expensive fallback. When the skill could not detect a project language during a prompt audit, it loaded documentation for C#, cURL, Go, Java, PHP, Python, Ruby and TypeScript, along with 26 shared Markdown files. The bundled directory was 812,650 bytes. Only one 32,954-byte file was needed up front for the task used in the reproduction.

A large local reference library provides an agent with useful material to draw on, but inlining it forced the agent to read all 812 KB for every request, even when most of it was irrelevant.

A large local reference library provides an agent with useful material to draw on, but inlining it forced the agent to read all 812 KB for every request, even when most of it was irrelevant.

Context window fills silently

Anthropic’s own Claude Code best-practices guide warns that performance degrades as the window fills, with the model more likely to lose earlier instructions or make mistakes. It’s a pattern that extends beyond Claude Code: the blank-check era of AI coding is ending precisely because unchecked token consumption degrades both quality and cost.

Once a skill loads, its content becomes fixed overhead that developers may never see, creating an inherited problem at enterprise scale. Claude Code’s documentation says the skill body stays in context across turns, even though the developer may see only the much smaller request and response.

Cutting the skill to roughly 25,000 tokens leaves a lot more room for the repository and the actual work. Anthropic doesn’t explain how Claude chooses which documents to load, only that the references are now pulled in on demand.

On-demand approach trades reads for room

Anthropic’s skill documentation says SKILL.md should contain the core instructions and links, while API specifications, examples, and other detailed material should live in supporting files that Claude opens only when needed.

That guidance divides loading into three stages: a small amount of metadata that is always present, the SKILL.md body when the skill triggers, and bundled resources pulled in during the task. The old /claude-api behavior blurred the last two by loading all of its reference material as soon as the skill ran.

With on-demand loading, Claude may need an extra file read after it identifies the relevant language or API feature.

With on-demand loading, Claude may need an extra file read after it identifies the relevant language or API feature. But it pays that cost only for material tied to the task, which becomes more important as agentic workflows make token costs the fastest-growing line item in AI budgets.

The post A Claude Code skill was eating 200,000 tokens before answering a single question appeared first on The New Stack.

Topics covered in this episode:

• Python 3.12.14, 3.11.16, 3.10.21 - security releases
• Codeberg’s AI-code ban tests its role as a GitHub alternative
• Brett Cannon: what's missing for reproducible builds on PyPI
• • nothing records the source code a distribution came from. direct_url.json captures it when you install from a repo or archive, so the fix is putting the same info in sdist/wheel metadata.
• • recording the build tools. Wheels can already do this via PEP 770 SBOMs in .dist-info/sboms/ - sdists can't, since they're a tarball plus a precalculated PKG-INFO with nowhere to hang extra metadata. Either "don't use sdists" or an sdist v2.
• Extra extra extra, hear all about it
• Extras
• Joke

Watch on YouTube

Sponsored by Logfire from Pydantic pythonbytes.fm/logfire

This episode is brought to you by Pydantic Logfire. It's observability for AI apps from the team behind Pydantic - agents, LLMs, APIs, database, and infrastructure in a single trace, queried with Postgres-compatible SQL. Your coding agent can query it too, through their MCP server. I'll tell you more later.

Connect with the hosts

• Michael: Mastodon / BlueSky / X / LinkedIn
• Calvin: Mastodon / BlueSky / X / LinkedIn
• Show: Mastodon / BlueSky / X
• Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesday at 7am PT. Older video versions available there too.

Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it.

Calvin #1: Python 3.12.14, 3.11.16, 3.10.21 - security releases

https://blog.python.org/2026/08/python-31214-31116-31021/

• Source-only security releases for the three branches now in security-fix-only mode; release team blamed the European solar eclipse for the timing.
• tarfile hardening. Multiple path-traversal bypasses of the data filter closed, including a symlink escape that bypassed the CVE-2025-4330 fix; extract() now applies the filter to link targets too.
• Four fresh CVEs: CVE-2026-2297 (SourcelessFileLoader not using io.open_code() for .pyc), CVE-2026-4224 (expat crash on deeply nested content models), CVE-2026-3644 (control chars in http.cookies.Morsel), plus the completed CVE-2021-4189 fix in ftplib.ftpcp.
• Quadratic-complexity DoS cleanup across the stdlib: HTMLParser, configparser regexes, unicodedata.normalize(), csv.Sniffer.sniff(), and ElementTree XPath index predicates.
• Header/injection fixes: CR/LF rejected in HTTPConnection.set_tunnel(), control chars blocked in wsgiref.handlers status, and webbrowser now rejects leading dashes (plus a %action prefix bypass).
• http.client now caps chunked trailer lines and 1xx interim responses at 100 each - a hostile server could previously hang the client forever despite a socket timeout.
• Memory-safety odds and ends: stale pointers in lzma/bz2/zlib decompressors after MemoryError, a bz2 stack overflow on reuse-after-error, and bundled libexpat bumped to 2.8.3. If you're still on 3.10, 3.11, or 3.12 - and you extract tarballs from anywhere you don't fully control - this one's not optional.

Michael #2: Codeberg’s AI-code ban tests its role as a GitHub alternative

• Armin’s article “Codeberg Divides”
• Armin Ronacher argues that Codeberg’s new terms, which prohibit projects mostly written with generative AI, create a vague and difficult-to-enforce boundary. His larger concern is that a democratically governed host can still be unpredictable or ideologically narrow, weakening Codeberg’s potential as a broad European alternative to GitHub.
  • The strongest question for Python developers is whether repository hosting should judge legal open source by how code was produced, or focus on behavior and resource abuse.
  • “Mostly generated” is hard to measure in modern codebases where developers mix handwritten code, completions, agents, and generated refactors.
  • Ronacher suggests clearer alternatives: ban all LLM involvement, or target autonomous repository spam, abusive resource use, and low-quality generated contributions directly.
  • Codeberg is free to choose a values-driven community, but that may conflict with being predictable, neutral infrastructure and a serious GitHub competitor.
  • Worth discussing: can open-source communities set meaningful AI boundaries without driving maintainers and projects into opposing camps?
• Very first search for these terms lands on this page.
  • Codeberg looked like a viable alternative. … Unfortunately, the latest update to its terms of service seems to mark a first step in changing one part I moved there for, namely the “freedom” part.

Sponsor: Logfire from Pydantic

Your AI agent failed at 2am. Was it the model? A tool call? The database? Most observability tools can't tell you, because they only see part of your stack. Pydantic Logfire sees all of it. One trace across your agents, LLMs, APIs, and database. Down to the infrastructure: services, Kubernetes, and hosts. It's built on OpenTelemetry, with SDKs for Python, TypeScript, and Rust, and it works with any OTel-compatible language. Every prompt, token count, and cost, right next to your vector searches and API calls. You query everything with Postgres-compatible SQL. And so can your coding agent, through the Logfire MCP server. Stop guessing. Read the trace. Pydantic Logfire. AI, it's still just engineering. Visit pythonbytes.fm/logfire today and sign up today. Get 10M records free every month, no card required. You can even click “Onboard with your coding agent” to copy a prompt to have claude or codex integrate Logfire into your app. Thanks to Pydantic for supporting the show.

Calvin #3: Brett Cannon: what's missing for reproducible builds on PyPI

• Framing came out of his 2026 Python Packaging Council nomination - the secure-supply-chain gap he found is that Python has no defined way to do reproducible builds at all.
• Design goal is zero friction: producers uploading to PyPI shouldn't have to do anything. The work lands on build backends and installers.
• Gap #1: nothing records the source code a distribution came from. direct_url.json captures it when you install from a repo or archive, so the fix is putting the same info in sdist/wheel metadata.
• Gap #2: recording the build tools. Wheels can already do this via PEP 770 SBOMs in .dist-info/sboms/ - sdists can't, since they're a tarball plus a precalculated PKG-INFO with nowhere to hang extra metadata. Either "don't use sdists" or an sdist v2.
• The replay mechanism already exists: [build-system] in pyproject.toml is a defined entry point, so if backends recorded their own environment, you could reinstall and re-run the build.
• Payoff idea: trusted third parties report successful reproductions back to PyPI, which displays "independently reproduced by X" - surfaced in the index API so installers could prefer reproduced files.
• Explicitly framed as a perk, not a requirement - roughly SLSA build level 1, no shaming projects that don't opt in. Verbal kicker option: "And don't think pure-Python wheels are off the hook. Something built that wheel, and if that something was compromised, so is your wheel. SolarWinds was a build-process attack."

Michael #4: Extra extra extra, hear all about it

• Python 3.14.7
• Upgraded the MCP servers to 2026-07-28 v2 protocols (talk python, python bytes)
• Got agentsview running synced via postgres
• Talk Python courses, teams trial offering
• Talk Python courses, government procurement offering
• Lean TDD audio book is out

Extras

Calvin:

• uv now prefers post-quantum key exchange - https://github.com/astral-sh/uv/releases/tag/0.12.4

Joke: Beware of dog

Download audio: https://pythonbytes.fm/episodes/download/492/codeberg-puts-head-in-sand.mp3