TheDaily Front

Over the past eight months, our Threat Intelligence team identified and disrupted operations in which threat actors tried to use Claude for malicious activity. In this report, we share case studies from those operations and describe how malicious use of Claude has evolved since our previous threat reports in March, August, and November 2025. In each case, we disrupted the activity, used what we learned to strengthen our safeguards, and shared intelligence with authorities and industry partners, where appropriate.

This report covers activity we disrupted between December 2025 and August 2026 across seven harm areas: cyber operations, influence operations, surveillance, scams and fraud, biological misuse, conventional weapons development, and distillation. Claude Haiku, Sonnet, and Opus models were used. None of the misuse cases involved the use of Claude Fable or Mythos-class models, with the exception of one illicit distillation case.

The cases we share here aren’t typical misuse, but rather examples of the most notable and novel threat activity we’ve identified to date. We’re publishing this work because we believe we have a responsibility to disclose malicious misuse of our services. As models become increasingly capable, their risks will increase, unless AI developers and society’s defenders act to make them safer.

The threat actors covered in this report include suspected state-sponsored groups, financially motivated criminals, commercial spyware vendors, state propaganda institutions, and politically motivated individuals. The cases range from a network of fake dating apps designed to defraud users to surveillance systems built to identify and monitor dissidents.

Sophisticated and persistent threat actors continuously test our safeguards and try to circumvent the technical measures we use to detect and prevent misuse. We’ll continue to evolve our safeguards and coordinate with our partners to improve our ability to detect, disrupt, and prevent future misuse.

We hope that the findings in this report will help other developers recognize similar patterns on their own platforms, give governments and civil society a clearer view of how emerging threats take shape, and strengthen collective defenses.

AI-augmented cyber operations

Cyber operations: From assistant to orchestrator

Over the past six months, our Threat Intelligence team identified and disrupted a series of cyber operations in which threat actors used Claude. The actors included suspected state-sponsored groups, financially motivated criminals, and politically motivated individuals. This section presents some of those cases.

Throughout these case studies, the report will reference Generative Threat Groups (GTGs). These are Anthropic’s internal designators for actors observed to be abusing AI. The report also attempts to measure uplift, a term we use to describe the AI capability boost, or how much more harm was caused with AI versus without AI. We view uplift through the lens of speed, scale, and depth, and attempt to determine how an actor’s adoption of AI meaningfully impacts each of these traits.

Many commentators focus on the risk of AI developing exploits at scale. While this is a danger, the risk from AI adoption is more pronounced across the cyber kill chain, where adversaries can operate faster, across a broader and deeper surface area, with fewer resources.

The cases span the period from December 2025 through August 2026. In all cases, Claude Haiku, Sonnet, and Opus models were used; no malicious activity was found on Claude Fable or Mythos (which has a series of safeguards in place that greatly reduce its ability to perform harmful cyber tasks). In each case we disrupted the activity involved, strengthened our AI safeguards based on what we learned, and shared intelligence with authorities and industry partners where appropriate.

In the following report, we begin by discussing the key trends that we’ve observed in these cyber operations, then move to reporting the case studies and how they highlight those trends.

Trends

Sophisticated attacks no longer require sophisticated attackers

The cybersecurity skills of AI models means that AI has collapsed the labor and tooling gap that used to separate well-resourced, state-sponsored operations from individual operators. In the case studies we report below, a hacktivist using stolen API keys, disparate financially motivated individuals, and a state espionage operator each sustained multi-victim campaigns that, even just a year ago, would have required many skilled operators and specialist knowledge.

For threat intelligence investigators, sophistication has stopped being a reliable signal of who is behind an operation. Every layer of offensive operations has been uplifted by AI, from reconnaissance and tool development to data processing and exploitation. An example of this uplift in capabilities is documented in case study GTG-50014 (described below). The net effect of this uplift in capabilities is access to an increased breadth and depth of knowledge, which in turn drives increased speed of capability development and implementation.

In November 2025, we documented an operating model used by a suspected state-sponsored campaign to carry out autonomous attacks. That operating model has now proliferated across every class of actors we investigated. Publicly available offensive agent frameworks, like PentAGI, reproduce much of the same scaffolding for anyone who downloads them. This scaffolding effectively automates each step of the cyber kill chain. The operators behind observed cases range from state services to lone individuals, across a widening set of countries. An example of this adoption of AI-enabled kill chains is documented in case study GTG-20006. As models continue to evolve and improve, we assess that more actors, from lone wolves to organized entities, will continue to adopt AI frameworks to enable more sophisticated cyber attacks at greater speed and scale.

AI’s role in cyber operations has become increasingly autonomous

A majority of the operations described in this report were enabled by AI via direct execution or orchestration. The use of AI went beyond simple questions and responses from a chatbot but rather involved the use of multi-agent frameworks executing reconnaissance, exploitation, and data exfiltration. Humans remained in the loop by setting the targets of attacks and reviewing exfiltration. An example of this trend is GTG-20006. This actor developed an AI-assisted workflow that automatically rebuilt and re-deployed their toolkit if it was detected by security products.

GTG-20006: Russian espionage

Historically, cyber espionage actors have followed a pattern of developing and deploying custom toolkits designed to evade detections. Actors would use these tools until defenders identified and built signatures to detect and block them, and there would then begin a new cycle of evasion and detection. Robust defenses and detections therefore created increased costs for adversaries. Now, however, the adoption of AI threatens to quickly and easily subvert defenders’ ability to impose costs on adversaries via static detections alone.

GTG-20006 is an actor who has increased their speed by automating their operations using AI. Our attribution is consistent with public reporting linking the actor to Midnight Blizzard. One of the operators is a Russian speaker using the handle “JackPoterz” whose tradecraft and targeting are consistent with Russian state-nexus espionage. They ran operations attacking military intelligence targets in Ukrainian and European governments, as well as diplomatic and defense organizations and individuals connected to US foreign policy. We observed GTG-20006 operate through customized AI-driven workflows that automated much of their operations from development, infrastructure acquisition, phishing, persistence through command and control, to data exfiltration.

GTG-20006 employed a custom toolkit composed of two families of Windows-based implants, a mobile exploitation kit, a credential stealing tool that targets browser password stores, a phishing platform designed to mimic priority targets like government organizations, and an administrative console used to manage compromised accounts. Each of these tools was managed and re-tooled as needed during the cyber operations through AI-assisted workflows.

The actor also used AI to monitor how well their tools evaded detections from known security defenses. If their monitoring AI agents identified that any of their deployed malware was detected by a security product, agents would then set about the process of autonomously modifying and rebuilding the malware to evade the existing detections. The agents were designed to continue iterating on GTG-20006’s toolkit until it was undetected. At that point, the tools were staged for live operations from disposable hosting servers where victim traffic was directed to retrieve the malware during their many cyber operations, including phishing, ClickFix, and DNS hijacking schemes.

The actor also used AI to drive their phishing operations. They developed AI-driven workflows to research then register domains and then configure the hosting infrastructure used to send phishing emails. Additional workflows were developed to send the emails and monitor the C2 channels for successful compromises. The human actor engaged primarily to modify Claude Code skills that drove the workflows when they needed to be refined.

Our investigation identified more than 20 distinct organizations targeted in the actor’s operational planning, reconnaissance, and live operations. They included government ministries, defense and intelligence bodies, embassies and diplomatic missions, think tanks, and defense-industrial companies, concentrated in Ukraine and Europe but extending to the Middle East and maritime related government agencies in Asia. A common theme of the targeting was Ukraine and military drone technology providers and supply chains. Exceptions included a Southeast Asian government entity relating to maritime shipping and tracking, and a North African government technology authority.

Cyber operations

The most commonly recurring targets were members of the Ukrainian government, military, and diplomatic staff. The actor scanned email services and remote access systems across more than two dozen Ukrainian government organizations.

A secondary recurring target for theft was drone supply chain technology. The actor bulk-exported the mailboxes of at least two drone component manufacturers, targeted a military drone maker, and stole a complete proprietary software development kit for a drone vision system. They spent several days reverse-engineering the drone’s vision system, recovering its product architecture, its hardware bill of materials, its supplier dependencies, and details of an unannounced product. Military drone control and AI vision-related firmware appeared to be of particular interest.

Not all targets were direct: to reach their targets indirectly, the actor compromised at least three hospitality vendors that operate hotel guest WiFi. They used compromised admin credentials to modify DNS records so that they pointed to services owned by the actor (a technique known as DNS hijacking). Guests of hotels using the compromised vendors who connected to the hotel WiFi had their traffic, device identifier and IP address sent to the actor’s servers. At that point, ClickFix-style lures were staged to deliver Windows, Android and iOS malware to the victim’s device. The actor was able to use a combination of guest information stolen from the hotel management systems with the data stolen from individual guests’ devices to focus additional targeting efforts. Particular targets of interest were individuals associated with Ukraine, including government officials and drone manufacturers. Note that in July 2026, Microsoft Threat Intelligence published a report on the method of theft and malware delivery used here, which they referred to as CaptiveCrunch.

The actor also took over victims’ WhatsApp accounts, using a platform of headless browsers to link victim accounts as companion devices. In part by using the WPPConnect open-source WhatsApp automation library, the actor’s configuration suppressed read receipts so victims would not notice while it bulk-exported Russian and Ukrainian language conversations. At least two former high-level Ukrainian officials were targeted in this way.

The actor also targeted surveillance platforms. They found authorization flaws in the application interface of camera streaming services, and from there they enumerated users and harvested tokens that granted them access to the victims’ live camera streams.

The same actor also conducted an intrusion of a North African government technology authority. They stole credentials to a VPN appliance, and used them to take over the organization’s central account server. This allowed them to exfiltrate its full credential database: more than 300,000 national identity records, and the commercial registry data of more than half a million companies operating in the country.

The actor continued to develop a cloud email espionage platform that in part used “Embassy Kit,” the actor’s framework for managing device code phishing, to operate a Microsoft 365 token theft campaign. This platform, which was used to target diplomatic and government personnel, resulted in the access and exfiltration of mail records from at least eight organizations including a national prosecutor office, a military education institute, and a regional intergovernmental organization.

Windows credential stealers were delivered via fake update-themed social engineering lures, alongside companion payloads with full remote access capabilities. These payloads were designed to freeze the victim machine’s security updates, meaning that new malware detection signatures published by security vendors would not be retrieved or run on the victim’s machine.

The actor used AI at every point in their operations:

• Reconnaissance: The actor used AI to fingerprint email and remote access systems and to harvest information from public sources, building target lists for phishing.
• Initial access: The actor used AI to build and operate the platform that ran these cyber intrusion campaigns. The campaign’s primary access technique was a form of device code phishing that abused legitimate sign-in flows for cloud email services. The actor used AI to set up the phishing infrastructure and the exploitation tooling, and executed portions of the intrusions directly including running commands against victim systems, harvesting credentials, and moving laterally through networks under the actor’s direction.
• Collection and exfiltration: The actor used AI to perform the extraction and organization of hundreds of gigabytes of stolen data. In some cases, exfiltration was achieved via bulk exports from compromised mailboxes.
• Maintaining access: The actor used AI to assist in maintaining access to compromised accounts and tenants by automating the registration of actor-controlled devices into the victim organization’s tenant.

In on-premises environments, the actor used AI to monitor the stealth and persistence of their implants. When their implants were flagged by security products, the actor used Claude to systematically identify, modify and redeploy the detected artifacts.

The result of the above is that AI has inverted the cost back onto defenders. Previously, defenders might have been able to slow an attacker’s operational tempo via the deployment of a new detection. Now, at least in theory, capable adversaries can “close the loop,” bypassing traditional security detections faster than defenders can develop and deploy them.

The actor’s malware included the following:

• Windows malware: PowerChrome, WUEngine, Shadow C2, MiniPlasma, CloudSyncSvc;
• Android malware: GiftDrop, a rebranded GiftsExpress Android surveillance RAT;
• iOS malware: DarkSword, an iOS exploit chain.

Indicators of compromise

ms365-live[.]com
teams.ms365-live[.]com
m365-owa[.]com
owa-ms365[.]com
ms365-device[.]com
mslivetest.duckdns[.]org
my-invite[.]org
chamber-ua[.]org
chathamhouse[.]eu
ukrinform-share[.]net
104.145.210[.]184
31.57.243[.]154
statistic-ms[.]live
static-ms[.]live
104.194.151[.]133
ad-g[.]org
104.194.159[.]55
docs-viewer[.]org
144.172.114[.]192
wa-connect[.]eu
mygreatmarket[.]org
mygreatmarket[.]com
213.145.86[.]112
2.26.53[.]194
cdncounter[.]net
static.cdncounter[.]net
stuseamandesilt[.]org
api.stuseamandesilt[.]org
cdn.stuseamandesilt[.]org
update.stuseamandesilt[.]org
itechx[.]tel
pdfviewer2024.b-cdn[.]net
meridian-protocol[.]org
meridiangroup-corp[.]com
projectnightcrawler[.]dev
metricwave[.]org
mgsend[.]org
148.135.195[.]111
185.198.234[.]26
185.198.234[.]101
149.54.42[.]106
104.194.149[.]228
38.146.28[.]132
38.146.28[.]75
wa-meeting[.]com
russianearabroad[.]com
russianearabroad[.]org
anna.manager@russianearabroad[.]net
events@embassy-protocol[.]int
msedgeupdate_v3[.]exe
msedgeupdate[.]exe
version[.]dll
WUEngine[.]exe
DiagHost[.]exe
client_20260507093021_4286d211_x64[.]exe
fix_network[.]apk
be99857449d2856dd5a84e21c8a3d5e0e01456adb44062ddec5a6b4970d8d42c
918fa52ae45ed60ba7cc8bdc99c3cbe9ab92e0375ec31fc05d0d4513be11c593

GTG-50014: ShinyHunters smash-and-grab opportunists

While some cyber threat actors may conduct targeted intrusions, seeking specific information for espionage or other purposes, others are less focused and deliberate in their operations. These opportunistic hackers have historically used broad-based scanning techniques to identify and probe unpatched internet-facing systems, before exploiting these vulnerabilities to compromise or take over the target systems. We’ve identified several advanced threat actors who used AI to uplift their opportunistic criminal activity, using Claude’s capabilities to accelerate their ability to rapidly scan, exploit, and take over target systems.

Opportunistic attacks come in many forms: racing N-day patches for mass exploitation; rummaging through public container stores, code repos, mobile applications, websites and more looking for credentials, tokens, and API keys; mass scan and exploitation of vulnerable internet facing devices; the creation of service accounts on novice service providers with poor security to escape their containers; prompt injection of LiteLLM or OpenClaw deployments; and more.

Many actors scour the internet for ways into networks and services, stealing data for sale and extortion and later reselling access. This was the case before AI. With AI, however, the pre-existing ecosystem of criminal cyber conduct has increased in scale and severity. With AI, diverse target environments are made trivial to understand and adjust to; unique and obscure configurations are made clear and exploitable. The old adage of “security through obscurity” is no longer viable in this new AI-assisted world: everything connected to the internet is a potential target for exploitation.

Once actors gain access, they typically move straight to databases and look for customer data. If the target is a software-as-a-service (SaaS) provider, they often use the stolen data to access the end customers, and make extortion demands, telling the provider that all of their data and their customers’ data will be leaked or sold online if they do not pay.

We identified and disrupted multiple clusters of financially motivated cybercrime activity conducted by operators suspected to be affiliates of the ShinyHunters collective, known for several large-scale data theft operations followed by pay-or-leak extortion demands. Although the affiliates appear disparate, and seem to be operating with their own tooling and operational workflows, analysis of their approaches and objectives shows that they are part of the same overall operation.

One French-speaking operator going by the aliases of (MeowSHA | frkoo | blazespider) ran a distributed credential-harvesting pipeline across a fleet of 10 AWS EC2 workers. This pipeline mass-downloaded 1.8 million distinct Android APKs from multiple app-store sources, decompiled them, and scanned for hardcoded secrets with TruffleHog. Verified findings were routed in real time to a Telegram group organized into over 100 source types. A parallel GitHub organization email harvester fed a second stream of stolen GitHub Personal Access Tokens. These two credential pipelines supplied the initial-access credentials for the bulk of the confirmed breaches associated with frkoo.

Operational security discipline by the operators was mixed. frkoo managed an EC2-based credential-harvesting pipeline, exposed their own EC2 staging IP, multiple Telegram bot tokens, a Squid proxy with hardcoded credentials and at least one public paste-site upload directly within a victim environment. They also registered a domain name impersonating the French national police, policenationale[.]cc (though we believe this served as branding for the criminal storefront rather than as a phishing lure). The subdomain autoshop.policenationale[.]cc served as the web frontend for the actor’s carding autoshop: a storefront selling stolen payment-card records (“fiches”) enriched with BIN lookups, full cardholder PII, and an interactive geolocation map of victim addresses. The shop was delivered to customers through a Telegram Mini App (@Soraki_Bot) backed by the actor’s “Soraki” platform, a PostgreSQL/GraphQL stack that also aggregated multiple French breach datasets (including a ~400,000-record telecom/ISP dataset with IBANs and BICs) into a searchable service.

Across the collective of operators, during multiple target intrusions, a target’s AI API keys were stolen from the target’s enterprise software vendors. One of the stolen API keys was then used by the attacker for roughly three weeks to conduct secondary attacks, which targeted other organizations including compromising a French retail chain and probing a Web3 identity platform. They also continued post-breach attacks against a nonprofit victim, and in the case of frkoo, continued development work on their own carding shop that masqueraded as a French police department site.

One of the more serious compromises was of a technology provider. The operators exfiltrated more than a terabyte of data, including hundreds of thousands of national identifiers and millions of payment card records, then staged the stolen material on a public website to pressure the victim into paying a ransom. At an airline, the threat actors accessed systems holding tens of millions of passenger records. At an energy company, the operators claimed that they could remotely control the charging current of electric-vehicle chargers installed in customers’ homes.

Another affiliate appeared to specialize in supply-chain theft, where a company is compromised in order to reach the downstream data of their customers. After breaching a software-as-a-service provider, the operators used that foothold to extract data belonging to roughly 200 of the SaaS company’s downstream customer organizations. It then conducted a session-store dump containing over 2,100 Azure AD token sets spanning more than 40 corporate tenants in about 34 hours. AI agents performed nearly all of the work.

In a different compromise, the actor leveraged Claude in a supply chain compromise of a software-as-a-service (SaaS) vendor to accelerate reconnaissance and to enable data exfiltration. The actor exploited a cross-site scripting vulnerability to gain access, escalated privileges, and ultimately exfiltrated data from thousands of downstream customer organizations. The actor used Claude by helping to identify, understand, and use developer and authentication APIs, create and convert privileged tokens, and build tools to enable bulk exports and cross-tenant data collection. Against a different target, the same attacker also claimed to have collected legitimate HackerOne bug-bounty payouts of $2,000 and $5,000 from two of the companies they infiltrated and extorted, treating BugBounty disclosure programs and intrusion as additional revenue streams against the same targets they were compromising. They also appeared to scrape HackerOne and BugBounty submissions as a form of reconnaissance during focused attacks on specific targets.

This threat actor’s operational tempo was relatively consistent. One breach of an enterprise software company took only hours from first access to bulk data theft. Another compromise escalated from a single stolen developer token to full administrative control of a victim’s cloud environment in roughly three hours. This was followed by iteratively scraping internal datastores, and in the case of supply chain attacks, iteratively accessing and scraping the end customer’s data as well. We detected and banned accounts associated with the ShinyHunters associates, implemented measures to detect and disrupt future misuse from the actors, and engaged government authorities, industry partners, and victims to remediate threats posed by the actors.

The use of AI during intrusions and data theft operations often resembles “vibe hacking,” wherein operators direct AI to achieve general goals like using a credential for an entity or retrieving data from a broad set of targets, then allow the AI to evaluate the environment, author and execute scripts, provide summaries, and repeatedly execute until the task is complete. Very often, the operator may not directly understand each target environment or the complexities of finding and accessing valuable information, instead deferring the specifics to the AI.

Security practitioners use the phrase “living off the land” to describe attacks that use tools that are already present in the victim’s environment. The opportunistic hackers described in this section have applied the same principles to AI. The operators treated the AI supply chain itself as both a target and a resource. They stole AI API keys from multiple target environments and used them to provide additional AI compute. In every instance, the API keys involved were stolen from Anthropic customers’ environments. Anthropic’s own systems were not compromised by this actor. We examine this pattern in detail in the section on the AI supply chain.

Attack lifecycle and AI integration

Sourcing and recon. Most intrusions began from compromised credentials. The actor also engaged in extensive scanning, vishing, phishing and domain spoofing operations to trick employees into giving access to systems.

Discover. Exposed access tokens were also discovered at industrial scale through a wide variety of automated scraping and mining projects. These included analyzing application binaries, code repositories and integrations, client side code, credential stores, container images, metadata endpoints, open storage and victim-deployed AI agents. An example of this is with one actor project that downloads all APK files from Google Play Store and searches them for exposed session tokens or other access mechanisms that could be abused for access.

Validate/qualify. Everything found is tested and qualified before use or resale, such as batch cloud key validation, purpose built login oracles, live replay against production, grading for resale value, and offline cracking.

Expand in-victim. One working credential is used to expand access within the victim, and used for things like whole-cluster secret dumps, admin-token amplification, CI/CD injection, database and session-table dumps, mining dumps for signing keys, and vendor-OAuth fan-out to every downstream tenant.

Exfil channels. Material moves out over six channels: consumer cloud storage, a private NAS over mesh-VPN, Telegram bot streams, staging inside victim clouds, C2 channels, and plain bulk API pulls.

Figure 7. Exfil channels.

Warehouse. Loot is warehoused for reuse and sale: a self-hosted estate that re-serves stolen databases, loot trees for each victim, a Telegram warehouse that also serves as the storefront, and working key stores.

Figure 8. Warehouse.

Mint/persist. New credentials and durable access are minted so the operation outlives rotation: cloud API keys in victim accounts, platform developer keys, forged sessions and 2FA codes, network backdoors.

Figure 9. Mint/persist.

Monetize. Monetization: resale channels and key pools, direct financial theft, extortion over the stolen data, dual-hat bounty income, and bulk data held for leverage.

Figure 10. Monetize.

Common workflows observed

Figure 11. Common workflows observed.

Indicators of compromise

updatebeacon.duckdns[.]org
esvfecawvjmchjslqyemho2fiduc59wzn.oast[.]fun
soraki-proxy.20245aad98d27b1b1a2f0f103e1d7ee0.workers[.]dev
soraki[.]cc
soraki[.]work
policenationale[.]cc
emailsecure[.]email
mozilla[.]ws
signin-1psswoord[.]com
on-pssword[.]com
ari-chain[.]com
arichain[.]network
bitmart-mystery[.]com
defi-claim[.]xyz
service-infos[.]info
0x0[.]st

Exfiltration locations

fuckyoubasil[@]s3.ap-tokyo.megas4[.]com
https[:]//s3.eu-central-1.s4.mega[.]io/fuckyoubasil/
https[:]//s3.ap-tokyo.megas4[.]com/<victim-name>
<victim-name>.s3.ap-tokyo.megas4[.]com

Telegram group IDs

Table 1. Telegram group IDs.

Attacker egress IPs

Table 2. Attacker egress IPs.

GTG-10007: Exploit foundries and autonomous attack frameworks

Historically, cyber operations have been limited in their scale and impact by two key constraints: the supply of working offensive exploits, and the supply of skilled operators capable of deploying those exploits. We have identified multiple threat actors who have effectively established automated exploit foundries with AI. In doing so, they have designed and implemented autonomous workflows by which they can direct Claude to conduct vulnerability and exploit research agentically around the clock. Across multiple instances, we identified Claude being used to meaningfully accelerate the pace of vulnerability research, testing, and exploit design.

We identified and investigated a sustained espionage operation, tracked as GTG-10007, conducted by Chinese-speaking operators likely residing in Changsha in China’s Hunan province. Two of the operators were identified as undergraduate students at a Chinese university in Hunan studying curriculum in a School of Computer & Communication Engineering. One had a prior internship at a Chinese security company, Sangfor, and was actively interviewing for a role at a different Chinese security company, QiAnXin, for an offensive cyber operations role. Multiple operators within this group used Claude as the engineering and orchestration layer of a coordinated offensive program involving a variety of tasks: intrusion attempts against production systems; reconnaissance of foreign-government networks across the Middle East, Europe, and Southeast Asia; a standing vulnerability-research and exploit development effort against major endpoint-security products; malware development; and an intelligence-collection platform. Notably, a team ran parallel workstreams that had shared tooling and infrastructure bases and persistent campaign records that maintained context between working sessions; it also had collection and vulnerability research capabilities that kept operating while its owners were away.

The actor targeted roughly fifty organizations, spanning education, retail, energy, technology, healthcare, finance, manufacturing, as well as multiple government agencies globally. The actor compromised an education-technology company, extracting hundreds of megabytes of bulk student personal data from the company’s cloud storage. They also gained access to a retail company’s production systems, reaching internal hosts and demonstrating their ability to modify the live environment. Finally, they targeted a Southeast Asian government agency, retrieving citizen records including names, phone numbers, and home addresses.

The group maintained an autonomous vulnerability research program. Its centerpiece was sustained research against a major security product (of a class of software deployed specifically to detect intrusions) which produced multiple previously-unknown vulnerabilities that were validated by the actor in their own lab environment. The same research effort produced working exploits for several families of network and security appliances. In a separate workflow, the actor was observed conducting cyber operations involving exploitation attempts against those same appliances owned by multiple government organizations globally. We banned accounts associated with the actors and deployed additional monitoring to detect and ban related activity.

Distinct workstreams were run in parallel. One workflow conducted cyber operations involving exploitation and intrusions, another performed foreign-government reconnaissance, another reverse-engineered security products in search of new vulnerabilities, another developed and tested custom malware, and another built and maintained collection infrastructure.

Autonomous espionage

The operators routinely ran “agent swarms,” where a lead AI agent decomposed reconnaissance and post-exploitation work and dispatched it to many subagents running in parallel. The operation maintained persistent campaign memory. Target lists, harvested credentials, engagement state, and standing instructions were saved across working sessions, so each session could be resumed mid-campaign with the program’s accumulated context. The cluster built and operated an intelligence-collection platform that ran unattended bulk harvesting of open-source material aligned with state intelligence priorities (including publicly accessible military doctrine and official publications, regional defense reporting, and policy sources).

Appliance zero-day research: Binary reversing and exploit-development loop

The following is a brief description of the loop the actor used in its zero day exploit foundry operations. The actor configured autonomous AI-driven workflows to target appliance firmware and binaries. The workflow started with loading firmware and binaries into a decompiler through a tool server. An assistant agent surveyed the image, and walked decompilation and cross-reference chains (over thousands of decompile calls, with back-to-back decompile sequences dominating the call stream). It then formed vulnerability hypotheses against a knowledge base it curated over time and prior proof-of-concept lookups. From there, the workflow tasked the writing of exploit code against those hypothesized vulnerabilities, and tested the code against lab copies of the target product. The workflow iterated over edits of the exploit code until success, at which point the chain landed in the operator’s private exploit portfolio.

Vendor firmware images were obtained and decrypted with a purpose-built skill, unpacked into root filesystems, and loaded into disassembler and audit sessions. Vulnerability patterns were hunted component-by-component with parallel agents instructed to require evidence and use project memory. One workflow iterating continuously on network appliances yielded more than a dozen possible zero day findings in a single month.

Figure 12. Appliance zero-day research: binary reversing and exploit-development loop.

Attack-surface and OSINT reconnaissance loop

Other AI workflows ran continuously to conduct reconnaissance. This workflow took input for scan scopes seeded from target verticals and ran through an asset search engine via a dedicated tool server and bundled probing tools that fingerprinted the results. The identified exposed surface was mapped and entry points were qualified against known vulnerabilities. Each round’s findings fed a persistent project memory, and expanded the target set for the next sweep. The actor used the framework to target multiple foreign government and diplomatic agencies, in addition to over a dozen domestic Chinese companies.

Figure 13. Attack-surface and OSINT reconnaissance loop.

Autonomous collection-fleet loop

A fleet of thirteen standing collection AI agents ran on a scheduled job to identify and download content from target websites, including publicly accessible US military and government sites like contract postings, and social media personas. The workflow did this through layered crawlers, anti-bot bypass techniques, and commercial proxy exits. An adjacent pipeline summarized and scored the retrieved content with an intelligence report-styled framing. From there, the workflow digests were delivered to a distribution portal.

Figure 14. Autonomous collection-fleet loop.

Hands-on intrusions

The operator engaged primarily in development, workflow output consumption related areas and during intrusion events produced from the autonomous exploitation workflows or in cases where access was obtained through weak or harvested credentials and exposed consoles. With access to internal networks, the AI assistant enumerated hosts, escalated via credential reuse and exposed management surfaces, harvested credentials and data stores, and staged material back to operator infrastructure then pivoted to the next host on what was harvested. Despite targeting entities globally in AI workflows, the actor concentrated hands-on efforts exclusively on domestic China victims.

AI supply chain as target, loot, and attack compute

Access to the uplift granted by AI is highly sought after by malicious actors and the broader criminal economy. Access to AI in the form of compromised API keys, session tokens, and devices has increasingly become the sole objective of multiple criminal groups. These groups then often sell that access through brokers, which often feed into fraudulent AI reseller networks that rotate in new stolen API keys and session tokens until they exhaust their usage. Malicious actors also use or purchase these stolen API keys and session tokens from brokers for their cyber attack operations.

A criminal AI supply chain has established a range of pathways to farm victim API keys and session tokens. One such approach involved masquerading as real AI service providers to deliver malware. The actor stood up websites that purported to be an intermediary service between multiple AI models and offered discounted access to frontier AI models. Site visitors would be compromised in a variety of ways, the most persistent one was by having the victims download and install malicious client side applications often spoofing as popular AI harnesses including Claude Code but were in fact credential harvesters that would gather all of the victim’s credentials and authenticated session tokens on their device and send them to the attacker. That included any AI related session tokens or API keys on the victim’s device. As the victim’s API keys or account may be identified as compromised and reset, the credential harvester continued to identify any new sessions on the device and sent them to the actor. In so doing the actor effectively mimicked the same fraudulent reseller networks they were supplying compromised credentials to but instead used this scheme to have victims continuously feed their credentials to the attacker and subsequently be sold to the fraudulent resellers.

GTG-50021 is a group that engaged in similar activity. They are a Russian and Ukrainian speaking group, one of whom went by the alias “kl1zy.” They ran a fraudulent AI reseller operation offering cheap Claude access—which turned out to be neither cheap nor actually Claude. Customers believed they were buying discounted Claude access, but their traffic was in fact silently proxied to a different AI model while the reseller’s tooling installed a credential harvester, stealing their Anthropic account credentials and selling them onward to other AI proxy resellers for malicious use.

GTG-50021 indicators of compromise

awstore[.]cloud
kiro[.]cheap
sys-tools[.]cfd
aws-us-east-3[.]com
holdboost[.]store
deltaclient[.]xyz
iymkjuzymkapovrntoxy.supabase[.]co

There are also groups that attempt to target the AI ecosystem and supply chain itself, seeking to gain access to restricted models via AI vendors, evaluators, and trusted access programs. For example, multiple actors were observed compromising AI wrapper services’ implementation of LiteLLM—they used prompt injection to exfiltrate the production API keys used in their cloud-hosted container environments.

Fraudulent resellers have increasingly been supplied by compromised access. Most commonly, this comes from legitimate customers who have inadvertently exposed their API keys and session tokens in their products, applications and public code such as GitHub, mobile application install files, Docker containers, websites, and chatbots. Malicious actors are constantly mining these sources for exposed keys and analyzing them for authentication abuse vectors.

Operators who obtain AI credentials gain three things at once:

• Loot: Stolen keys and accounts have resale value in established markets;
• Compute: Having the credentials means that their attack workloads can run at someone else’s expense;
• Cover: The activity is attributed to the credential’s legitimate owner.

A hacktivist campaign (described later in this report) ran for a month entirely on stolen API keys. ShinyHunters affiliates, on obtaining a victim’s AI keys during an intrusion, switched their own attack workloads onto the victim’s keys. GTG-50020, after compromising an AI vendor’s evaluation sandbox, took its production keys first.

AI API keys and session tokens are targets; the integrations customers build around AI such as sandboxes, proxies, and resellers are part of the attack surface. Organizations should treat AI keys and agent integrations with the same level of seriousness as they do production credentials—because attackers treat them with the same level of seriousness, too. AI access should be purchased only through authorized channels. An alleged discount that requires routing traffic and credentials through an unknown intermediary introduces tremendous risk to user data and systems.

GTG-50020: From hotel bookings to the AI supply chain

GTG-50020 is a Russian-speaking, financially-motivated actor who had historically conducted intrusions against hotel booking and financial technology platforms. In one intrusion, they exfiltrated roughly 26 gigabytes of data from one victim and sought payment in extortion attempts (or from selling the data on darkweb forums) of between $1.5 and 2.5 million.

They then redirected the same tradecraft towards the AI industry. By injecting malicious instructions into an AI vendor’s automated evaluation sandbox, the actor caused the sandbox to hand over the credentials it held—including the production AI API keys from multiple providers belonging to that vendor.

Those stolen keys were then abused by the actor: they continued their intrusion attempts against the vendor and other unrelated targets simultaneously. In effect, when they obtained the target’s API keys, they automatically switched to using the victim’s keys instead of their own. A follow-on campaign run from the same infrastructure attacked roughly thirty AI companies in about four days with similar techniques. They identified one successful attack path and repeated it against all thirty targets, adapting slightly to account for differences across the targets. The actor’s stated goal, pursued across more than a dozen avenues, was access to a pre-release Claude model. The actor never gained access; every attempted path failed. In all of this, the keys involved were customers’ keys stolen from customers’ environments. The actor never compromised Anthropic’s own systems.

This case is the clearest demonstration to date that the AI supply chain has become a deliberate criminal target. The actor pursued AI vendors for their production API keys, and had an explicit ambition—which, to be clear, was never realized—to gain access to pre-release AI models.

Human-directed AI pentest loop

The operator maintained a per-target scope file that launched a custom workflow to delegate work to parallel reconnaissance and exploitation agents. The agent’s findings were re-tested for working access; if viable, they were merged into an incremental report. This workflow iteratively looped against the next target domain.

Figure 15. Human-directed AI pentest loop.

Autonomous exploitation pipeline

The actor used a containerized open-source pentest platform fronted by a local model gateway. It was aimed at a target’s web applications. Worker agents ran injection, XSS, authentication-bypass, and SSRF testing without human supervision, collecting potential findings and credentials into the operator’s workspace. This loop was run with exploitation enabled against production systems, meaning it both attempted to identify vulnerabilities and actively exploit them for access in the same workflows.

Figure 16. Autonomous exploitation pipeline.

Fraud account factory

Residential proxies and antidetect browser profiles were provisioned, after which bots drove signup flows on exchange and marketplace targets. Commercial CAPTCHA-solving services, automated inbox polling, and automated identity-verification steps defeated onboarding controls, and the resulting verified accounts were banked for later operations.

Figure 17. Fraud account factory.

KYC interception cloak

The actor also engaged in credential theft and phishing campaigns. Victims were directed to lookalike verification domains whose reverse proxy relayed the real know your customer (KYC) flow, so the victim completed genuine identity verification while the operator captured the verified session and documents from the proxy relay in the middle. The captured session was then used by the actor from their machines to access the target service and data.

Figure 18. KYC interception cloak.

GTG-50029: Hacktivists targeted European political and affiliated entities

AI has helped to close the capability gap turning low-level “hacktivists” into advanced persistent threats. As demonstrated repeatedly throughout our case studies, AI capabilities raise the baseline as well as reduce the resource requirements for offensive cyber operators. In this section, we provide details of a hacktivist campaign we investigated and disrupted, in which small well-motivated operations were able to achieve significant goals due to the integration of AI in their operations.

In the spring of 2026, a single French-speaking actor was observed using Claude to target European political parties, media, think-tanks, and the SaaS providers used by these organizations.

This actor built their own custom Rust-based scanner designed to scan and validate public containers for exposed API keys. Once keys were validated, the actor’s tool was designed to rotate key usage across a local proxy layer. This enabled the actor to blend their traffic in with the traffic from the legitimate owner of the stolen API keys. As we saw in the case studies above, access to an exposed API removes the barrier to entry for a rogue actor.

GTG-50029 provides another example of an actor embracing the use of AI across the kill chain. The actor used AI’s agentic coding skills in a framework that helped it manage sub-agents; the sub-agents were themselves responsible for pre- and post-authentication reconnaissance, code review, and vetting findings from different AI models.

Novel exploitation and purpose-built tooling

The campaign’s signature technique to initially access their target systems was exploiting a previously undocumented WordPress re-installation race condition that created a rogue administrator account without valid credentials. The actor used Claude to develop and debug the exploit in the same session, including creating a lab harness. It succeeded against at least four victim websites.

In one case, the actor compromised a political campaign management platform via an exposed search endpoint. The actor tasked their agents with iterating across this endpoint and ultimately exfiltrated approximately 140,000 records that included users’ political opinions.

Against another target, the actor implanted a webshell hidden among font assets. A webshell is a small script placed on a web server that lets an attacker send commands remotely to be run by the server, effectively a backdoor reachable through the website itself. The actor built the webshell on the fly as they identified the vulnerability enabling the upload. They also used a WordPress “must-use” plugin, a type of plugin that runs on every page load and can’t be switched off from the admin dashboard, that harvested submitted credentials, encrypted them with per-site public keys, and staged them for pickup. Additionally, GTG-50029 poisoned the victim’s backups, presumably to maintain persistence. If the victim moved to restore their previous environment from backups, they would be re-infected.

Finally, the actor compromised a media outlet by deploying a browser-exploitation C2 framework that hooked the organization’s readers through an injected script. This enabled the actor to fingerprint thousands of visiting browsers. We observed the actor specifically hunting for the editorial staff’s sessions and credentials via this framework.

The actor’s signature tool was “fafsearch,” a purpose-built doxxing platform. This platform provided a compiled search engine, complete with ingestion pipelines, the ability to cross-reference individual breach dumps against exfiltrated data, normalization for national identity numbers and phone numbers, ranking logic, tests, and a containerized deployment. The actor loaded this platform with tens of millions of rows, including data such as national health identifiers and information from justice system breaches, and fused it with material they’d obtained as part of their own intrusions. They published the result as a set of anonymously hosted dark-web services where individuals affiliated with the targeted political movement could be looked up by name.

This is one of the clearest cases we have seen of AI-assisted software engineering applied directly to a mass attack on privacy—and the entire platform was created by just one person.

Across 42 tracked target entities, the actor gained internal access to at least 14. The actor accessed and exfiltrated an estimated 12 to 26 GB of database dumps including information on political party donors and member records, a 15,000-message mailbox, student application records (including data from minors), payment-provider data. The actor also set up live credential interception. With the exfiltrated data, the actor staged per-victim encrypted archives on an actor-run Tor leak site.

Prevailing trends

Overview

Despite the fact that each of the case studies above shared no connection, there are two broad developments that are relevant to each of them.

AI tradecraft is proliferating: Diffusion of AI-enabled cyber operations

Just as in the legitimate economy, AI has diffused through the cyber battlefield. Multiple groups including GTG-10002, as previously reported, developed and utilized their own autonomous attack frameworks; while other groups including GTG-50020 and GTG-50029 leveraged publicly available offensive agent frameworks like PentAGI. These public frameworks reproduced much of the same scaffolding for anyone who downloads them, and several operations in this report ran on them or on derivatives.

A marketplace supporting the battlefield has formed as well. We discovered GTG-50021 creating fraudulent resellers offering discounted Claude access, while silently proxying user traffic to a different model, and harvesting the Anthropic credentials of anyone who signed up.

Diffusion is occurring across different classes of threat actors, different regions, and different types of mission. The capabilities described in this report should be assumed to be available to any actors who are motivated to use them. We continue to invest in resources, tooling, and personnel to develop more effective ways to stay ahead of these adversaries and disrupt their access before harm is realized. But we anticipate that we will continue to face persistent threats from highly-motivated, (and sometimes sophisticated state-sponsored) malicious cyber actors, and will continue to work with private- and public-sector partners to share threat information and best practices to mitigate these threats.

This report details campaigns directed by both smaller criminal groups and state-sponsored organizations. The diffusion of AI has leveled the playing field giving both classes of actors access to the same set of advanced capabilities. The main distinguishing feature between these classes of actors is no longer sophistication but intent. Previously, state-sponsored actors were able to leverage access to greater resources to deploy more advanced cyber capabilities. The advance of AI provides non-state actors access to the same capabilities previously only accessible to state actors. A hacktivist using stolen API keys (GTG-50029), a financially motivated crew harvesting credentials from mobile applications (GTG-50014), and a state-nexus espionage operator (GTG-20006) all showed similar methodology: they ran multi-victim campaigns using agentic AI that would previously have required teams of operators. They built custom tools, executed intrusions, and processed stolen data at volumes no individual human operator could manage manually.

The attacks themselves are familiar, involving stolen credentials, unpatched edge devices, exposed services, SQL injection, and phishing. None of the operations in this report depended on some entirely novel technique that defenders have never seen. Instead, the economics of the attacks have changed. The kind of labor that previously set the well-resourced operations apart from everyone else—reconnaissance, exploitation, tool development, and data processing—are all now delegated to AI models, which run in harnesses at machine speed and in parallel. The results are visible in the numbers reported above: breaches completed in two to three hours, and dozens of victims handled in parallel by individual operators.

AI’s increasingly autonomous role in cyber operations

The AI use in the cases in this report spans a wide range of levels of autonomy. At one end, actors used Claude conversationally: it acted as an engineering assistant in the creation of malware, phishing kits, and surveillance tooling. Further along the spectrum, threat actors directed Claude to execute operations (such as running commands against victim networks, harvesting credentials, and exfiltrating data) with a human making each individual targeting decision (GTG-20006). At the far end, operations ran autonomously, with minimal human input or supervision: these included multi-agent frameworks conducting reconnaissance, exploitation, and theft against multiple victims, in parallel, for hours or days at a time (GTG-50014, GTG-50020, GTG-50029). We also observed a collection fleet running on a pre-set schedule with no human in the loop (GTG-10007), as well as scheduled jobs renewing stolen access tokens and harvesting victim cloud storage with no human involvement (GTG-20006).

It’s important to bear in mind two caveats. First, humans have retained the decisions that matter most to them: for example, they’re still heavily involved in target selection, monetization of findings, and review of results. Second, autonomy and harm are separate axes: Autonomy multiplies the scale and speed of an operation, and reduces operating costs and complexity, but severity is still determined by a multitude of factors. Several of the most serious compromises we report here came from operations where a human directed every step. In economic terms, AI autonomy compresses the cost side of attacker ROI calculations, lowering the skill threshold and labor required per campaign, while leaving potential payoffs largely unchanged. This favorable shift in unit economics makes previously marginal targets viable and encourages higher-volume, lower-touch operations.

Appendix A

The following is a list of skills developed by threat actors to build out their AI-enabled workflows.

Figure 19. Skill breakdown.

Detecting and countering influence operations using Claude

In this section, we focus on influence operations, which we define as efforts to manipulate the information environment—including political, civic, and public discourse—with the intent to deceive, distort, or covertly influence the perceptions, beliefs, or behaviors of individuals or groups, typically while concealing the activity’s origin, sponsorship, or coordination.

Our first threat intelligence report discussed one commercial influence-as-a-service network. Since then, we’ve discovered and disrupted larger, more sophisticated operations. We’ve seen groups of actors use Claude to build networks of fake social media profiles and entire news sites, leveraging these platforms to publish deceptive content, while completely concealing the entities behind these operations.

An actor might create a hundred social media accounts that appear to belong to ordinary citizens of a country, then have all of them post content amplifying the same political view over the course of a week. The accounts are not real and the opinions are not genuinely held. Nothing on the surface identifies who’s actually behind this effort.

This report details nine of those cases. They originated in Russia, Iran, Turkey, and across the Gulf, South Asia, Africa and Europe, and targeted audiences on six continents. The actors behind these operations included governments, state-aligned propaganda institutions and state media, as well as private firms selling influence to paying clients, domestic political operators, and in one case an opposition movement in exile.

Notably, several of these campaigns were timed to national elections. For instance, Russian state media produced fabricated claims about Moldova’s president before the September 2025 vote, and a pro-government operator in Kenya prepared fake grassroots social media posts ahead of Kenya’s 2027 general election.

How we investigate

Influence operations are neither new nor unique to the internet. An established community of journalists, researchers, and government agencies has studied these tactics, exposed them, and built the frameworks we use to understand them.

However, while a social media site usually sees an operation once its content is already circulating, we may see it on Claude while the operation is still being built. Actors use AI to plan their campaign, choose their targets, and write the material. Those types of tasks produce signals that our systems are trained to detect, which often lets us disrupt an operation before it gets off the ground.

Our visibility into these operations ends once it’s live. To verify our findings and understand what happened after content left our platform, we rely on open-source research, cross-platform industry data, and public reporting. Each case explains how we found the activity and who else contributed to the investigation.

Once we identify an operation, we ban the accounts involved and attribute the activity to the organization behind it. We use what we learn to sharpen our safeguards, feeding the findings from each investigation, including novel tactics and behaviors, back into our detection systems.

How we measure reach

To accurately evaluate the impact of each influence operation, we apply the Breakout Scale, a six-category framework widely accepted by industry researchers. The scale categorizes impact based on cross-platform migration and reach. Category One represents content that is confined to a single community on a single platform, while Categories Two through Six measure increasingly higher levels of public exposure and distribution.

Trends in influence operations

1. Influence sold as a service. As we noted in our previous report, commercial actors hired by entities (political, government, et cetera) produce content for whoever wishes to pay. This gives plausible deniability to the ultimate commissioners of the influence operations, and puts this capability within reach of actors who can’t or do not want to build it themselves. In two cases presented here, a working advertising or marketing firm ran the operations alongside ordinary commercial work.
2. AI as a newsdesk. In several cases, Claude was slotted into a human-edited pipeline that was already up and running, playing the role of a sub-editor or content creator. This allowed low-resourced actors to run influence operations at a scale well beyond what they could accomplish alone.
3. AI helped to build the apparatus as well as the content. Actors had the model produce doctrine manuals, opposition dossiers, ministerial portfolios, persona systems, target databases, employment contracts encoding editorial loyalty, and scoring rubrics that were used to rank staff who were part of the operation. This kind of work would otherwise need a staffed program office.
4. Complex tool use. We found influence operations that were built to persist and easily scale over time. Markdown files containing doctrine were reused almost verbatim across hundreds of sessions. Actors kept lists of banned words inside their AI agents, maintained shared files of approved sources and evasion rules, and ran custom software that called Claude in fixed batches. The central setup meant that actors producing content never needed to coordinate with or even know one another. One actor was building a course to teach the workflow to others. Increasingly, operations are not run using individual prompts. Instead, a great deal is embedded within persistent memory files.
5. Laundering of attribution, sourcing, and certainty. Actors used Claude to engineer content so that state or commissioned narratives appeared to come from independent voices. Actors prompted Claude to intentionally strip state attribution from republished material, passing claims through chains of outlets so they read as independently confirmed. In one case, tied to a Russian state media operation, an actor produced claims the model flagged as unverified, then instructed it to drop those caveats and present everything as confirmed, so the material would read as established fact.
6. Increased operational security. Threat actors find ways to obscure the origins of their identities. This began at the outset of the content creation process: actors asked the model to strip the marks of automated text and to sound organic, built account warmup and evasion logic, and removed metadata and codenames before delivery. They also laundered their access to Claude itself through VPNs, foreign phone numbers, rotated accounts, and third-party services that masked their IP address.
7. Fake personas (and impersonation of real personas). Actors generated full personas by using AI-generated profile photos, invented biographies for fake reporters, and fabricated political spokespeople. We also uncovered impersonation of real people and real institutions (including a state spokesperson and a human rights organization) and forged government documents.
8. Targeting people and accountability mechanisms. We observed the cloning of a real activist’s account to hold live conversations with his contacts inside Iran (alongside arrest-history profiles of other Iranians), ghost-written testimony delivered in a live UN Human Rights Council session, and counter-dossiers on UN Special Rapporteurs.
9. Influence operations often fail to reach a genuine audience. Because we sit at the production stage of operations, upstream of platforms like social media platforms, we may detect and disrupt an operation while it is still being put together. Most of the content we discovered drew little or no authentic engagement, and in several cases we disrupted the operation before it could build an audience. The widest authentic reach occurred where state media outlets were the distribution mechanism (including FM radio, satellite and shortwave radio, and global television).

GTG-04001: Disrupting a Russian foreign information manipulation and interference operation in the Central African Republic

We removed an account run by a Russian-speaking actor in Bangui who provided the production backbone for a Russian state-aligned Foreign Information Manipulation and Interference (FIMI) operation targeting the Central African Republic (CAR).

The actor ran a daily content operation through Radio Lengo Songo (98.9 FM), coordinated with the Russian state media outlets RT, Sputnik Afrique, and TASS, and the Russian House in Bangui. Whenever the user generated content, they explicitly instructed Claude to embed the pro-Russia, anti-France talking points in the stories. To ensure absolute deniability, they pushed the model to strip away classic formatting habits, actively preventing the news feeds from reading like synthetic, AI-generated text. A majority of the sampled activity was pro-CAR government, pro-Wagner, anti-France and anti-CAR opposition narratives.

A recent investigative report by the All Eyes On Wagner project showed that the radio station was created and funded by the Wagner Group in 2017. The actors designed a pipeline to channel their fabricated content through the station and straight onto the national broadcaster. They managed this by trading airtime for slots on SputnikPro, Rossiya Segodnya’s media training program for foreign journalists. This setup ensured that official Russian state material would reach local listeners under the guise of ordinary national programming.

On the surface, most of the content looked like it was written by a regular CAR journalist, but our investigation linked the actor to Politology, the Africa Corps/Wagner influence branch assessed to have come under the control of the Russian Foreign Intelligence Service (SVR) in late 2023. We assess that the individual was acting as Politology’s local media coordinator on the ground. Ultimately, the actor distributed Russian state-aligned propaganda. This was a Russian state-directed covert operation built to manipulate and interfere with the Central African Republic’s information space.

Using the Breakout Scale, we would assess this operation as Category Four (content broadcast daily through Radio Lengo Songo on 98.9 FM, amplified through Telegram channels and carried by local news outlets in CAR).

Key findings

• The operation was entirely foreign-run but carefully engineered to appear as though it originated from Bangui. The Russian-speaking actor directed the output, while the contracts, scripts, and posts presented it as the work of a Central African radio station.
• The network used Claude to automate their human resources and internal management. They tasked the model and it generated contracts mandating loyalty to the President of CAR and “Russia and its contingent.” They also used the model to write job descriptions, scoring rubrics, and a three-strike dismissal process. The actors then scored staff articles against these criteria and used Claude to get recommendations on which employees to keep and which ones to fire. When Claude flagged the political weighting, the actor relabeled it in neutral terms and kept the scoring.
• The actor engaged in three additional activities aimed at political control and influence. They organized a recurring surveillance operation to track and update data on CAR opposition political figures. In addition, the actors drafted strategic talking points and statements for spokespeople in the Russia House, a cultural and information center Russia uses as a vehicle for soft-power and political hub abroad. Finally, the actor produced forged CAR government documents, including Gendarmerie and Ministry of Defense communications, built from original design files.
• Claude refused to comply with the operation’s most aggressive request, which involved naming real individuals as militants to draw security action against them. The actor pivoted to anonymous-source framing instead.

Attack lifecycle and AI usage

The foreign actor supplied the topic and the talking points, and used Claude to turn them into briefings, contracts, scripts, graphics, and posts. Several were prepared for delivery to the Presidency’s spokesperson and the Russian House director. The reused templates and standing instructions show the planning was mostly done offline before any prompt was sent to Claude.

Figure 1. The Pro-Russian Telegram channels associated with the operation that are always exported for stylistic voice analysis, cloning and distribution.

Organizational nodes

Table 6. Organizational nodes.

RTK (Rust Token Killer) filters and compresses terminal output before the AI agent reads it. With over 79k GitHub stars today, RTK is one of the most popular tools to make AI coding cheaper.

One X post saying RTK could cut Claude Code tokens by up to 60% reached 313K views.

Yet JetBrains’s SkillsBench run found no savings. The README has a disclaimer:

RTK cuts up to 90% of the bash output your agent reads. […] it is not the same as cutting your bill by 90%.

So “less terminal output” is not the same as “cheaper AI coding”. It can help, be a no-op, or backfire (more turns or lower quality). In this post, we present our findings after several days and over $1,500 spent on tokens.

How RTK works

RTK can rewrite Git, test, package and file commands the agent runs through its shell tool (Bash in Claude Code, bash in OpenCode). Each rewrite returns a terser version of the same output.

For example, RTK keeps file names, sizes and permissions (644 means rw-r—r—), but drops the owner and date:

$ ls -la /app/warriors
-rw-r--r-- 1 root root  824 Sep 13  2025 g2-clear.red
-rw-r--r-- 1 root root  487 Sep 13  2025 paper.red

$ rtk ls -la warriors/
644  g2-clear.red  824B
644  paper.red  487B

Testing RTK on Terminal-Bench 2.1

RTK compresses terminal output, so we tested it on Terminal-Bench 2.1, a benchmark with heavy terminal interaction. We stayed on 2.1 rather than the newer 3.0 and 4.0: agents pass most 2.1 tasks, while 3.0 and 4.0 are still a challenge. Cost only matters for tasks that pass.

We ran Claude Code with Fable 5.0, and OpenCode with DeepSeek V4 Pro 0813 through OpenRouter. Each task was scheduled five times without RTK and five times with it, on the same model route, platform and task-specific timeout.

After removing four Fable security tasks that got refusals, the final comparison covers 85 Fable tasks and 89 DeepSeek tasks, or 1,740 attempts.

The first chart was promising

With RTK, costs fell by 5% for Fable and rose by 5% for DeepSeek.

Pass rates were lower with RTK: by 1% for Fable and 2% for DeepSeek. Both pass-rate gaps are small.

When we divided all spending, including failed attempts, by the number of passes, Fable was 3% cheaper with RTK, and DeepSeek was 7% more expensive.

Another way is to weight every task equally, because one expensive task can outweigh many cheap ones. We compared the mean of each task’s baseline attempts with the mean of its RTK attempts, then averaged those changes.

On this task-level measure, Fable was 1% more expensive, with no clear difference from zero. DeepSeek’s task cost rose 17% on average.

Accounting for failures does not change the trend. Across the 36 DeepSeek tasks where all ten attempts passed, the increase was still 18%.

One task made the difference in the whole benchmark

Almost all of Fable’s savings with RTK came from one task: winning-avg-corewars. Both setups passed every attempt, but with RTK it finished in about half as many turns. Across the other tasks, the savings were less than 1%.

DeepSeek had the reverse result on that same task. Both setups passed every attempt, but RTK took more turns and cost more. Even without that task, costs remained higher with RTK.

rtk gain is useless as a cost metric

RTK documents rtk gain as raw minus filtered command output in bytes, divided by 4, not a count of billed tokens.

Across 445 DeepSeek RTK attempts, RTK reported 349.2 million tokens saved, a 89% reduction.

Large reported token savings did not mean cheaper tasks.

In train-fasttext, the model requested head -1 train.txt twice. RTK credited 120.5 million tokens saved each time by comparing those limited reads with the whole file. Those two calls accounted for 69% of the comparison’s savings counter, although the requested commands would never have returned the whole file.

Treating rtk gain as money saved assumes the rest of the attempt would stay the same. RTK can change the agent’s next turns. rtk gain does not account for the cost of those turns.

This is where social posts go wrong: rtk gain counts removed output, not money saved, and it can make a more expensive attempt look optimized.

RTK bugs can bite you

One DeepSeek git-multibranch attempt got stuck in a loop. The agent ran a find with a flag that rtk find 0.45.0 did not support. The plugin rewrote it to rtk find, which failed with “Use find directly”. Every retry was rewritten again. RTK fixed this in 0.46.0, after our runs.

The agent accumulated 339 consecutive errors before its timeout. It still passed the task, but cost about 9× as much as the matching baseline attempt, which also passed. One outlier attempt; the trend holds without it.

Terminal output is a small share of the bill

Without RTK, tool output made up about 11% of Fable’s input tokens and 40% of DeepSeek’s.

In the RTK attempts, 31% of Claude Code’s terminal calls and 51% of OpenCode’s terminal calls used RTK.

RTK rewrites only shell commands: its Claude Code hook matches the Bash tool and its OpenCode plugin acts on bash calls. Both platforms expose file reading and searching as separate Read, Grep, and Glob tools, which bypass RTK. About half of Claude Code’s Bash calls already limited their own output with head, tail, or wc.

In agentic coding, the context is cached after each turn, so later reads of terminal output mostly show up as cache reads. Those cost 1/10 of regular input tokens for Fable, and 1/30 for DeepSeek.

In DeepSeek, RTK reduced terminal-output characters by 9%, yet prompt tokens rose 9%. Uncached input fell 1% and cached input rose 9%. Model output, including reasoning, accounted for 56% of cost with RTK and 57% without it.

Extra turns can erase the savings

When the agent took more turns, task cost usually rose with it.

DeepSeek’s RTK attempts took more turns on 58 tasks, and 44 of them cost more. They took fewer turns on 28, and 23 of them cost less.

The average DeepSeek turn had 7% less input with RTK, but there were 18% more turns overall. Smaller turns did not add up to less total input.

One extra agent turn can cost more than the compression saved. It is the same tokenflation problem in another form. JetBrains saw the same pattern on SkillsBench: RTK added turns at low effort and did not lower cost at high effort.

RTK does not make AI coding cheaper

On Terminal-Bench 2.1, Fable’s savings depended on one task and did not hold across tasks. We do not recommend RTK as a generic cost-saving tool.

Individual transcripts show that current frontier models already use the terminal efficiently (just ~7% of Fable’s context was terminal output). Models use techniques like head -n or tail -n themselves. RTK probably helped more with older models. Today it is a niche optimization, not a source of general savings.

Tested with RTK 0.45.0, Claude Code 2.1.220, OpenCode 1.18.25 and Harbor 0.20. Trajectories available on request for follow-up research. Thanks to Piotr Migdał for his review and feedback.

I’ll admit that until fairly recently I had no idea git worktrees existed. They’ve been part of git for a decade1 and I never once needed them. Feature branches did the job just fine - create a branch, do the work, merge it, delete it, and start over.

What finally introduced me to worktrees was, of all things, AI coding agents. Tools like Claude Code create a worktree for each task, so several agents (or several sessions of the same agent) can work on the same repo in parallel without stepping on each other - or on you. Suddenly my projects directory was full of cider-this and cider-that siblings, and I figured I should understand what’s actually going on there.

Worktrees vs Branches

A branch is just a movable pointer to a commit, and making one is basically free. The catch is that a repository has a single working directory, so working on two branches means switching that directory back and forth. You know the routine: stash your half-done work (or commit it), check out the other branch, do the thing, check out the first branch again, unstash. It works, but it’s tedious, and it gets worse when the two branches leave your project in different build states and every switch means recompiling half the world.

A worktree gives you an additional working directory attached to the same repository:

$ git worktree add ../cider-smart-targeting -b smart-form-targeting

Now ~/projects/cider-smart-targeting is a full checkout of that branch, while your main checkout stays exactly where it was. The object database, refs, stashes and remotes are all shared - a worktree is not a clone, so fetching in one is fetching in all, and creating one is nearly instant. Each worktree gets its own HEAD and index, and git enforces one simple rule: a branch can only be checked out in one worktree at a time.

When are they worth it? Whenever two things need to happen at the same time: a long test run on one branch while you work on another, reviewing a PR without disturbing your half-done work, or - the reason everyone is talking about them these days - AI agents doing their thing in isolation. The price is pretty modest: your working files exist on disk more than once, and anything that isn’t tracked by git (dependencies, build caches, node_modules and friends) has to be set up again in each worktree.

If branches have never felt limiting to you, that’s fine - they didn’t for me either, for over a decade. Worktrees are one of those features you don’t miss until your workflow changes.

What About Jujutsu?

While we’re on the topic of working copies - the most interesting thing happening in version control right now is Jujutsu (jj), a git-compatible VCS that makes the problem worktrees solve mostly go away. In jj the working copy is a commit, snapshotted automatically as you work. There’s no staging area and no stash, because there’s no uncommitted state that could be lost or get in the way - switching contexts is always safe. It also has proper support for parallel working directories (jj workspace), plus an operation log that makes practically everything undoable. That last bit is part of why the AI agent crowd has taken an interest in it too.

You can use jj on top of an existing git repository (they call this a colocated repo), and your colleagues - and Magit - will keep seeing a normal git repo. I’m still just an observer here, but it’s clearly a project to keep an eye on.

Worktrees in Magit

Back to Emacs land. Magit has had worktree support for years, hiding behind Z:

Key	Command	Description
Z b	magit-worktree-checkout	Check out an existing branch in a new worktree
Z c	magit-worktree-branch	Create a new branch and worktree in one go
Z g	magit-worktree-status	Jump to another worktree’s status buffer
Z m	magit-worktree-move	Move a worktree
Z k	magit-worktree-delete	Delete a worktree

The best part is that there’s nothing else to learn. Each worktree gets its own Magit status buffer, and every Magit command operates on the worktree the current buffer belongs to. Z g is the only switching mechanism you need, and even that is just a shortcut for visiting another status buffer.

A few practical tips from my (admittedly recent) experience:

• By default the status buffer doesn’t list your worktrees. Fix that with:

(magit-add-section-hook 'magit-status-sections-hook
                        #'magit-insert-worktrees
                        nil t)

Now every status buffer shows all worktrees of the repo, and you can hit RET on any of them to jump there.

• Create worktrees as siblings of the main checkout with descriptive names (cider-smart-targeting next to cider), not nested inside it - nesting confuses grep, find and plenty of other tools.
• Magit’s branch selection annotates branches that are checked out in another worktree with the worktree’s path, and refuses to check them out a second time (that’s git’s rule, not Magit being difficult). If you ever wondered why a branch “won’t check out”, that’s usually why.
• Each worktree is its own project as far as project.el (or Projectile) is concerned, so project switching, per-project buffers and search all work naturally.
• Anything that’s not tracked by git doesn’t come along for the ride. You’ll have to install dependencies once per worktree and start with a cold build cache. For Elisp that costs you nothing; for a big JVM or JS project it’s the main downside of the whole approach.
• When you’re done with a worktree, delete it with Z k (or with git worktree remove from the command line). If you just delete the directory by hand, git worktree prune will clean up the leftover bookkeeping.

Closing Thoughts

These days my workflow with agents usually looks like this: an agent does its work in a worktree, I review the changes there in Magit (often while another task is running in a second worktree), and the worktree goes away once the branch is merged. Maybe one day I’ll find other uses for worktrees - we’ll see.

Are you using git worktrees - and did you discover them the same roundabout way I did? I’d love to hear about it in the comments!

That’s all I have for you today. Keep hacking (in parallel)!

1. They were introduced in git 2.5, released all the way back in July 2015. ↩

gPTY - a PTY foundation built on Godot and Rust. Provides a tiling grid for panes (terminal, code, file-tree, etc.), a concept capture engine, and a JSON-RPC/MCP control surface so AI agents and automation tools can spawn panes, inject text, and observe output on terminals without scraping a TUI.

Overview

• PTY - Spawn and manage independent shell sessions in a resizable tiling grid. Full DEC STD 070 via alacritty_terminal: 16/256/true color, scrollback with regex search, wrapped text selection.
• Public API - JSON-RPC IPC socket + CLI (gpty new-pane, gpty inject, …) + MCP server. AI agents, scripts, and orchestrators drive the workspace over a documented, versioned protocol.
• Concept engine - RegEx triggers on PTY output capture the reply and route it into adjacent panes (code viewer, Inspector). Write your own or ship the defaults. Concepts capture and display only - they never inject input into a shell.
• Agent observability - Reasoning pane passively projects documented agent lifecycle events (OMP, extensible); Inspector pane runs a private, tool-free Q&A session. Observability only - gpty never orchestrates agent state.
• Persistence - Scrollback, settings, workspaces (named tab sets), and profiles auto-save to SQLite/JSON and restore on restart; full-text search across each pane's persisted history.
• Cross-platform - Standalone binaries for Linux, macOS, and Windows. No Godot or Rust toolchain required to run.
• Documentation - https://godot-pty.github.io/gpty/
• The vast majority of this codebase, including most of the Godot UI layout and the Rust (gpty-core) GDExtension bridge, was generated using LLMs; and as such, the underlying code may contain unidiomatic patterns and/or bugs.

Component Choice Rationale PTY library portable-pty Cross-platform (Linux /dev/ptmx + Windows ConPTY) with a single API ANSI parsing vte crate Fast Rust ANSI state machine Async runtime tokio Per-terminal tasks; channel-driven capture state machine I/O threading Dedicated std::thread per PTY Predictable blocking reads; bridges to tokio via mpsc Concept capture Rust regex over parsed LineParser output Linear-time matching (ReDoS-safe); captures buffer raw bytes for grid-faithful replay Grid rendering alacritty_terminal Full DEC STD 070 grid state machine; pass arrays to Godot _draw() Godot bridge gdext 0.5 Native GDExtension for Godot 4.7+ Rust edition 2024 Requires Rust >= 1.85

---

Installation & Usage

Standalone binaries (no Godot install required) are published on GitHub Releases for Linux, macOS, and Windows.

Platform Package Linux gpty-v0.5.3-linux-x86_64.tar.gz - extract; ./gpty-gui.sh starts the GUI, ./gpty is the CLI macOS gpty-v0.5.3-macos.zip - unzip, right-click the .app → Open; gpty beside it is the CLI Windows gpty-v0.5.3-windows-x86_64.zip - unzip; gpty-gui.exe starts the GUI, gpty.exe is the CLI

Each release publishes a SHA256SUMS listing every asset. Check the file you downloaded before running it:

sha256sum -c SHA256SUMS            # Linux
shasum -a 256 -c SHA256SUMS        # macOS
certutil -hashfile <asset> SHA256  # Windows

Checksums catch a corrupted or tampered download in transit; they are not a signature - release artifacts are unsigned (see SECURITY.md).

CLI

The gpty binary controls a running GUI over JSON-RPC IPC, and every release bundle ships it next to the GUI, which it starts on demand (--no-daemon opts out). Building from source (cargo build -p gpty, or cargo build --workspace) is only needed when working on the CLI itself.

Once the GUI is running (launched from Godot or a release binary), the CLI connects over a Unix socket ($XDG_RUNTIME_DIR/gpty.sock on Linux, or GPTY_SOCKET env var):

# Check if the GUI is running
gpty version

# Print the bundled agent skill (for coding agents running inside a pane)
gpty --skill

# Spawn a new terminal pane
gpty new-pane --pane-type terminal

# List all active panes
gpty list-panes

# Send text to a pane (by label, e.g. T1)
gpty inject T1 --text "echo hello"

# Close a pane
gpty kill-pane T1

# Save and load named layouts
gpty layout save my-setup
gpty layout load my-setup
gpty layout list

# Manage the GUI daemon
gpty daemon status
gpty daemon stop

# Generate AI tool manifests (no GUI needed)
gpty schema
gpty schema --format mcp

# Run as MCP server over stdio (no GUI needed)
echo '{"jsonrpc":"2.0","id":1,"method":"initialize"}' | gpty mcp

See gpty --help for all subcommands and flags.

MCP integration

gpty ships an MCP (Model Context Protocol) server so AI agents and coding harnesses can control the workspace. The repo-root mcp.json declares it for auto-discovery:

{"mcpServers": {"gpty": {"command": "gpty", "args": ["mcp"]}}}

• Direct: run gpty mcp over stdio - exposes a tool per CLI subcommand (new-pane, list-panes, kill-pane, focus-pane, inject, pane-read, pane-status, pane-run, pane-wait, broadcast, layout-*, daemon-*, concept-*, version).
• Manifest: gpty schema --format mcp prints the MCP tool manifest (JSON Schema, works without a running GUI) for hand-off to agent configurations.

Tool schemas are generated from the same clap definitions as the CLI (crates/gpty-cli/src/commands/schema.rs), so they cannot drift from gpty --help.

---

Roadmap

See ROADMAP.md for the full feature inventory.

Security

See SECURITY.md for the threat model, reporting process, and what gpty does not defend against. Implementation rules - the Concept Engine's ReDoS stance, PTY environment sanitization, IPC hardening, OSC 52 restrictions - live in AGENTS.md.

Contributing

See CONTRIBUTING.md for setup instructions, build commands, testing, code style, and the pull request process.

Changelog

See CHANGELOG.md for the complete versioned changes and history.

License

gPTY is free software, licensed under the GNU General Public License, version 3 or later — see LICENSE for the full text.

LICENSE-EXCEPTIONS.md adds two permissions under section 7 of that license, so the ecosystem side stays permissive:

• Plugins, extensions, and adapters are not required to be GPLv3. Anything that works with gPTY over its CLI, JSON-RPC, MCP, or event interfaces — including native pane types — may be licensed under Apache-2.0, MIT, or any other terms you choose, and shipped alongside gPTY without obligation.
• Configuration and data files carry no copyleft. Profiles, workspaces, layouts, concepts, and settings are yours to license however you like; the default *.json files shipped with gPTY are Apache-2.0.

Copyright (C) 2026 Neil Pathare.

gPTY is distributed in the hope that it will be useful, but absolutely without any warranty and assumes no liability for any usage by end-users; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

ResolveHQ is a Cloudflare-native, self-hostable helpdesk for small support teams.

What you can do

• Run a shared inbox with tenant-isolated customers, tickets, assignment, status, priority, tags, and full-text search.
• Sign up as owner, invite teammates, and manage Owner/Admin/Agent roles with a workspace switcher across organizations.
• Thread email correctly per RFC 5322, resistant to subject-line spoofing across tickets.
• Receive mail through Cloudflare Email Routing and send it through Resend, with delivery status, retries, and idempotent webhooks. Outbound replies carry their linked attachments, and dead-letter queues drain to durable, recoverable records.
• Attach files to tickets through validated, authorized R2 uploads.
• Reply faster with saved replies, internal notes, AI-drafted responses (opt-in), and a responsive three-pane inbox with optimistic-version conflict handling.
• Reset passwords and accept invitations through system email sent via the same provider seam as ticket mail.
• Publish a public help center from knowledge-base articles, with drafts kept private to your team.
• Track volume and response speed in Reports, export any window to CSV, and automate triage with rule-based Automations.
• Notify agents of assignments and customer replies in-app, and work comfortably in light or dark mode.
• Export everything stored about a customer as JSON, or erase it with a durable, resumable workflow that cancels queued mail.
• Recover automatically: a five-minute cron job retries stalled mail jobs and cleans up staging and orphaned data.
• Control AI assistance per workspace: it stays off until an admin enables it in Settings, and only then are ticket conversations sent to OpenAI.
• Set TICKET_RETENTION_DAYS (for example 365) to have the scheduled sweep permanently delete resolved and closed tickets older than that window, including attachments.

Interface

The workspace uses a Slack-inspired aubergine sidebar, self-hosted Lato typography, Lucide icons, and Radix UI primitives. Theme-aware controls and status colors support light and dark workspaces. On mobile, bottom navigation and a keyboard-accessible workspace drawer keep all destinations available; ticket columns adapt to preserve subject readability.

Use Cmd/Ctrl+K to jump between pages. The sidebar dock contains notifications, theme switching, and account actions.

How it works

ResolveHQ runs as a single Cloudflare Worker in your own account. Hono serves both the REST API and the built React application. Cloudflare D1 holds tickets and customers, Cloudflare R2 holds attachments, and Cloudflare Queues carry inbound and outbound mail jobs. Cloudflare Email Routing delivers incoming mail to the Worker, and Resend sends outgoing mail. Tickets and attachments are stored in your Cloudflare account; outbound email content passes through Resend.

How much does it cost?

ResolveHQ can run on Cloudflare’s Free plan for small deployments, provided usage stays within the current limits for Workers, D1, R2, Queues, Cron Triggers, and Email Routing. CPU-intensive authentication or mail parsing may require Workers Paid; benchmark your deployment. Queues are available on Workers Free. R2 requires account activation and billing setup separately. Resend handles outbound email under its own limits. See the Free-plan audit.

Deploy

The easiest way to get started is with the Deploy to Cloudflare button above. You will need:

• A Cloudflare account; Workers Free supports Queues. Activate R2 separately.
• A domain on Cloudflare, so you can set up Email Routing.
• Optionally, a Resend account with a verified sending domain, to send outgoing mail.

After deployment, open your ResolveHQ URL and sign up as the owner, giving an optional support email that becomes your default inbox. In the Cloudflare dashboard, add an Email Routing rule sending that address to the deployed Worker, then send a test email to confirm it arrives in the inbox.

See the deployment guide for what the deploy flow provisions, required configuration, first-run setup, and manual deployment.

Local development

npm install
cp .dev.vars.local.example .dev.vars
npm run db:migrate:local
npm run db:seed:local
npm run dev

The Vite application runs on http://localhost:5173 and proxies /api to Wrangler on http://localhost:8787.

Documentation

• Deployment and configuration
• Architecture
• Security

Optional configuration

• AI assistance: set OPENAI_API_KEY (and optionally OPENAI_MODEL, default gpt-4o-mini) as Worker secrets to make AI available. Each workspace still opts in through Settings; without a key the feature stays hidden and no AI calls are made.
• Retention: set TICKET_RETENTION_DAYS as a Worker variable to automatically delete resolved and closed tickets (with attachments) after that many days. Unset means nothing is deleted automatically.

Not yet implemented

• Multi-language interface and notifications outside the app (email digests).

License

See LICENSE.

Accelerate your AI development with Thelio Mira AI, System76's affordable, GPU-focused workstations, built for local AI development — so you can train, fine-tune, and iterate challenging AI workloads entirely on your own hardware.

Configure Thelio Mira with up to:

• 16-core AMD Ryzen 9000 Series CPU
• 192 GB DDR5 RAM
• Dual NVIDIA RTX Pro 6000 GPU
• 192 GB GPU memory

Features:

Sustained top performance

Liquid cooling

Dual NVIDIA RTX Pro 6000 Blackwell GPUs

Quick-access interior

Open source hardware

Manufactured in USA

Master your specs

• Multi-GPU AI Training
• Model Fine-Tuning
• Computer Vision and Image Generation
• Simulations
• Inference

Specifications

Operating System:

Pop!_OS 24.04 LTS with COSMIC Desktop Environment
Ubuntu 24.04 LTS
Ubuntu 26.04 LTS

Processor:

AMD Ryzen 9000 Series

Graphics:

NVIDIA® Graphics or AMD Radeon Pro GPUs

Video Ports:

Integrated graphics: 1 x HDMI 2.1, 1 x DisplayPort 1.4, 1 x USB 10Gbps port (USB Type-C®) supports DisplayPort video output, Other options are dependent on graphics selection. Most include 3 x DisplayPort, 1 x HDMI port.

Memory:

Up to 192 GB Dual Channel DDR5

Storage:

2 x M.2 PCIe Gen5 NVMe, 1 x M.2 PCIe Gen4 NVMe, Up to 2 x 2.5" SATA

Note: The PCIEX16(G4) will be disabled when M.2_3 runs

Front Ports:

1 x USB 3.2 Gen2 (Type-C), 2 x USB 3.2 Gen1 (Type A), 3.5mm combo jack

Rear Ports:

2 x USB 3.2 Gen 2 ports (USB Type-C), 2 x USB 3.2 Gen 2 ports (USB Type-A), 4 x USB 2.0 Ports, 2 x RJ-45 LAN ports, 1 x BIOS FlashBack Button

Rear Audio:

1 x Line In, 1 x Line Out, 1 x Microphone Input

Networking:

2 x 5GbE LAN ports, built-in Wifi 7 (a/b/g/n/ac/ax/be) with Bluetooth 5.4

Power Supply:

750W or 1000W SFX 80+ Gold Certified (1000W + 750W SFX 80+ Gold with Dual 6000 Pro GPU configuration)

Build:

Aluminum, aluminum powder coat, stainless steel (mesh), tempered glass (front), manufactured and assembled in Denver, Colorado

Dimensions:

Height × Width × Depths
17.31" × 9.96" × 15.12" (440mm H × 254mm W × 384mm D)

Model:

thelio-mira-r6-n4

Thelio Mira AI Linux Workstation

Open, customizable, and built for AI

Reliability You Can Train On

Long training runs can't afford silent errors. Thelio Mira AI's ECC GPU memory helps protect your progress.

Alt Text

Own Your Compute, Skip the Fees

Cloud GPU instances add up fast. Train, fine-tune, and iterate locally without recurring cloud fees.

Alt Text

Alt Text

Unleash Your AI Potential on Pop!_OS

Do what you do best — with an open source OS that stays out of your way and maximizes your productivity. Pop!_OS is engineered to keep you innovating with customizable workflows while collecting zero user data.

Discover Pop!_OS

Built-In Security You Can Trust

Protect your data, models, and research with robust security features like encryption on setup — giving you peace of mind when running sensitive or proprietary AI workloads locally.

Alt Text

Crafted with Care in the USA

From schematic to fulfillment, your system is designed from generations of hardware expertise and skillfully handcrafted in Denver, Colorado.

Alt Text

Own Your Machine and Future

Designed for easy access — so you can upgrade and keep your desktop running at its best for years to come.

Alt Text

Resources

Thelio Mira AI one-pager pdf

Why the Mira AI is a must-have machine

Find out why our new AI workstation sets a new standard.

Download One-Pager (PDF)

the blog of system76

Blog: Discover the power of dual GPUs

The new Thelio Mira AI maximizes GPU performance per dollar.

View Blog

Accelerating AI development with Thelio Mira AI

Accelerating AI development

Find out how System76 AI workstations cover the spectrum of AI workloads.

Discover AI Solutions

Thelio Mira AI FAQs

What OS does this run?

System76 computers are optimized for Pop!_OS and Ubuntu. Additionally, you can install a variety of Linux distributions, as well as Microsoft Windows.

Can I swap parts myself?

Yes! Upgrading your Thelio Mira AI is straightforward. We provide lifetime support alongside detailed guides found in the tech specs to help you upgrade components like RAM, storage, and GPUs.

Can I run multiple GPUs for training?

Yes — Thelio Mira AI can be configured with dual PCIe 5.0 x16 slots for x8/x8 multi-GPU support, so you get fast memory transfer between GPUs for large-scale model training.

What if I need help?

Our support team comes highly rated, and for good reason. For the lifetime of your product, you'll have direct access to our in-house experts who are trained in fast, effective solutions.

Why buy from System76?

System76 offers a first-class Linux experience backed by a unique blend of repairability, open source software, customization, and privacy-focused features, plus US-based manufacturing, engineering, and support.

Is this really manufactured in the US?

Yes! We take sheet metal and cut, sand, bend, powder coat, and assemble it all into a full desktop that’s then shipped out the door.

The Logo Programming Language, a dialect of Lisp, was designed as a tool for learning. Its features - interactivity, modularity, extensibility, flexibility of data types - follow from this goal.

Interactivity

Although there are some versions of Logo that compile, it is generally implemented as an interpreted language. The interactivity of this approach provides the user with immediate feedback on individual instructions, thus aiding in the debugging and learning process. Error messages are descriptive. For example

fowad

I don't know how to fowad

(The word fowad is not a primitive - one of Logo's built in words - nor a procedure that you've defined.)

forward

Not enough inputs to forward

(Now that you've spelled it correctly, Logo knows the word forward, but can't run your instruction because forward requires additional information.

forward 100

(Logo is happy. There's no error message. The turtle moves forward 100 steps.)

Modularity and Extensibility

Logo programs are usually collections of small procedures. Generally, procedures are defined by writing them in a text editor. The special word to is followed by the name of the procedure. Subsequent lines form the procedure definition. The word end signals that you're finished.

In our turtle graphics example we defined a procedure to draw a square

to square
repeat 4 [forward 50 right 90]
end

and used it as a subprocedure of another procedure

to flower
repeat 36 [right 10 square]
end

Similarly, flower could be a building block of something larger

to garden
repeat 25 [set-random-position flower]
end

No, set-random-position is not a primitive, but random is and so is setposition (or setpos or setxy). Or you could write set-random-position using forward and right with random.

Once a Logo procedure is defined it works like the Logo primitives. In fact, when you look at Logo programs there's no way of knowing which words are primitives and which are user-defined unless you know that particular Logo implementation. In our language sample we used the procedure pick to randomly select an item from a list, for example in the procedure who.

to who
output pick [Sandy Dale Dana Chris]
end

In some versions of Logo pick is a primitive while in others you have to write it yourself. Who would look and work the same way in either case.

Logo allows you to build up complex projects in small steps. Programming in Logo is done by adding to its vocabulary, teaching it new words in terms of words it already knows. In this way it's similar to the way people learn spoken language.

Flexibility

Logo works with words and lists. A Logo word is a string of characters. A Logo list is an ordered collection of words and or lists. Numbers are words, but they're special because you can do things like arithmetic with them.

Many programming languages are pretty strict about wanting to know exactly what kind of data you claim to be using. This makes things easier for the computer, but harder for the programmer. Before adding a couple of numbers you might have to specify whether they are integers or real numbers. The computer needs to know such things. But most people don't think about this so Logo takes care of it for you. When asked to do arithmetic Logo just does it.

print 3 + 4

7

print 3 / 4

.75

If you are unfamiliar with Logo but work in other programming languages, the following sequence may surprise you:

print word "apple "sauce

applesauce

print word "3 "4

34

print 12 + word "3 "4

46

Here's a recursive procedure that computes factorials:

to factorial :number
if :number = 1 [output 1]
output :number * factorial :number - 1
end

print factorial 3

6

print factorial 5

120

Here's a procedure to reverse a list of words:

to reverse :stuff
ifelse equal? count :stuff 1
[output first :stuff]
[output sentence reverse butfirst :stuff first :stuff]
end

print reverse [apples and pears]

pears and apples

You might also want to take a look at Brian Harvey's interesting Logo sample.

Enhancements

The features just illustrated are common to all versions of Logo. Some Logo implementations include enhanced language features.

There was an object-oriented Logo called Object Logo for the Macintosh.

MicroWorlds Logo includes multi-tasking so that several independent processes may be run simultaneously. The same capability is in the software for Control Lab, a LEGO Logo product. An even more massively parallel Logo is StarLogo.

In a traditional Logo the command to the turtle

repeat 9999 [forward 1 right 1]

would take a while to execute. The instruction

repeat 9999 [forward 1 right 1] print "HELLO

would cause the word HELLO to appear after the turtle was done moving.

In MicroWorlds Logo typing

launch [repeat 9999 [forward 1 right 1]] print "HELLO

would start the turtle going. The word HELLO would appear as soon as the first process is launched. Or

forever [forward 1 right 1] print "HELLO

would initiate a process that would continue until you stopped it. Again, the word HELLO would appear as soon as the turtle process is initiated.

Find Out More

To find out more about the Logo programming language look at Brian Harvey's three-volume epic Computer Science Logo Style and Michael Friendly's Advanced Logo.

If you do not have Logo and want to get started, you might want look at our Logo software page. Or, you can just download UCBLogo, MSWLogo, FMSLogo, StarLogo TNG, or StarLogo Nova right now.

A Hindi translation of this article is available here.

A Ukrainian translation of this article is available here.
A Serbo-Croatian translation of this article is available here

How a Hertfordshire research lab quietly transformed an iconic British staple food, and the complexion of the countryside - without anyone actually noticing

The next time you eat a sandwich, one of those triangular ones you get from a supermarket or Pret, or put some sliced bread into your toaster, pause for a moment and take a close look at the bread. On the surface of it you will see hundreds of little holes - cells, as bakers sometimes call them.

I suspect you’ve never paid them all that much attention. I certainly hadn’t. That was until I discovered that those cells are a clue to one of the most fascinating stories in postwar history. For the little holes in British sliced white bread - not to mention bread in everywhere from South Africa to Australia (though not America or Singapore - as we’ll get to in a moment) are the surface manifestation of an extraordinary shift in the way bread was made.

It is thanks to this shift that, unbeknownst to most of the people consuming it, sliced bread in Britain is actually made in a starkly different way to how bread used to be made for thousands of years. Indeed, by some standards, British bread is a markedly different foodstuff to bread elsewhere; some purists would go so far as arguing that it isn’t actually bread.

But this isn’t just about taste. This is about a little-known revolution in food that, grandiose as this will probably sound, represented one of the most significant industrial strategy interventions in modern British history. This bread revolution changed the entire equation of this country’s food chain, transforming farming throughout the nation in the process. So, yes, this is a very big deal.

But, this being bread - plain, simple sandwich bread - few are even aware of what has become known as the Chorleywood Bread Process. Even fewer know about its backstory, a backstory that begins, you’ve guessed it, in the Trade World.

There are a few straightforward reasons I chose bread as one of the three products whose story we follow in my new book: for one thing, if you understand the origins of bread you start to understand the very beginnings of trade - as grain was traded around the earliest civilisations in the Fertile Crescent in Mesopotamia. You begin to understand the invention of “supply chains” (cities have always been dependent on food supply chains, from ancient Ur and Uruk to modern day London and New York). You realise the extent to which the world around is sometime quite precariously perched on these supply chains.

No wheat; no bread. That equation is etched deep into the historical record. Any time food runs short, or gets too expensive, it precipitates riots. That’s part of the backstory of the French Revolution and the Arab Spring. You could make the case that, in a sense, it’s also part of the backstory for the cost of living crisis the UK and Europe have been suffering for the past few years. Higher energy costs; higher food costs; more discontent.

But the other reason bread is such a fascinating topic comes back to something else. For all that it is invariably treated as a sort of archaic product - the ultimate homespun foodstuff - in fact bread is in many respects the ultimate product of technology and trade (which is sort of what Trade World is all about).

Photo by Sergio Arze on Unsplash

Though the French treat the baguette as a part of their national heritage, in fact it’s a surprisingly modern invention, younger than the Tour Eiffel or the Tour de France. Or consider the Italian ciabatta - that lovely rustic, white bread with big, attractive holes in the crumb. While it is sometimes marketed as the fruit of some ancient Italian tradition, it was actually invented in the early 1980s, making it a little bit younger than me.

More to the point, the ciabatta depends for its production on modern breadmaking techniques, chief among them high-hydration doughs. And in order to pull off high hydration doughs you need “strong” modern flours with very high gluten and protein levels. And for the most part, even in Italy, those flours have to be imported. There is no making ciabattas - or many other types of modern breads - without wheat that often comes from the other side of the world.

That comes back to a pretty fundamental point - a point that will seem slightly arcane to start off with, but has had profound consequences. Not all wheat is alike. Take a train through the English countryside and much of the wheat you see growing in the fields would not typically have qualified to be used in breadmaking. That is because most of the wheat grown in this country lacks the features bakers have historically looked for in good flour.

Chief among those features is protein, or (since it’s more or less the same thing) gluten. Gluten is what helps flour, when mixed with water, salt and either yeast or some sourdough starter, develop that stretchy elastic form. And that elasticity turns out to be the critical thing you’re after when baking nice big lofty loaves, since it traps the carbon dioxide produced by the dough as it ferments. The more protein you have, the bigger the air pockets you can produce in your loaves.

It is moderately easy to grow wheat with 11–12 per cent protein. It is quite hard, in most parts of the world, to ratchet the protein level up to 13 per cent or beyond (though paradoxically the drier the summer, the higher the protein levels, meaning this summer’s wheat harvest is likely to be unusually glutenous). Getting the number up to 14 or 15 per cent takes extraordinary luck or superhuman dedication, but if they want to ensure a good loft in their bread, those are the sorts of numbers bread makers often look for.

British wheat from typically soggy British fields is relatively low protein. But wheat coming from the dry American prairies and places like Manitoba and Saskatchewan in Canada have wonderfully high protein levels. All of which is to say, for as long as Europeans had an appetite for white bread (an appetite which went into overdrive after WWII, when they discovered the wonders of American sliced white bread from GIs stationed across the continent), they have had to import high protein wheat in from elsewhere - much of it from North America.

Back in the early post-war years, roughly 65 per cent of the wheat used for baking in Britain came from Canada, with only about 5 per cent of the local wheat passing muster for domestic bread production. And for the powers-that-be that represented a serious crisis. The country had barely just recovered from two world wars, during which its ability to feed itself was party a function of how much wheat it could ship in from Canada. Surely, the government asked, there was a technological way for Britain to be able to feed itself with its own wheat?

All of which brings us back to Chorleywood, a pretty little village just outside the M25 near London. That was the headquarters of a group called the British Baking Industries Research Association, a part government-funded industry body dedicated to trying to improve British bread. So the association sent out researchers to the mills of Minneapolis and the vast factories where Wonder Bread and Sunbeam were being baked to see how the Americans did it. The American bread making system was what is now known as the “sponge-and-dough” technique. Yeast is used to create a spongy mixture with flour and water that is left to ferment for five hours or so. Then some more flour, water, salt, fat and sugar are added to the fermented sponge to make the final dough, which can finally go in the oven. Voilà: a consistent white loaf that can then be sliced and packed.

But, this being the late 1950s and early 1960s, the age of industrial optimism and the “white heat” of innovation, the bakers at Chorleywood wondered whether maybe they could go one better. What if they could make a bread just as white and just as fluffy as American sliced white bread but even faster? So was born the Chorleywood Bread Process.

The guiding principle of the Chorleywood Bread Process (I’m paraphrasing, of course) is that instead of depending for the most part on fermentation to generate all those bubbles of CO2 that later become the “cell structure” of microscopic holes in a loaf of bread, something similar could be achieved by beating that dough to within an inch of its life in a massive mechanical mixer. This brute force method was, it turns out, phenomenally effective in turning a dough into something that could be baked into bread, far, far quicker than the American method. What once took hours could happen in minutes. The entire process, from start to finish, could happen in about half the time it took to make American white bread. It was, in short, a productivity miracle.

And not just that. An added bonus of the Chorleywood process was that you could also use flours from wheat that had lower protein/gluten content, in other words British wheat. I have a whole section in Trade World about this, including interviews with one of the leading lights in the technologies that made it possible, so I don’t want to repeat it all here, but for our sakes the key thing to focus on here is that the Chorleywood process completely transformed the nature of bread making, milling and, hence, farming in this country. Where once a white bread would have to depend on Canada for the majority of its wheat, you can now make a sliced white loaf with as much as 85 per cent British wheat.

The sorts of mixers used in the Chorleywood process. Photo: Baker Perkins

Today, pretty much all sliced white bread in this country - nearly all the loaves you buy in the supermarket packed in plastic or waxes paper - is made using the Chorleywood Bread Process. It won’t say it on the label, of course. Nor will the label disclose that the bread still needs a certain amount of high protein wheat from 6,000 miles away. But this is nonetheless the hidden backstory of this everyday staple.

If you were looking for an example of an industrial strategy intervention that truly changed Britain’s terms of trade and rejuvenated domestic production (something the latest UK government talks about rather a lot), you could hardly do better than the Chorleywood Bread Process. In the decades after its invention in 1961, British bread became truly, well, British. And not just that. The process, and all the machinery that went alongside it, became an enormous export industry. The gospel of Chorleywood was spread around the world, with the result that gradually other countries adopted the same machines and the same process. As I write in Trade World:

If you go into any supermarket in the world and pick out some sliced white bread, it will most likely have been made either with the American sponge-and-dough system or the Chorleywood bread process. They are the Coke and Pepsi of the industrial bread world. North America? Sponge-and-dough. India? Chorleywood. Singapore? Sponge-and-dough. Shanghai? Chorleywood. Which raises another question: how can you tell the difference?

That brings us back to the “cellular structure” of the bread - those little holes I mentioned at the very start. Look at the holes in your bread and there you have a little clue as to whether it was made with the Chorleywood Bread Process or the American sponge-and-dough process. American industrial sliced bread tends to have round little holes in the surface. The holes in Chorleywood bread are slightly more elongated, slightly more elliptical, a consequence of the fact that the dough has been churned at such an extraordinary speed during its production.

The other difference, some would say, is that sponge-and-dough bread, industrial and bleached as it might look, over-sweetened as it usually is, not to mention doused in extra fats and emulsifiers, is, thanks to those hours of fermentation, at least a closer approximation to bread. That leaves us pondering the awkward question that has been hanging over our conversation. Is Chorleywood bread actually bread?

Either way, it’s an innovation that has changed the complexion of this country, without most people even realising it. The building in Chorleywood where bread changed forever is no longer a research institute for baking; it is now a nursing home. The British Baking Industries Research Association was disbanded after government support dried up some years ago. Britain no longer leads the world in bread research, but we are renowned, for better or worse, for having developed the world’s fastest method for mass-producing bread.

Wheat fields across the UK have become a part of the national bread food chain in a way they never were before. Industrial bread producers are able to produce bread far more cheaply than their predecessors (albeit that those Chorleywood mixers use an awful lot of power). The story of British bread provides some surprisingly rich lessons about economic policy and beyond, both for this country and further afield.