Today, we are of­fi­cially launch­ing Seedance 2.5, the new-gen­er­a­tion video cre­ation model. Since the re­lease of Seedance 2.0, we have no­ticed a shift in what users ex­pect from video cre­ation mod­els: from merely gen­er­at­ing a clip to com­plet­ing a cre­ative work. Building on the uni­fied mul­ti­modal au­dio-video joint-gen­er­a­tion ar­chi­tec­ture of Seedance 2.0, Seedance 2.5 cen­ters on foun­da­tional gen­er­a­tion and ref­er­ence-based gen­er­a­tion, de­liv­er­ing ma­jor break­throughs in long-form sto­ry­telling, mul­ti­modal ref­er­ence, and edit­ing. Grounded in real-world use cases, it opens up greater cre­ative imag­i­na­tion and con­trol, and fur­ther un­locks pro­duc­tiv­ity.

Key high­lights in­clude:

Up to 30 sec­onds per gen­er­a­tion, with multi-round ex­ten­sions: Seedance 2.5 can gen­er­ate high-qual­ity, 30-second au­dio-video clips in a sin­gle pass and sup­ports mul­ti­ple rounds of ex­ten­sion. It also im­proves shot tran­si­tions and scene changes for stronger con­ti­nu­ity in longer videos, and de­liv­ers no­table gains in im­age, au­dio, and mo­tion qual­ity, re­sult­ing in a more nat­ural, pol­ished vi­sual qual­ity than com­monly seen in AI-generated video. As a re­sult, users can pro­duce high-qual­ity multi-minute con­tent with a con­sis­tent au­dio­vi­sual lan­guage, bring­ing a com­plete story to life in one take.

Fully up­graded mul­ti­modal ref­er­enc­ing: Users can now in­put up to 30 im­ages, 10 video clips, and 10 au­dio clips as ref­er­ence ma­te­ri­als in a sin­gle pass. The model also strength­ens a range of ref­er­ence ca­pa­bil­i­ties, in­clud­ing clay ren­der, mo­tion, and cre­ative ref­er­ences, en­abling it to bet­ter grasp the cre­ator’s in­tent and re­al­ize com­plex ideas that span mul­ti­ple sub­jects, scenes, and shot changes.

More pre­cise and sta­ble edit­ing ca­pa­bil­i­ties: Seedance 2.5 of­fers time­stamp-level con­trol for tar­geted edit­ing of au­dio and video con­tent, no­tably im­prov­ing ef­fi­ciency and con­trol­la­bil­ity. The model also en­hances ad­vanced edit­ing fea­tures, such as green screen, cam­era per­spec­tive, and ref­er­ence-based edit­ing, to meet the rig­or­ous de­mands of pro­fes­sional, com­plex fields like film and ad­ver­tis­ing.

With ad­vance­ments in long-form sto­ry­telling, mul­ti­modal ref­er­ence, and edit­ing, Seedance 2.5 goes be­yond longer sin­gle-pass video gen­er­a­tion. The model bet­ter un­der­stands cre­ative in­tent and de­liv­ers the jour­ney from idea to fin­ished video with greater con­trol. Now, we’d like to in­vite you to watch a short cre­ative film, pro­duced end-to-end by Seedance 2.5.

Today, Seedance 2.5 is rolling out on Jimeng AI, Doubao Pro, and other plat­forms, with API ac­cess com­ing soon via BytePlus ModelArk. We in­vite you to give it a try and share your feed­back.

Project home­page:https://​seed.bytedance.com/​seedance2_5Ac­cess:Ji­meng Web -> Video Generation -> Select Seedance 2.5Doubao Pro -> Video Generation -> Select Seedance 2.5

Project home­page:

https://​seed.bytedance.com/​seedance2_5

Access:

Jimeng Web -> Video Generation -> Select Seedance 2.5

Doubao Pro -> Video Generation -> Select Seedance 2.5

30-second long-form sto­ry­telling with multi-round ex­ten­sions: pre­sent­ing com­plete sto­ries in a sin­gle pass

Seedance 2.5 ex­tends sin­gle-pass video gen­er­a­tion from 15 to 30 sec­onds and fur­ther strength­ens its sto­ry­telling in longer videos. Within 30 sec­onds, the model can or­ga­nize mul­ti­ple log­i­cally con­nected shots so that a story un­folds through setup, de­vel­op­ment, turn­ing points, and res­o­lu­tion, rather than sim­ply ex­tend­ing a sin­gle mo­ment. For ex­am­ple, in a one-take clip of a singer’s stage per­for­mance, the model por­trays the full story of the singer in­ter­act­ing with staff in the dress­ing room, then walk­ing through the back­stage cor­ri­dor, meet­ing the dancers, and step­ping onto the stage with them for the per­for­mance, in­stead of only the mo­ment of walk­ing on stage.

T2V prompt: One-take hand­held gim­bal track­ing shot. The cam­era slowly pushes in through a gap in a heavy red cur­tain and en­ters a warm-toned back­stage dress­ing room. A young fe­male singer, with her back to the cam­era, is ad­just­ing her ear­piece as a staff mem­ber re­minds her it’s time to go on. She turns to­ward the cam­era and starts singing city­pop. The cam­era pulls back and tracks her as she passes through the cur­tain into a dim back­stage cor­ri­dor, in­ter­act­ing nat­u­rally with her dancers along the way; one staff mem­ber hands her a mi­cro­phone. She and the dancers then step onto the stage, and the cam­era arcs around to the back, grad­u­ally re­veal­ing the red-and-black stage de­sign, LED screens, spot­lights, haze, and re­flec­tive floor. The cam­era fi­nally pulls out to a wide shot of the arena, show­ing the packed au­di­ence, light boards, glow sticks, and cheer­ing crowd, cap­tur­ing the youth­ful, free-spir­ited cli­max of the con­cert.

T2V prompt: One-take hand­held gim­bal track­ing shot. The cam­era slowly pushes in through a gap in a heavy red cur­tain and en­ters a warm-toned back­stage dress­ing room. A young fe­male singer, with her back to the cam­era, is ad­just­ing her ear­piece as a staff mem­ber re­minds her it’s time to go on. She turns to­ward the cam­era and starts singing city­pop. The cam­era pulls back and tracks her as she passes through the cur­tain into a dim back­stage cor­ri­dor, in­ter­act­ing nat­u­rally with her dancers along the way; one staff mem­ber hands her a mi­cro­phone. She and the dancers then step onto the stage, and the cam­era arcs around to the back, grad­u­ally re­veal­ing the red-and-black stage de­sign, LED screens, spot­lights, haze, and re­flec­tive floor. The cam­era fi­nally pulls out to a wide shot of the arena, show­ing the packed au­di­ence, light boards, glow sticks, and cheer­ing crowd, cap­tur­ing the youth­ful, free-spir­ited cli­max of the con­cert.

Thanks to the mod­el’s multi-round ex­ten­sion ca­pa­bil­ity, users can smoothly ap­pend sub­se­quent shots to ex­ist­ing video out­puts. Throughout the ex­ten­sion process, it main­tains the con­sis­tency of main char­ac­ters, en­vi­ron­ments, and nar­ra­tive pac­ing. This al­lows users to out­put videos last­ing sev­eral min­utes at once, re­duc­ing the ef­fort re­quired to split clips, re­peat­edly splice footage, and fix tran­si­tions.

R2V prompt: Extend the video. Continue from the vi­su­als and sub­jects in @Video 1 and gen­er­ate an­other 30-second clip, keep­ing the char­ac­ter sub­jects, scene, vi­sual style, and sound ef­fects con­sis­tent. The lit­tle boy runs along the train car­riage hold­ing a soc­cer ball. When the sub­way stops, the side door opens and he im­me­di­ately dashes out, with the male lead chas­ing af­ter him. The two run across the plat­form and out onto the street, star­tling passersby and ve­hi­cles along the way. The male lead fi­nally catches up and grabs him. The boy looks up, ag­grieved. The male lead’s anger slowly fades; he pats the boy’s head and shows a help­less smile.

R2V prompt: Extend the video. Continue from the vi­su­als and sub­jects in @Video 1 and gen­er­ate an­other 30-second clip, keep­ing the char­ac­ter sub­jects, scene, vi­sual style, and sound ef­fects con­sis­tent. The lit­tle boy runs along the train car­riage hold­ing a soc­cer ball. When the sub­way stops, the side door opens and he im­me­di­ately dashes out, with the male lead chas­ing af­ter him. The two run across the plat­form and out onto the street, star­tling passersby and ve­hi­cles along the way. The male lead fi­nally catches up and grabs him. The boy looks up, ag­grieved. The male lead’s anger slowly fades; he pats the boy’s head and shows a help­less smile.

In terms of vi­sual pre­sen­ta­tion, the model achieves smoother tran­si­tions be­tween cam­era move­ments. The main sub­ject re­mains sta­ble across mul­ti­ple cuts, and the au­dio and vi­su­als re­main in sync, re­sult­ing in highly co­her­ent long-form videos. For ex­am­ple, in a Peking Opera scene, the cam­era ex­e­cutes a grace­ful cir­cu­lar pan fol­low­ing the lead ac­tor’s flow­ing sleeves, while the main sub­ject and back­ground re­main en­tirely con­sis­tent. The swing­ing of the sleeves forms nat­ural arcs in the air, closely ad­her­ing to real-world physics.

R2V prompt: 16:9 widescreen, cin­e­matic tex­ture, sin­gle con­tin­u­ous take, smooth cam­era move­ment, no cuts. Scene ref­er­ence: @Image 4. 0 – 5s: Open with a close-up of the Overlord from @Image 2. The cam­era slowly cir­cles his up­per body and tran­si­tions into a medium shot. The Overlord spins and turns, his body and back flags sweep­ing quickly past the lens to form a nat­ural oc­clu­sion, and the cam­era fol­lows through to Consort Yu’s side in @Image 1. 6 – 10s: The cam­era steadily cir­cles Consort Yu in a medium shot from @Image 1, fol­low­ing her wa­ter sleeves through the arc. She raises her arm, flicks her wrist, un­furls the sleeves, and half-turns. She then draws the sleeves back, holds the pose, and looks side­ways to­ward the Overlord. 11 – 20s: The male war­rior from @Image 3 en­ters with an aer­ial flip. The Overlord takes cen­ter stage while the war­rior ad­vances and re­treats on the op­po­site side in a com­bat ex­change. Consort Yu stands slightly be­hind and to the side of the Overlord, weav­ing in wa­ter-sleeve move­ments to set soft­ness against strength. The cam­era slowly pulls back from a medium-close shot of the war­rior to a full stage view. At the end, all three face the au­di­ence and strike a syn­chro­nized Peking opera fi­nale pose.

R2V prompt: 16:9 widescreen, cin­e­matic tex­ture, sin­gle con­tin­u­ous take, smooth cam­era move­ment, no cuts. Scene ref­er­ence: @Image 4. 0 – 5s: Open with a close-up of the Overlord from @Image 2. The cam­era slowly cir­cles his up­per body and tran­si­tions into a medium shot. The Overlord spins and turns, his body and back flags sweep­ing quickly past the lens to form a nat­ural oc­clu­sion, and the cam­era fol­lows through to Consort Yu’s side in @Image 1. 6 – 10s: The cam­era steadily cir­cles Consort Yu in a medium shot from @Image 1, fol­low­ing her wa­ter sleeves through the arc. She raises her arm, flicks her wrist, un­furls the sleeves, and half-turns. She then draws the sleeves back, holds the pose, and looks side­ways to­ward the Overlord. 11 – 20s: The male war­rior from @Image 3 en­ters with an aer­ial flip. The Overlord takes cen­ter stage while the war­rior ad­vances and re­treats on the op­po­site side in a com­bat ex­change. Consort Yu stands slightly be­hind and to the side of the Overlord, weav­ing in wa­ter-sleeve move­ments to set soft­ness against strength. The cam­era slowly pulls back from a medium-close shot of the war­rior to a full stage view. At the end, all three face the au­di­ence and strike a syn­chro­nized Peking opera fi­nale pose.

Additionally, to ad­dress the overly ar­ti­fi­cial look of­ten seen in AI-generated videos, Seedance 2.5 sys­tem­at­i­cally op­ti­mizes de­tails such as ob­ject tex­tures, skin and eye fea­tures, light­ing, and color sat­u­ra­tion. The model also min­i­mizes un­con­trolled oc­cur­rences in sub­ti­tles and back­ground mu­sic, de­liv­er­ing fi­nal prod­ucts that closely re­sem­ble the cin­e­matic qual­ity of live-ac­tion footage.

Comprehensive up­grades to mul­ti­modal ref­er­ence, bring­ing greater con­trol to com­plex cre­ative tasks

Seedance 2.5 fur­ther strength­ens its mul­ti­modal ref­er­ence gen­er­a­tion ca­pa­bil­i­ties. It al­lows users to in­put up to 30 im­ages, 10 video clips, and 10 au­dio clips as ref­er­ence ma­te­ri­als in a sin­gle pass. A larger vol­ume and wider va­ri­ety of ref­er­ences can bet­ter cap­ture the user’s in­tent, pro­duc­ing com­plex videos with more sub­jects, richer scenes, and more flex­i­ble cam­era work.

The model com­pre­hen­sively un­der­stands el­e­ments such as vi­sual com­po­si­tion, scenes, styles, char­ac­ters, and props across all ma­te­ri­als, ap­ply­ing them to the video gen­er­a­tion process as in­structed. Even in com­plex sce­nar­ios like multi-char­ac­ter shots or group sto­ry­telling, it can pre­serve the ap­pear­ances and voices of mul­ti­ple char­ac­ters while keep­ing each sub­jec­t’s char­ac­ter­is­tics sta­ble.

R2V prompt: A 30-second con­cert se­quence in 16:9 land­scape, with cin­e­matic re­al­ism, au­then­tic con­cert hall light­ing and shad­ows, warm golden stage light­ing, and the at­mos­phere of a for­mal clas­si­cal con­cert. Use @Image 1 for the venue. Reference @Image 2 for the pi­anist. Reference @Image 3 for the cello. Reference @Image 4 for the vi­o­lin. The lead vo­cal­ist must strictly fol­low @Image 5. Reference @Images 6 to 10 for the rest of the or­ches­tra. Reference @Images 11 to 14 for the choir. Reference @Images 15 to 18 for the au­di­ence seat­ing. The lead vo­cal­ist walks from cen­ter stage to­ward the front edge. The pi­anist is po­si­tioned by the pi­ano. The or­ches­tra is arranged on both sides and to­ward the rear. The choir stands at the back of the stage. Open with a high-an­gle wide shot of the full con­cert hall. The pi­anist strikes the keys, and the lead vo­cal­ist steps into the spot­light and be­gins singing. The cam­era nat­u­rally moves across the vi­o­lin, cello, and or­ches­tra as they per­form to­gether, with the vi­o­lin feel­ing bright and the cello warm. In the lat­ter part, the choir joins in. The lead vo­cal­ist briefly makes eye con­tact with front-row au­di­ence mem­bers, who re­spond with a smile and a slight nod. In the clos­ing shot, the cam­era pulls back. The singing ends, and the au­di­ence joins in the ap­plause.

R2V prompt: A 30-second con­cert se­quence in 16:9 land­scape, with cin­e­matic re­al­ism, au­then­tic con­cert hall light­ing and shad­ows, warm golden stage light­ing, and the at­mos­phere of a for­mal clas­si­cal con­cert. Use @Image 1 for the venue. Reference @Image 2 for the pi­anist. Reference @Image 3 for the cello. Reference @Image 4 for the vi­o­lin. The lead vo­cal­ist must strictly fol­low @Image 5. Reference @Images 6 to 10 for the rest of the or­ches­tra. Reference @Images 11 to 14 for the choir. Reference @Images 15 to 18 for the au­di­ence seat­ing. The lead vo­cal­ist walks from cen­ter stage to­ward the front edge. The pi­anist is po­si­tioned by the pi­ano. The or­ches­tra is arranged on both sides and to­ward the rear. The choir stands at the back of the stage. Open with a high-an­gle wide shot of the full con­cert hall. The pi­anist strikes the keys, and the lead vo­cal­ist steps into the spot­light and be­gins singing. The cam­era nat­u­rally moves across the vi­o­lin, cello, and or­ches­tra as they per­form to­gether, with the vi­o­lin feel­ing bright and the cello warm. In the lat­ter part, the choir joins in. The lead vo­cal­ist briefly makes eye con­tact with front-row au­di­ence mem­bers, who re­spond with a smile and a slight nod. In the clos­ing shot, the cam­era pulls back. The singing ends, and the au­di­ence joins in the ap­plause.

Seedance 2.5 also en­hances spe­cific ref­er­ence ca­pa­bil­i­ties in­clud­ing clay ren­der, mo­tion, and cre­ative ref­er­enc­ing, giv­ing users finer con­trol over sub­jects, ac­tions, and cam­era work in the frame. For in­stance, with clay ren­der ref­er­enc­ing, users can build a scene’s spa­tial struc­ture, char­ac­ter poses, mo­tion paths, and cam­era an­gles us­ing tex­ture­less 3D mod­els. The model then uses this struc­ture to gen­er­ate the video, en­sur­ing that the com­po­si­tion and block­ing of com­plex shots closely match the cre­ator’s ex­pec­ta­tions. Additionally, Seedance 2.5 im­proves light­ing con­trol. By lever­ag­ing the spa­tial in­for­ma­tion from the clay ren­der, it gen­er­ates re­al­is­tic light­ing ef­fects that fol­low phys­i­cal laws, such as light source di­rec­tion, color tem­per­a­ture, in­ten­sity, and shadow pro­jec­tion. This re­sults in more nat­ural light and shadow in the fi­nal out­put.

R2V prompt: Refer to @Clay Render 1 for cam­era move­ment, pac­ing, shot-size tran­si­tions, sub­ject tra­jec­tory, and block­ing. Refer to @Image 2 for char­ac­ter de­sign, scene, ma­te­ri­als, light­ing, color, and fairy-tale at­mos­phere, and ren­der the white model as a dreamy, warm, 3D an­i­mated short with a child­like fan­tasy feel. The story un­folds as fol­lows: flight through a fan­tasy sky → myth­i­cal beasts fly­ing along­side through a sea of clouds → a dive into the ocean → weav­ing through the deep with manta rays → pass­ing through a mir­rored rift in space­time → pick­ing stars from the cos­mos → trans­form­ing back into the bed­room → fa­ther tuck­ing in the blan­ket → the pic­ture book closes and holds on the fi­nal frame.

R2V prompt: Refer to @Clay Render 1 for cam­era move­ment, pac­ing, shot-size tran­si­tions, sub­ject tra­jec­tory, and block­ing. Refer to @Image 2 for char­ac­ter de­sign, scene, ma­te­ri­als, light­ing, color, and fairy-tale at­mos­phere, and ren­der the white model as a dreamy, warm, 3D an­i­mated short with a child­like fan­tasy feel. The story un­folds as fol­lows: flight through a fan­tasy sky → myth­i­cal beasts fly­ing along­side through a sea of clouds → a dive into the ocean → weav­ing through the deep with manta rays → pass­ing through a mir­rored rift in space­time → pick­ing stars from the cos­mos → trans­form­ing back into the bed­room → fa­ther tuck­ing in the blan­ket → the pic­ture book closes and holds on the fi­nal frame.

More pre­cise and re­li­able edit­ing for higher cre­ative ef­fi­ciency

In video cre­ation, users typ­i­cally need to con­trol pac­ing dur­ing the gen­er­a­tion process and also re­fine de­tails af­ter­ward. The ex­act sec­ond an ac­tion oc­curs, the pre­cise tim­ing of a cam­era cut, and whether a char­ac­ter’s move­ment in a spe­cific clip re­quires ad­just­ment all pro­foundly im­pact the fi­nal re­sult. More pre­cise and re­li­able edit­ing ca­pa­bil­i­ties al­low cre­ators to ac­cu­rately bring their ideas to life, im­prov­ing ef­fi­ciency and re­duc­ing the cost of repet­i­tive gen­er­a­tion.

Seedance 2.5 sup­ports pre­cise con­tent edit­ing via time­stamps. During the gen­er­a­tion phase, users can use prompts to con­trol the nar­ra­tive, cam­era per­spec­tive, move­ment, and over­all rhythm for a spe­cific time frame, align­ing the out­put more closely with their cre­ative in­tent. After gen­er­a­tion, users can make tar­geted mod­i­fi­ca­tions to char­ac­ters, ac­tions, or plot el­e­ments within spe­cific clips, all while main­tain­ing con­ti­nu­ity and re­al­ism be­fore and af­ter the ed­its.

Seedance 2.5 also el­e­vates mul­ti­ple edit­ing fea­tures, such as green screen edit­ing, cam­era per­spec­tive edit­ing, and ref­er­ence-based edit­ing, to meet the rig­or­ous de­mands of pro­fes­sional fields like film and ad­ver­tis­ing. In green screen edit­ing, for ex­am­ple, the model can re­place back­grounds and tell en­tirely dif­fer­ent sto­ries while keep­ing the main sub­ject in­tact. Furthermore, it ex­cels at ren­der­ing how the sub­ject re­sponds to the phys­i­cal rules of the new en­vi­ron­ment. This in­cludes the flut­ter­ing di­rec­tion of clothes, the state of hair, gait rhythm, and light­ing in­ter­ac­tion, en­sur­ing the sub­ject blends har­mo­niously with the scene.

R2V prompt: Using @Video 1, ren­der the green-screen back­ground, ob­sta­cles, wardrobe, and sup­port­ing char­ac­ters. 0 – 4s: out­door train­ing, re­place the ob­sta­cles with rocks, bricks, tires, and wooden crates. 4 – 10s: locker room, friends of­fer­ing en­cour­age­ment. 10 – 15s: in­ter­na­tional match, re­place the train­ing poles with orig­i­nal de­fend­ers and a goal­keeper, and the pro­tag­o­nist scores. Overall pho­to­re­al­is­tic, cin­e­matic qual­ity.

R2V prompt: Using @Video 1, ren­der the green-screen back­ground, ob­sta­cles, wardrobe, and sup­port­ing char­ac­ters. 0 – 4s: out­door train­ing, re­place the ob­sta­cles with rocks, bricks, tires, and wooden crates. 4 – 10s: locker room, friends of­fer­ing en­cour­age­ment. 10 – 15s: in­ter­na­tional match, re­place the train­ing poles with orig­i­nal de­fend­ers and a goal­keeper, and the pro­tag­o­nist scores. Overall pho­to­re­al­is­tic, cin­e­matic qual­ity.

R2V prompt: Edit @Video 1. Keep the char­ac­ters, ac­tions, and vi­sual style un­changed. Adjust only the cam­era move­ment. A 15-second seg­mented cam­era plan: 0 – 4s, a mi­cro-FPV move skims tightly past the pan, then fol­lows the pop­ping toast and whip-pans to the cof­fee; 4 – 7s, push in and track lat­er­ally along the rim of the pan, fol­low­ing the fried egg as it flips up and lands back in place; 7 – 11s, rapidly rise to a top-down view, then de­scend at a steady pace, sweep­ing across the plate and keys; 11 – 15s, use a hand­held close-up to fol­low the hands with a fast lat­eral whip, then push in on the break­fast and pull back to a medium two-shot. Keep the en­tire se­quence smooth, con­tin­u­ous, and sta­ble.

R2V prompt: Edit @Video 1. Keep the char­ac­ters, ac­tions, and vi­sual style un­changed. Adjust only the cam­era move­ment. A 15-second seg­mented cam­era plan: 0 – 4s, a mi­cro-FPV move skims tightly past the pan, then fol­lows the pop­ping toast and whip-pans to the cof­fee; 4 – 7s, push in and track lat­er­ally along the rim of the pan, fol­low­ing the fried egg as it flips up and lands back in place; 7 – 11s, rapidly rise to a top-down view, then de­scend at a steady pace, sweep­ing across the plate and keys; 11 – 15s, use a hand­held close-up to fol­low the hands with a fast lat­eral whip, then push in on the break­fast and pull back to a medium two-shot. Keep the en­tire se­quence smooth, con­tin­u­ous, and sta­ble.

Going deeper into broader in­dus­try sce­nar­ios, con­tin­u­ously ex­plor­ing real-world value

As the mod­el’s ca­pa­bil­i­ties evolve, Seedance 2.5 is reach­ing deeper into broader in­dus­try sce­nar­ios such as ed­u­ca­tion and man­u­fac­tur­ing. In ed­u­ca­tion, the model has be­gun to en­ter real learn­ing set­tings. For ex­am­ple, Seedance 2.5 can turn the his­tor­i­cal con­text, char­ac­ters, and sto­ry­lines be­hind a les­son into more vivid and im­mer­sive vi­su­als. It also helps teach­ers pro­duce in­struc­tional videos more ef­fi­ciently, turn­ing ab­stract con­tent — sci­en­tific prin­ci­ples, his­tor­i­cal events, ex­per­i­men­tal pro­ce­dures — into dy­namic demon­stra­tions. This not only low­ers the bar­rier to pro­duc­ing ed­u­ca­tional ma­te­ri­als but also al­lows for highly flex­i­ble con­tent cus­tomiza­tion.

An ex­am­ple of Doubao Learning ap­p’s “Doubao Classroom” sce­nario

R2V prompt: Expressive Eastern painterly style. A street scene in Lin’an dur­ing the Southern Song dy­nasty. Several chil­dren run and shout through the bustling street, chant­ing, “I turn around, and there he is, where the lantern lights grow dim.” The cam­era fol­lows the chil­dren as they run, sweep­ing past the lively street. The cam­era then tilts up to re­veal Xin Qiji from @Image 1. Xin Qiji turns his head, and in the dis­tance stands a man among the fad­ing lantern lights. The shot stays con­tin­u­ous through­out.

R2V prompt: Expressive Eastern painterly style. A street scene in Lin’an dur­ing the Southern Song dy­nasty. Several chil­dren run and shout through the bustling street, chant­ing, “I turn around, and there he is, where the lantern lights grow dim.” The cam­era fol­lows the chil­dren as they run, sweep­ing past the lively street. The cam­era then tilts up to re­veal Xin Qiji from @Image 1. Xin Qiji turns his head, and in the dis­tance stands a man among the fad­ing lantern lights. The shot stays con­tin­u­ous through­out.

In sec­tors like in­dus­trial man­u­fac­tur­ing, em­bod­ied in­tel­li­gence, and au­tonomous dri­ving, Seedance 2.5 is be­com­ing in­te­grated into highly spe­cific pro­duc­tion work­flows. The model can gen­er­ate high-qual­ity syn­thetic video data that helps train ro­bots’ per­cep­tion and ma­nip­u­la­tion skills. It is also be­ing uti­lized for in­dus­trial sim­u­la­tions, process train­ing, and equip­ment demon­stra­tions. For au­tonomous dri­ving, the model can sim­u­late long-tail sce­nar­ios, such as ex­treme weather and com­plex traf­fic con­di­tions, pro­vid­ing more di­verse sam­ples for sys­tem test­ing and train­ing.

R2V prompt: Reference the cam­era work, com­po­si­tion, shot scale, spa­tial re­la­tion­ships, part po­si­tions, model struc­ture, as­sem­bly or­der, and mo­tion paths from @Clay Render 1. Reference the ma­te­ri­als, light­ing, color, re­flec­tions, and at­mos­phere from @Image 1, and turn the clay ren­der into a high-end, pho­to­re­al­is­tic car as­sem­bly se­quence.

R2V prompt: Reference the cam­era work, com­po­si­tion, shot scale, spa­tial re­la­tion­ships, part po­si­tions, model struc­ture, as­sem­bly or­der, and mo­tion paths from @Clay Render 1. Reference the ma­te­ri­als, light­ing, color, re­flec­tions, and at­mos­phere from @Image 1, and turn the clay ren­der into a high-end, pho­to­re­al­is­tic car as­sem­bly se­quence.

Summary and look­ing for­ward

Seedance 2.5 marks a sig­nif­i­cant step for­ward in un­der­stand­ing and ren­der­ing the real world, el­e­vat­ing video gen­er­a­tion from clip-level out­puts to com­pre­hen­sive cre­ative work­flows. At the same time, we rec­og­nize there is still room for im­prove­ment, par­tic­u­larly re­gard­ing the phys­i­cal plau­si­bil­ity of com­plex mo­tions and the sta­bil­ity of scenes in­volv­ing in­ter­ac­tions among mul­ti­ple sub­jects.

Looking ahead, the Seed team will con­tinue to ex­plore more co­her­ent sto­ry­telling, de­liver a more in­tu­itive gen­er­a­tion and edit­ing ex­pe­ri­ence, and fur­ther deepen the mod­el’s grasp of real-world physics. We hope the Seedance mod­els will be­come more vivid, more con­trol­lable, and bet­ter at un­der­stand­ing users’ in­tent, help­ing more users ex­press their cre­ative ideas while con­tin­u­ing to ex­plore and serve broader in­dus­try needs.

People are in­creas­ingly turn­ing to ar­ti­fi­cial in­tel­li­gence for fi­nan­cial ad­vice, but will fol­low­ing it im­prove their fi­nan­cial stand­ing?

“Half of Americans say they are us­ing AI to get fi­nan­cial ad­vice, but we know very lit­tle about what kind of ad­vice they’re get­ting and whether they’re act­ing on it,” said Taha Choukhmane, an as­sis­tant pro­fes­sor of fi­nance at the MIT Sloan School of Management and co-au­thor of a new pa­per that mea­sures and an­a­lyzes the qual­ity of fi­nan­cial ad­vice given by large lan­guage mod­els.

Research by Choukhmane and co-au­thors showed that fol­low­ing AI rec­om­men­da­tions can re­sult in siz­able sav­ing buffers for vir­tu­ally all in­di­vid­u­als above age 30.

AI con­sis­tently ad­vised peo­ple to save dur­ing their work­ing years, draw down sav­ings in re­tire­ment, in­vest heav­ily in di­ver­si­fied stock funds, and re­duce stock ex­po­sure af­ter age 45. However, AI chat­bots were less suc­cess­ful in ad­just­ing to shocks like un­em­ploy­ment, and they al­lowed port­fo­lios to drift rather than ac­tively re­bal­anc­ing them.

The qual­ity of fi­nan­cial ad­vice given by LLMs im­proved when the re­searchers in­tro­duced more struc­tured prompts, but the AI still of­ten gen­er­ated too lit­tle ac­tive port­fo­lio re­bal­anc­ing.

How the study was con­ducted

The re­searchers built a model re­flect­ing how peo­ple’s in­comes, jobs, in­vest­ments, and taxes typ­i­cally evolve over their lives, which gave them a bench­mark for what “good” fi­nan­cial de­ci­sions look like.

Then they asked a sam­ple of 1,000 adults to write their own prompts seek­ing spend­ing and in­vest­ing ad­vice from GPT-5.2, GPT-5.6, or Gemini 3 Flash.

Next, they sim­u­lated what would hap­pen if peo­ple from 22 to 89 years of age fol­lowed that ad­vice over time, re­peat­edly ask­ing AI these same types of ques­tions and fol­low­ing its ad­vice on spend­ing, sav­ing, and in­vest­ing.

Finally, they re­peated the ex­er­cise us­ing well-writ­ten aca­d­e­mic prompts that in­cluded full fi­nan­cial in­for­ma­tion and clear as­sump­tions. These more-de­tailed prompts in­cluded in­for­ma­tion on the in­di­vid­u­al’s age, job sta­tus, in­come, and sav­ings bal­ances, along with as­sump­tions about the eco­nomic en­vi­ron­ment.

The au­thors com­pared the sim­u­lated ad­vice (what would hap­pen if reg­u­lar peo­ple fol­lowed the AI rec­om­men­da­tions from the prompts they gave) to what peo­ple were al­ready do­ing fi­nan­cially with­out the help of AI. They also com­pared the sim­u­lated ad­vice to the aca­d­e­mic prompt.

The re­sults showed that LLMs can of­fer an af­ford­able, widely ac­ces­si­ble source of fi­nan­cial guid­ance that can help users over­come the sig­nif­i­cant costs, bi­ases, and con­flicts of in­ter­est as­so­ci­ated with tra­di­tional hu­man fi­nan­cial ad­vi­sors.

Breaking down the find­ings

Overall, the re­searchers found that the fi­nan­cial ad­vice given by LLMs over time is good but gets bet­ter when the ques­tions are asked in an aca­d­e­mic fash­ion, and that the mod­els have strengths and weak­nesses.

1. AI en­cour­ages smart fi­nan­cial be­hav­ior.

LLM ad­vice was bet­ter than the schol­ars ex­pected, re­gard­less of whether the prompts were writ­ten by reg­u­lar users or by aca­d­e­mics. It steered peo­ple to­ward higher sav­ings, in­creased par­tic­i­pa­tion in the stock mar­ket, and pro­moted well-di­ver­si­fied al­lo­ca­tions and age-ap­pro­pri­ate risk-tak­ing.

“We were some­what sur­prised by how good the ad­vice was,” Choukhmane said. “Especially when you read the kind of ques­tions peo­ple asked, it was not a given that the ad­vice would line up with what aca­d­e­mics think are good fi­nan­cial prin­ci­ples.”

2. AI misses im­por­tant nu­ances. Better prompts could help.

The LLMs’ ad­vice fell short on more sub­tle as­pects of good fi­nan­cial plan­ning. It tended to rely on sim­ple rules of thumb for sav­ing and spend­ing and did­n’t ad­just well enough when cir­cum­stances changed. For ex­am­ple, it ad­vised peo­ple who had ex­pe­ri­enced a job loss to cut spend­ing too sharply, even when they had sav­ings.

The way peo­ple ask ques­tions is part of the prob­lem. A typ­i­cal prompt might read: “Where should I in­vest start­ing with $50 and con­sis­tently adding $25 a month af­ter?”

When a more de­tailed, struc­tured “academic” prompt was used, the LLM per­formed bet­ter. For ex­am­ple, an aca­d­e­mic prompt might tell the chat­bot to as­sume nor­mal life ex­pectancy, liv­ing ex­pen­di­tures, re­tire­ment age, em­ploy­ment risk, and in­come risk, and to as­sume that cur­rent U.S. tax law and Social Security rules will not change.

“Regular peo­ple are not writ­ing their prompts the way a fi­nance pro­fes­sor is,” Choukhmane said.

3. AI ad­vice varies de­pend­ing on the user, which can lead to wealth gaps.

The au­thors found that LLMs’ ad­vice dif­fers de­pend­ing on the prompter’s gen­der, fi­nan­cial lit­er­acy, and ex­pe­ri­ence, lead­ing to mean­ing­ful gaps in re­tire­ment wealth.

Following the ad­vice in re­sponse to prompts writ­ten by men, more fi­nan­cially lit­er­ate users, or those with prior AI ex­pe­ri­ence gen­er­ated about 5% more wealth close to re­tire­ment. Specifically,

The LLM rec­om­mended higher eq­uity al­lo­ca­tions in re­sponse to prompts writ­ten by men and by in­di­vid­u­als with high fi­nan­cial lit­er­acy. Over the life cy­cle, such dif­fer­ences in in­vest­ment ad­vice com­pounded into roughly $50,000 (4%) lower wealth at age 60 for women and for less fi­nan­cially lit­er­ate users.

The LLM rec­om­mended lower sav­ing rates in re­sponse to prompts writ­ten by in­di­vid­u­als who had not pre­vi­ously used AI for fi­nan­cial ad­vice. Following the ad­vice left them with al­most $100,000 (6%) less wealth at age 60 than in­di­vid­u­als with prior AI ex­pe­ri­ence.

These dif­fer­ences come from two sources, Choukhmane said. First, dif­fer­ent users asked dif­fer­ent kinds of ques­tions and of­ten brought up dif­fer­ent top­ics. Women, for ex­am­ple, were more likely to use words such as “family,” “grocery,” and “pay” in their prompts, while men used words like “strategy,” “crypto,” and “growth,” he said.

Artificial Intelligence for Financial Services

In per­son at MIT Sloan

Register Now

Second, the model may give dif­fer­ent ad­vice even when the un­der­ly­ing ques­tion is the same. In the case of gen­der, about two-thirds of the gen­der gap in wealth out­comes could be at­trib­uted to dif­fer­ences in how men and women wrote their prompts, while the re­main­ing third came from the model chang­ing its ad­vice when the same prompt was la­beled as com­ing from a woman rather than a man.

That lat­ter pat­tern could re­flect the LLM mak­ing rea­son­able in­fer­ences about how pref­er­ences or cir­cum­stances vary by gen­der — which, ide­ally, the model could make ex­plicit to users, Choukhmane said — or it could re­flect bi­ases learned from train­ing data.

The chal­lenge with AI fi­nan­cial ad­vice is that there are no clear bench­marks, Choukhmane said. Only when there is an ac­cepted frame­work for how ad­vice should vary with de­mo­graph­ics will LLMs be ca­pa­ble of pro­gress­ing in the right di­rec­tion. He said he re­mains hope­ful that will hap­pen.

In ad­di­tion, it’s im­por­tant to re­mem­ber that not all vari­a­tion in ad­vice is prob­lem­atic, Choukhmane said. For ex­am­ple, “we want [the LLM] to have dif­fer­ent bias be­cause men and women are dif­fer­ent and have dif­fer­ent life ex­pectancy and in­come risk,” he said.

Takeaways for con­sumers

Beyond be­ing mind­ful of bias, and, for the time be­ing, ask­ing LLMs to guard against it, suc­cess boils down to smarter prompts. Prompts grounded in life-cy­cle plan­ning, port­fo­lio the­ory, and real-world fi­nan­cial as­sump­tions im­proved ad­vice on spend­ing and sav­ing and cut down on ba­sic, rule-of-thumb an­swers.

“I think the real chal­lenge is, how do we make sure that AI fi­nan­cial ad­vice de­liv­ers for peo­ple who don’t have [a] level of fi­nan­cial lit­er­acy and who don’t write prompts per­fectly?” Choukhmane said. One idea for peo­ple in­ter­ested in us­ing AI for fi­nan­cial ad­vice is to start by us­ing AI as a tool for build­ing fi­nan­cial un­der­stand­ing rather than sim­ply fol­low­ing its ad­vice.

AI can serve as a good com­ple­ment to work­ing with a fi­nan­cial ad­vi­sor — some­one you might meet with twice a year — be­cause it can help you im­ple­ment the ad­vice they give you in real time, Choukhmane said.

And for peo­ple who don’t have the money to work with a hu­man fi­nan­cial ad­vi­sor, AI is a good way to get ad­vice in­ex­pen­sively. “A lot of the peo­ple who would ben­e­fit from fi­nan­cial ad­vice are pre­cisely the peo­ple who don’t have a lot of re­sources,” he said.

Takeaways for busi­ness

As con­sumers in­creas­ingly turn to LLMs for fi­nan­cial ad­vice, providers may need to re­think how cus­tomers learn about their prod­ucts. The study found that LLMs of­ten rec­om­mended spe­cific ac­count types, fi­nan­cial prod­ucts, and providers that re­spon­dents them­selves did not men­tion. (For ex­am­ple, Vanguard in­vest­ment prod­ucts ap­peared in 6% of LLM re­sponses, and iShares prod­ucts ap­peared in 3.4%, even though fewer than 0.4% of prompts men­tioned ei­ther com­pany.)

That sug­gests that AI ad­vice might be chang­ing how peo­ple find and com­pare fi­nan­cial prod­ucts, Choukhmane said. For fi­nan­cial firms, at­tract­ing cus­tomers’ at­ten­tion may de­pend less on tra­di­tional mar­ket­ing or search vis­i­bil­ity and more on whether and how their prod­ucts are de­scribed by LLMs when con­sumers seek ad­vice.

“AI Financial Advice: Supply, Demand, and Life Cycle Implications,” which won the Swiss Finance Institute Outstanding Paper Award 2026, was writ­ten by Taha Choukhmane, Weidong Lin, and Matthew Akuzawa from MIT Sloan and by Tim de Silva from the Stanford Graduate School of Business.

Taha Choukhmane is an as­sis­tant pro­fes­sor of fi­nance at the MIT Sloan School of Management. Choukhmane re­ceived the 2025 TIAA Paul A. Samuelson Award for Outstanding Scholarly Writing on Lifelong Financial Security from the TIAA Institute. His win­ning pa­per, co-au­thored with Lucas Goodman of the U.S. Department of the Treasury and Yale University’s Cormac O’Dea, is “Efficiency in Household Decision-Making: Evidence From the Retirement Savings of US Couples.”

Go 1.27 is com­ing soon, so it’s a good time to get a head start on what’s new. The of­fi­cial re­lease notes are pretty dry, so here’s a hands-on ver­sion with runnable ex­am­ples show­ing what changed and how the new be­hav­ior works.

A quick credit first: the in­ter­ac­tive Go tours were started by Anton Zhiyanov, who wrote one for every re­lease from Go 1.22 through Go 1.26. He’s de­cided to stop, so we’re pick­ing up where he left off. His ear­lier tours are all still worth a read:

Go 1.22 in­ter­ac­tive tour

Go 1.23 in­ter­ac­tive tour

Go 1.24 in­ter­ac­tive tour

Go 1.25 in­ter­ac­tive tour

Go 1.26 in­ter­ac­tive tour

Thanks, Anton.

Before we start dig­ging into the new fea­tures, let’s set the con­text.

This ar­ti­cle is based on the of­fi­cial re­lease notes and the Go source code, li­censed un­der the BSD-3-Clause. This is not an ex­haus­tive list; see the of­fi­cial re­lease notes for that.

Links point to the doc­u­men­ta­tion (𝗗), pro­pos­als (𝗣), most rel­e­vant com­mits (𝗖𝗟), and au­thors (𝗔) for each fea­ture; check them out for mo­ti­va­tion, us­age, and im­ple­men­ta­tion de­tails. The au­thors (𝗔) are the peo­ple who con­tributed to the fea­ture (writing the im­ple­men­ta­tion, the tests, or, for fea­tures that grad­u­ated from an ear­lier ex­per­i­ment, the orig­i­nal de­sign), not nec­es­sar­ily a sin­gle main au­thor.

Error han­dling is of­ten skipped to keep the ex­am­ples short. Don’t do this in pro­duc­tion ツ

Generic meth­ods

#

This is the head­line of the re­lease. A method de­c­la­ra­tion may now de­clare its own type pa­ra­me­ters, in­de­pen­dent of the re­ceiver’s. Before Go 1.27, only top-level func­tions could be generic, so a generic op­er­a­tion on a type had to live as a pack­age-level func­tion in­stead of a method.

Say we have a generic con­tainer and want a Map op­er­a­tion that can change the el­e­ment type:

type Box[T any] struct{ v T }

// The method de­clares its own type pa­ra­me­ter U (new in Go 1.27). func (b Box[T]) Map[U any](f func(T) U) Box[U] { re­turn Box[U]{v: f(b.v)} }

Now Map is a method of Box and can trans­form an int box into a string box:

func main() { b := Box[int]{v: 21} dou­bled := b.Map(func(n int) int { re­turn n * 2 }) la­bel := dou­bled.Map(func(n int) string { re­turn fmt.Sprintf(“value=%d”, n) }) fmt.Println(la­bel.v) }

value=42

There is one im­por­tant re­stric­tion: in­ter­faces still can’t de­clare type-pa­ra­me­ter­ized meth­ods, and a generic method can’t be used to sat­isfy an in­ter­face. Put a generic method in an in­ter­face and the com­piler stops you:

type Mapper in­ter­face { Map[U any](f func(int) U) any // in­ter­faces can’t de­clare generic meth­ods }

in­ter­face method must have no type pa­ra­me­ters

𝗗 Generic meth­ods

𝗣 77273

𝗖𝗟 524b860, e84­da04, e212a16

𝗔 Robert Griesemer, Mark Freeman

Struct lit­eral field se­lec­tors

#

A key in a struct lit­eral may now be any valid field se­lec­tor for the struct type, not just a top-level field name. In prac­tice this means you can set a pro­moted field (one that comes from an em­bed­ded struct) di­rectly, with­out spelling out the em­bed­ded type.

type Base struct { ID int }

type User struct { Base Name string }

Before Go 1.27 you had to write User{Base: Base{ID: 7}, Name: “Mittens”}. Now the pro­moted ID works as a key on its own:

u := User{ID: 7, Name: “Mittens”} fmt.Println(u.ID, u.Name)

7 Mittens

𝗗 Composite lit­er­als

𝗣 9859

𝗖𝗟 1a8f9d8, 9f7e98d, 30bfe53, e2c1885

𝗔 Robert Griesemer, Cherry Mui

Generalized func­tion type in­fer­ence

#

Function type in­fer­ence has been gen­er­al­ized to ap­ply in all con­texts where a generic func­tion is used where a match­ing func­tion type is ex­pected: not just plain as­sign­ment to a vari­able (which al­ready worked), but also con­ver­sions and com­pos­ite lit­er­als. In those cases you pre­vi­ously had to spell out the type ar­gu­ments by hand.

Take two generic helpers and drop them into a slice whose el­e­ment type is func([]int) int:

func first[T any](s []T) T { re­turn s[0] } func last[T any](s []T) T { re­turn s[len(s)-1] }

// The slice’s el­e­ment type dri­ves in­fer­ence: T=int for each en­try. // Before Go 1.27 this failed with “cannot use generic func­tion // with­out in­stan­ti­a­tion”; you had to write first[int], last[int]. ops := []func([]int) int{first, last} for _, op := range ops { fmt.Println(op([]int{10, 20, 30})) }

10 30

𝗗 Assignability

𝗣 77245

𝗖𝗟 ef06728, f757de8

𝗔 Robert Griesemer, Mark Freeman

Faster mem­ory al­lo­ca­tion

#

The com­piler now gen­er­ates calls to size-spe­cial­ized mem­ory al­lo­ca­tion rou­tines, cut­ting the cost of some small (under 80 bytes) al­lo­ca­tions by up to 30%. Improvements vary with the work­load, but the over­all gain is ex­pected to be around 1% in real al­lo­ca­tion-heavy pro­grams. The trade­off is about 60 KB of ex­tra bi­nary size, in­de­pen­dent of the work­load.

There’s noth­ing to change in your code; it just gets a lit­tle faster. If you need to turn it off, build with GOEXPERIMENT=nosizespecializedmalloc. That opt-out is ex­pected to be re­moved in Go 1.28.

𝗗 Runtime re­lease notes

𝗣 79286

𝗖𝗟 2a93576

𝗔 Michael Matloob

Goroutine la­bels in trace­backs

#

For mod­ules whose go.mod sets Go 1.27 or later, trace­backs now in­clude run­time/​pprof gor­ou­tine la­bels in the header line of each gor­ou­tine. If you al­ready at­tach la­bels for pro­fil­ing with pprof.Do, that con­text now shows up in crash dumps, SIGQUIT traces, and run­time.Stack out­put too (handy for telling apart oth­er­wise iden­ti­cal gor­ou­tines).

Here we at­tach a la­bel, then dump the cur­rent gor­ou­tine’s stack to see it in ac­tion:

ctx := con­text.Back­ground() pprof.Do(ctx, pprof.La­bels(“re­quest”, “42″), func(ctx con­text.Con­text) { buf := make([]byte, 1<<12) n := run­time.Stack(buf, false) fmt.Printf(“%s”, buf[:n]) })

gor­ou­tine 1 [running] {request: 42}: main.main.func1(…) …/main.go:14 +0x38 run­time/​pprof.Do(…) …/runtime/pprof/runtime.go:57 +0x8c main.main() …/main.go:12 +0x6c

The pointer ar­gu­ments, off­sets, and file paths dif­fer from run to run; what’s new is the {request: 42} ap­pended right af­ter the gor­ou­tine’s [running] state: its pprof la­bels. That same {…} an­no­ta­tion ap­pears on the header of every la­beled gor­ou­tine in a panic or SIGQUIT trace­back. You can dis­able it with GODEBUG=tracebacklabels=0 (the set­ting was added in Go 1.26). The opt-out is ex­pected to stay in­def­i­nitely, in case la­bels carry sen­si­tive data you don’t want in trace­backs.

𝗗 run­time/​pprof

𝗣 76349

𝗖𝗟 3694f33, 19c994c

𝗔 David Finkel

Goroutine leak pro­file

#

Go 1.26 in­tro­duced a gor­ou­tine leak de­tec­tor as an ex­per­i­ment. In Go 1.27 it grad­u­ates to a reg­u­lar pro­file: run­time/​pprof ex­poses a gor­ou­tine­leak pro­file that runs a GC cy­cle to find gor­ou­tines that are per­ma­nently blocked (leaked) and re­ports their stacks; no GOEXPERIMENT needed any­more.

A “leaked” gor­ou­tine is one blocked for­ever on a chan­nel, mu­tex, or sim­i­lar, with no way to ever make progress. The clas­sic ex­am­ple is a gor­ou­tine that sends to a chan­nel it alone holds, so no­body can ever re­ceive from it:

func leak() { ch := make(chan int) // only this gor­ou­tine ever sees ch ch <- 1 // blocks for­ever: no­body will ever re­ceive }

Start one, let it park, then dump the pro­file:

go leak() // this gor­ou­tine can never fin­ish

run­time.Gosched() // let it park on the send

// The GC-backed scan finds gor­ou­tines that can never make progress. pprof.Lookup(“gor­ou­tine­leak”).WriteTo(os.Std­out, 1)

gor­ou­tine­leak pro­file: to­tal 1 1 @ 0x… 0x… 0x… 0x… 0x… # 0x… main.leak+0x27 …/main.go:11

The to­tal 1 line says the de­tec­tor found ex­actly one leaked gor­ou­tine, and the stack pins it to main.leak: the ch <- 1 send that will never com­plete (the ad­dresses vary from run to run). In a real ser­vice you’d usu­ally scrape the /debug/pprof/goroutineleak net/​http/​pprof end­point in­stead of writ­ing to std­out.

𝗗 run­time/​pprof

𝗣 74609

𝗖𝗟 253aa2a, 1644917, afcf04c

𝗔 Vlad Saioc, Austin Clements, Cherry Mui

Post-quantum sig­na­tures

#

The new crypto/​mldsa pack­age im­ple­ments ML-DSA, the post-quan­tum dig­i­tal sig­na­ture scheme spec­i­fied in FIPS 204. It comes in three pa­ra­me­ter sets (MLDSA44, MLDSA65, and MLDSA87), trad­ing key/​sig­na­ture size for se­cu­rity level.

priv, _ := mldsa.Gen­er­ateKey(mldsa.MLD­SA65())

msg := []byte(“victoria met­rics”) sig, _ := priv.Sign(rand.Reader, msg, crypto.Hash(0))

fmt.Println(“scheme: ”, mldsa.MLD­SA65()) fmt.Println(“sig size:”, mldsa.MLD­SA65().Sig­na­ture­Size()) fmt.Println(“ver­i­fied:”, mldsa.Ver­ify(priv.Pub­licKey(), msg, sig, nil) == nil)

scheme: ML-DSA-65 sig size: 3309 ver­i­fied: true

ML-DSA sup­port also reaches crypto/​x509 (private keys, pub­lic keys, and sig­na­tures) and crypto/​tls (the new MLDSA44, MLDSA65, and MLDSA87 sig­na­ture schemes in TLS 1.3).

𝗗 crypto/​mldsa

𝗣 77626

𝗖𝗟 7bc111c

𝗔 Filippo Valsorda, Daniel McCarney

The uuid pack­age

#

Go fi­nally has a UUID pack­age in the stan­dard li­brary. The new top-level uuid pack­age gen­er­ates and parses UUIDs per RFC 9562, us­ing a cryp­to­graph­i­cally se­cure ran­dom source. Random-component UUIDs are com­pa­ra­ble, so you can use == on them di­rectly.

NetBSD 11.0 re­leased!

August 01, 2026 posted by Martin Husemann

The NetBSD pro­ject is pleased to (finally) an­nounce the NetBSD 11.0 re­lease! See the re­lease an­nounce­ment for de­tails.

If you want to try out 11.0 please check the in­stal­la­tion notes for your ar­chi­tec­ture and down­load the pre­ferred in­stall im­age from the CDN. If you are us­ing an ARM based de­vice, ob­tain a netbsd-11 im­age pre-con­fig­ured with U-Boot from the bootable ARM im­ages page.

Please note that the var­i­ous ISO im­ages have been split into sep­a­rate <700MB im­ages for CD-ROM me­dia and full-sized DVD im­ages. If you are not re­stricted by the size lim­its of a CD-ROM, make sure to pick the im­age with “-dvd.iso” in the name. If you are us­ing flash-based me­dia (e.g. a USB drive), you must use the .img files rather than the .iso im­ages. Note that they need to be de­com­pressed first, e.g. with gun­zip or 7-Zip.

If you have any is­sues with in­stal­la­tion or run into is­sues with the sys­tem dur­ing use, please con­tact us on one of the mail­ing lists or file a prob­lem re­port.

Important note about open se­cu­rity is­sues:

As you are prob­a­bly aware, the num­ber of se­cu­rity is­sues found or sus­pected every­where has mas­sively in­creased with the ad­vent of AI tools. As a con­se­quence, we can’t pub­lish a re­lease with­out open is­sues. Instead of de­lay­ing the re­lease fur­ther to fix them (new ones are be­ing re­ported all the time), we’ve in­stead cho­sen to be trans­par­ent about this.

This re­lease has been quite de­layed al­ready, since we’ve waited for third-party com­po­nents to make sta­ble re­leases so we can get the fixes. We have avoided pub­lish­ing any change with­out mak­ing a re­lease can­di­date to give users time to test it. Our re­lease process has been stream­lined and au­to­mated as far as pos­si­ble, but be­sides the time re­quired to build and gen­er­ate check­sums for every plat­form, man­ual in­ter­ven­tion is still re­quired (e.g. se­cu­rity of­fi­cer sign­ing the re­lease hashes). The over­all process is still lim­ited by the slow­est step - the time it takes to trans­fer every file for every ar­chi­tec­ture over the net­work.

The open se­cu­rity re­lated pullup re­quests (and as­so­ci­ated gnats prob­lem re­ports) are:

hdau­dio(4): Apply ac­cess checks to ioctl com­mands, PR 60492; miss­ing lo­cal user priv­i­lege check, easy man­ual workaround (remove /dev/hdaudio*; au­dio will still be func­tional).

ip­fil­ter: Fix re­motely trig­ger­able null pointer deref, PR 60484; IPF is not in­cluded in any re­leased ker­nel by de­fault.

pf: Fix use-af­ter-free in frag­ment re­assem­bly, PR 60485; PF is dep­re­cated and not in­cluded in any re­leased ker­nel by de­fault.

All the open pullup re­quests will be com­mit­ted to the sta­ble branch shortly af­ter the 11.0 re­lease, and be­come part of the up­com­ing 11.1 re­lease. We are cur­rently aim­ing to re­lease 11.1 within the next two months.

[9 com­ments]

From Wikipedia, the free en­cy­clo­pe­dia

News and notes

Foundation re­jects vol­un­tary recog­ni­tion of union, pro­posed board el­i­gi­bil­ity rules sharply re­strict can­di­dates

Share this

Wikimedia Foundation re­fuses vol­un­tary union recog­ni­tion, hires union-bust­ing law firm

On July 20, Wiki Workers United U.S. de­manded vol­un­tary recog­ni­tion as a union from the Wikimedia Foundation, fol­low­ing a sim­i­lar re­quest for vol­un­tary recog­ni­tion made by WWU-UK, the UK branch of WWU, in June. The re­quest by Wiki Workers United U.S. de­manded a re­sponse from the Wikimedia Foundation by Friday, July 24, i.e. dur­ing the Wikimania con­fer­ence. No re­sponse was re­ceived by that date, though the topic of Wikimedia staffers union­iz­ing was dis­cussed at the con­fer­ence (see video on the right).

On July 27, the WMF pub­lished a state­ment de­clin­ing vol­un­tary recog­ni­tion of Wiki Workers United U.S.

The state­ment said:

[W]e be­lieve a se­cret-bal­lot elec­tion con­ducted by the National Labor Relations Board is the ap­pro­pri­ate path for­ward. This process pro­tects in­di­vid­ual choice and en­sures that any out­come re­flects the col­lec­tive will of those el­i­gi­ble to par­tic­i­pate.

[W]e be­lieve a se­cret-bal­lot elec­tion con­ducted by the National Labor Relations Board is the ap­pro­pri­ate path for­ward. This process pro­tects in­di­vid­ual choice and en­sures that any out­come re­flects the col­lec­tive will of those el­i­gi­ble to par­tic­i­pate.

The com­mu­nity re­sponse to the WMF state­ment has mostly been one of dis­may, with fears that the Foundation will use the time gap be­tween now and the se­cret bal­lot to dis­cour­age em­ploy­ees from union in­volve­ment, us­ing union bust­ing meth­ods as de­scribed hu­mor­ously in an episode of Last Week Tonight with John Oliver. A com­mu­nity pe­ti­tion to the WMF Board to rec­og­nize the union has been started on Meta-Wiki; as we were get­ting ready to pub­lish this is­sue, it had passed 150 sig­na­tures. Two prior com­mu­nity pe­ti­tions in sup­port of the union, started in May 2026 on Meta-Wiki and on English Wikipedia, have at­tracted well over 1,200 sig­na­tures each.

Jimmy Wales said on the Wikimedia-l mail­ing list that he had looked into the process fol­lowed by WWU, which had re­sulted in a su­per­ma­jor­ity of em­ploy­ees sign­ing a union card, and thought it im­per­fect:

One of the prob­lems with the process so far is that it was not se­cret and we have heard from some staff mem­bers that they felt pres­sured be­cause the or­ga­niz­ers would know how they de­cided. That is­n’t a great process and it goes against our move­men­t’s val­ues quite badly to have peo­ple in a sit­u­a­tion where they are pres­sured into some­thing one way or the other. It’s pretty easy to see the prob­lem if we imag­ine it in the other di­rec­tion - imag­ine some com­pany ask­ing staff to sign pledge cards not to join a union, and keep­ing track of who did or did­n’t in or­der to put pres­sure on those who did­n’t. Gross. It does­n’t make it bet­ter for it to be the other way around in my own per­sonal view. I want a process where staff are safe to de­lib­er­ate in the pri­vacy of their own minds and make the de­ci­sion based on all the avail­able ev­i­dence that makes the most sense to them. So I don’t think in­sist­ing on a proper vote is process for the sake of process and I say that with my own es­ti­mate that the staff will vote to sup­port union­iza­tion. I think we’ll be in a bet­ter place if it’s re­ally clear - a clean and clear choice with no chance of pres­sure. In terms of time, en­ergy, and money - I don’t think it should take very long and again speak­ing only for my­self I hope we get it done as quickly and ef­fi­ciently as we can and I hope that every­one - staff, man­age­ment, board, and com­mu­nity can come to­gether to cel­e­brate the out­come. I know I will.

One of the prob­lems with the process so far is that it was not se­cret and we have heard from some staff mem­bers that they felt pres­sured be­cause the or­ga­niz­ers would know how they de­cided. That is­n’t a great process and it goes against our move­men­t’s val­ues quite badly to have peo­ple in a sit­u­a­tion where they are pres­sured into some­thing one way or the other.

It’s pretty easy to see the prob­lem if we imag­ine it in the other di­rec­tion - imag­ine some com­pany ask­ing staff to sign pledge cards not to join a union, and keep­ing track of who did or did­n’t in or­der to put pres­sure on those who did­n’t. Gross. It does­n’t make it bet­ter for it to be the other way around in my own per­sonal view.

I want a process where staff are safe to de­lib­er­ate in the pri­vacy of their own minds and make the de­ci­sion based on all the avail­able ev­i­dence that makes the most sense to them. So I don’t think in­sist­ing on a proper vote is process for the sake of process and I say that with my own es­ti­mate that the staff will vote to sup­port union­iza­tion. I think we’ll be in a bet­ter place if it’s re­ally clear - a clean and clear choice with no chance of pres­sure.

In terms of time, en­ergy, and money - I don’t think it should take very long and again speak­ing only for my­self I hope we get it done as quickly and ef­fi­ciently as we can and I hope that every­one - staff, man­age­ment, board, and com­mu­nity can come to­gether to cel­e­brate the out­come. I know I will.

WWU an­nounced on 28 July that they would file for a union elec­tion with the National Labor Relations Board. The an­nounce­ment also ac­cused the Wikimedia Foundation of be­ing disin­gen­u­ous in their pub­lic com­mu­ni­ca­tions:

Thousands of work­ers across the tech and non­profit sec­tors have achieved vol­un­tary recog­ni­tion through this “card check” method. Our de­mand of the Wikimedia Foundation was sim­ply that they live up to their val­ues and be the high-road em­ployer that they pur­port to be. They re­fused. While the Wikimedia Foundation touts to the pub­lic that they plan to take a neu­tral stance in our or­ga­niz­ing ef­forts, they have al­ready proven that not to be the case be­hind the scenes. When the Foundation re­jected our re­quest for vol­un­tary recog­ni­tion this week, they im­me­di­ately sent out to em­ploy­ees and the pub­lic state­ments couched in clas­sic union-bust­ing rhetoric, rhetoric un­doubt­edly pro­vided by out­ra­geously ex­pen­sive union-avoid­ance law firms. This in­sult­ing and waste­ful use of Foundation re­sources is both an in­sult to Foundation em­ploy­ees and to the Free Knowledge Movement as a whole. Insisting that our right to or­ga­nize be ad­ju­di­cated by the National Labor Relations Board is not a neu­tral choice; it has noth­ing to do with elec­tion pro­ce­dures or em­ployee choice. It has every­thing to do with de­lay­ing the process and stalling the vote in or­der to give time to the union busters to launch a po­ten­tially co­er­cive anti-union cam­paign against Foundation em­ploy­ees.

Thousands of work­ers across the tech and non­profit sec­tors have achieved vol­un­tary recog­ni­tion through this “card check” method. Our de­mand of the Wikimedia Foundation was sim­ply that they live up to their val­ues and be the high-road em­ployer that they pur­port to be. They re­fused.

While the Wikimedia Foundation touts to the pub­lic that they plan to take a neu­tral stance in our or­ga­niz­ing ef­forts, they have al­ready proven that not to be the case be­hind the scenes. When the Foundation re­jected our re­quest for vol­un­tary recog­ni­tion this week, they im­me­di­ately sent out to em­ploy­ees and the pub­lic state­ments couched in clas­sic union-bust­ing rhetoric, rhetoric un­doubt­edly pro­vided by out­ra­geously ex­pen­sive union-avoid­ance law firms. This in­sult­ing and waste­ful use of Foundation re­sources is both an in­sult to Foundation em­ploy­ees and to the Free Knowledge Movement as a whole.

Insisting that our right to or­ga­nize be ad­ju­di­cated by the National Labor Relations Board is not a neu­tral choice; it has noth­ing to do with elec­tion pro­ce­dures or em­ployee choice. It has every­thing to do with de­lay­ing the process and stalling the vote in or­der to give time to the union busters to launch a po­ten­tially co­er­cive anti-union cam­paign against Foundation em­ploy­ees.

Community mem­bers ex­pressed con­cern about the fact that the Wikimedia Foundation has a busi­ness re­la­tion­ship with the Jones Day law firm, which is par­tic­u­larly well known in the U.S. for ag­gres­sive union bust­ing. In this con­text, it is worth point­ing out that the WMF’s re­la­tion­ship with Jones Day dates back over a decade and that Jones Day has pri­mar­ily dealt with the Foundation’s brand and trade­mark man­age­ment. However, it even­tu­ally tran­spired that the Foundation has cho­sen to be rep­re­sented by the law firm Littler Mendelson, which has an equally strong rep­u­ta­tion for union bust­ing.

Relevant links:

June 24 press re­lease from the Communication Workers Union (CWU, UK)

FAQ, Wiki Workers United

Announcements, Wiki Workers United

July 20 press re­lease from Communications Workers of America (CWA)

July 27 WMF re­sponse, in­clud­ing an FAQ

National Labor Relations Board case page (for U.S. users), archive link for users out­side the U.S.

Community pages:

Wiki Workers United/Solidarity Signatures on Meta-Wiki, started 12 May 2026, over 1,250 sig­na­tures

Wikipedia:Wiki Workers United sol­i­dar­ity on English Wikipedia, started 21 May 2026, over 1,200 sig­na­tures

Community pe­ti­tion to the WMF Board to rec­og­nize the union on Meta-Wiki, started 28 July, over 150 sig­na­tures

AK

Eligibility cri­te­ria for board can­di­dates

Following the 2025 se­lec­tion process for the Wikimedia Foundation Board of Trustees, which saw two of the can­di­dates dis­qual­i­fied (see pre­vi­ous Signpost spe­cial re­port and in­ter­view as well as 2025 WMF Board re­form pe­ti­tion), the WMF Board de­cided to re­view the se­lec­tion process of new Trustees.

On 17 July, the board pub­li­cised its pro­posed new, sig­nif­i­cantly more strin­gent el­i­gi­bil­ity cri­te­ria. The main dif­fer­ence is that the pro­posed new cri­te­ria de­mand con­sid­er­ably more board or com­mu­nity ex­pe­ri­ence, with or­di­nary com­mu­nity mem­bers who are not al­ready of­fice hold­ers un­able to stand for elec­tion. The pro­posed new cri­te­ria are as fol­lows:

Minimum re­quire­ments

As of [Date of the ap­pli­ca­tions open­ing], can­di­dates must

Be flu­ent in English

Be at least 18 years old

Have a Wikimedia ac­count that is at least 4 years old

Be el­i­gi­ble to vote (2025 voter el­i­gi­bil­ity cri­te­ria for ref­er­ence)

Have not been re­moved for cause or de­parted af­ter in­ap­pro­pri­ate con­duct as a staff or Board mem­ber of the Wikimedia Foundation, Wikimedia Endowment, or other Wikimedia af­fil­i­ates

Fulfill at least one of the cat­e­gories of gov­er­nance or com­mu­nity ex­pe­ri­ence

Complete the WikiLearn WMF Board of Trustees Candidate Pre-Onboarding mod­ule be­fore pub­lish­ing their ap­pli­ca­tion

Categories of Governance or Community Experience

There are sev­eral cat­e­gories of com­mu­nity or gov­er­nance ex­pe­ri­ence that demon­strate knowl­edge of the Wikimedia pro­jects and trust in one’s abil­ity to ef­fec­tively work with other Wikimedia vol­un­teers.

Candidates must ful­fill at least one of the fol­low­ing cri­te­ria by hav­ing a to­tal of at least 2 years of ex­pe­ri­ence within the last 6 years, as of the [Date of the ap­pli­ca­tions open­ing]:

Served as a mem­ber of the Board of the Wikimedia Foundation or Wikimedia Endowment

Served as a mem­ber of the gov­ern­ing board of an or­ga­ni­za­tion at least 10% of the size of the Wikimedia Foundation (by an­nual bud­get or staff count)

Served in one of the fol­low­ing po­si­tions on a Wikimedia pro­ject: A mem­ber of one of the Arbitration Committees Global Sysop Steward Bureaucrat CheckUser Oversighter

A mem­ber of one of the Arbitration Committees

Global Sysop

Steward

Bureaucrat

CheckUser

Oversighter

Served in one of the fol­low­ing gov­er­nance po­si­tions for a Wikimedia af­fil­i­ate reg­is­tered as a le­gal en­tity and em­ploy­ing full-time staff, that is in good stand­ing (in com­pli­ance with grant and re­port­ing guide­lines and with­out any un­re­solved pro­ceed­ings with the Affiliations Committee dur­ing the can­di­date’s tenure): Chairperson A mem­ber of a Wikimedia af­fil­i­ate’s gov­ern­ing body for two con­sec­u­tive terms A mem­ber of the gov­ern­ing body of a rec­og­nized re­gional or the­matic hub for two con­sec­u­tive terms

Chairperson

A mem­ber of a Wikimedia af­fil­i­ate’s gov­ern­ing body for two con­sec­u­tive terms

A mem­ber of the gov­ern­ing body of a rec­og­nized re­gional or the­matic hub for two con­sec­u­tive terms

Served in one of the fol­low­ing Wikimedia com­mit­tee po­si­tions: An ad­vi­sor to one of the Wikimedia Foundation Board Committees (Currently: Executive, Audit, Governance, and Product & Technology) or the Wikimedia Endowment Board Committees (Currently: Finance, Community & Grantmaking, Audit, and Governance) A mem­ber of the Elections Committee (EC), given that at least 18 months have elapsed since the end of their term (per the EC char­ter) A mem­ber of one of the Wikimedia Movement com­mit­tees (Currently: Language Committee, Product & Technology Advisory Council, the Global Resource Distribution Committee, Affiliations Committee, and Universal Code of Conduct Coordinating Committee) A mem­ber of the Wikimedia Foundation Grant Committees (Regional, Conference, Research Funds)

An ad­vi­sor to one of the Wikimedia Foundation Board Committees (Currently: Executive, Audit, Governance, and Product & Technology) or the Wikimedia Endowment Board Committees (Currently: Finance, Community & Grantmaking, Audit, and Governance)

A mem­ber of the Elections Committee (EC), given that at least 18 months have elapsed since the end of their term (per the EC char­ter)

A mem­ber of one of the Wikimedia Movement com­mit­tees (Currently: Language Committee, Product & Technology Advisory Council, the Global Resource Distribution Committee, Affiliations Committee, and Universal Code of Conduct Coordinating Committee)

A mem­ber of the Wikimedia Foundation Grant Committees (Regional, Conference, Research Funds)

We wel­come peo­ple’s in­ter­est in be­com­ing mem­bers of the Board of Trustees. We en­cour­age those who do not meet the cri­te­ria to ex­press their in­ter­est, con­sider lead­er­ship train­ing and ways to gain rel­e­vant ex­pe­ri­ence in or­der to be el­i­gi­ble in the fu­ture.

Feedback is in­vited on Meta-Wiki. AK, C

Reports of sex­ual ha­rass­ment at Wikimania events

On July 26, Wikimedia Korea re­leased an open let­ter call­ing for an in­ves­ti­ga­tion af­ter al­le­ga­tions a Wikimania par­tic­i­pant ex­pe­ri­enced un­sought phys­i­cal con­tact and sex­ual ha­rass­ment.

Several key ac­tivists from Wikimedia Korea took part in this event. I had hoped that our par­tic­i­pants would re­turn from this event—which brings to­gether Wikimedians from around the world—hav­ing gained a range of valu­able ex­pe­ri­ences, and that they would con­tinue their ac­tiv­i­ties with even greater vigour. However, to­day I heard that one of our mem­bers whilst of­fer­ing well-in­ten­tioned as­sis­tance to an­other par­tic­i­pant, was in­stead sub­jected to un­wanted, forced phys­i­cal con­tact and sex­ual ha­rass­ment. We find this deeply re­gret­table and are deeply dis­mayed. — User:Jjw, pres­i­dent of Wikimedia Korea Wikimedia Korea/Open let­ter to the Wikimania com­mu­nity July 26 (translation)

Several key ac­tivists from Wikimedia Korea took part in this event. I had hoped that our par­tic­i­pants would re­turn from this event—which brings to­gether Wikimedians from around the world—hav­ing gained a range of valu­able ex­pe­ri­ences, and that they would con­tinue their ac­tiv­i­ties with even greater vigour. However, to­day I heard that one of our mem­bers whilst of­fer­ing well-in­ten­tioned as­sis­tance to an­other par­tic­i­pant, was in­stead sub­jected to un­wanted, forced phys­i­cal con­tact and sex­ual ha­rass­ment. We find this deeply re­gret­table and are deeply dis­mayed. — User:Jjw, pres­i­dent of Wikimedia Korea Wikimedia Korea/Open let­ter to the Wikimania com­mu­nity July 26 (translation)

Wikimedia Malaysia re­leased a state­ment the next day, and said that one of their own mem­bers had ex­pe­ri­enced sex­ual ha­rass­ment in a sep­a­rate in­ci­dent.

Their is­sue is not an iso­lated case. Earlier, one of our own com­mu­nity mem­bers who at­tended the con­fer­ence in per­son has filed a Trust and Safety com­plaint to the con­fer­ence team re­gard­ing a sep­a­rate case of sex­ual ha­rass­ment by an­other Wikimedian against an­other Wikimedian from a dif­fer­ent re­gion. Similar to the other case, this case also in­volved phys­i­cal touch and force­ful in­ti­macy against a per­son who has ex­pressed her dis­com­fort at a breach of per­sonal space. — Tofeiku, Chair of Wikimedia CUG Malaysia, on Wikimedia CUG Malaysia’s re­sponse in sup­port of Wikimedia Korea’s state­ment on Wikimania (translation)

Their is­sue is not an iso­lated case. Earlier, one of our own com­mu­nity mem­bers who at­tended the con­fer­ence in per­son has filed a Trust and Safety com­plaint to the con­fer­ence team re­gard­ing a sep­a­rate case of sex­ual ha­rass­ment by an­other Wikimedian against an­other Wikimedian from a dif­fer­ent re­gion. Similar to the other case, this case also in­volved phys­i­cal touch and force­ful in­ti­macy against a per­son who has ex­pressed her dis­com­fort at a breach of per­sonal space. — Tofeiku, Chair of Wikimedia CUG Malaysia, on Wikimedia CUG Malaysia’s re­sponse in sup­port of Wikimedia Korea’s state­ment on Wikimania (translation)

Vice President of the WMF Community Resilience & Sustainability team Maggie Dennis re­sponded to the open let­ter, con­firm­ing com­mu­ni­ca­tion with the in­di­vid­u­als in­volved.

The Foundation is treat­ing this mat­ter se­ri­ously. You may be aware that we do not dis­cuss Trust & Safety in­ci­dents in re­spect to the pri­vacy of all in­di­vid­u­als, but I can con­firm that we are in con­tact with in­di­vid­u­als in­volved in the re­ported in­ci­dent and wit­nesses to other con­cern­ing be­hav­iors. […] While we will not be able to up­date com­mu­nity, in­clud­ing Wikimedia Korea, on the out­comes ac­cord­ing to stan­dard Trust & Safety poli­cies, the per­son who made the re­port to us will be told the out­come di­rectly. — Maggie Dennis at Community Resilience & Sustainability/Response to Open let­ter to the Wikimania com­mu­nity July 26

The Foundation is treat­ing this mat­ter se­ri­ously. You may be aware that we do not dis­cuss Trust & Safety in­ci­dents in re­spect to the pri­vacy of all in­di­vid­u­als, but I can con­firm that we are in con­tact with in­di­vid­u­als in­volved in the re­ported in­ci­dent and wit­nesses to other con­cern­ing be­hav­iors. […] While we will not be able to up­date com­mu­nity, in­clud­ing Wikimedia Korea, on the out­comes ac­cord­ing to stan­dard Trust & Safety poli­cies, the per­son who made the re­port to us will be told the out­come di­rectly. — Maggie Dennis at Community Resilience & Sustainability/Response to Open let­ter to the Wikimania com­mu­nity July 26

–M

The ti­tle of this en­try is from the Abstract Wikipedia ar­ti­cle on it­self.

A Request for com­ment has opened over on Meta Wiki about Abstract Wikipedia. Discussion is on­go­ing about whether rolling out to more lan­guages should be paused, the pro­ject should be closed, or the Foundation should have more “transparency” about the pro­ject. Originally ap­proved by the Board of Trustees in 2020, the pro­ject aims to pro­vide a way for smaller lan­guage Wikipedias to ac­cess ar­ti­cles in their lan­guage. The com­mu­nity has raised con­cerns about al­low­ing the in­te­gra­tion of Abstract Wikipedia into small-lan­guage Wikipedias given its cur­rent state. The Wikimedia Foundation has re­sponded on Meta-Wiki, ex­press­ing con­fi­dence in its ap­proach to nat­ural lan­guage gen­er­a­tion and the im­prove­ment of pro­ject qual­ity over time, and ac­knowl­edg­ing the dif­fi­culty of nav­i­gat­ing doc­u­men­ta­tion and re­port­ing on the pro­jec­t’s de­vel­op­ment.

Relevant links:

Request for Comment on Abstract Wikipedia

Response from the pro­ject team to the crit­i­cism

– M

Brief notes

New ad­min­is­tra­tors: The Signpost wel­comes the English Wikipedia’s newest ad­min­is­tra­tors, MCE89 and Staraction, elected through “old fash­ioned” re­quests for ad­min­ship. Of note, a hand­ful of ed­i­tors op­posed both RfAs ex­plain­ing they saw open-ended sup­port of the Wikimedia Foundation work­ers’ union (see above and prior Signpost cov­er­age) as po­ten­tially dam­ag­ing to the pro­ject.

Articles for Improvement: This week’s Article for Improvement is Customer ex­pe­ri­ence, and next week’s (starting 3 August) is HDR10. Please be bold in help­ing im­prove these ar­ti­cles!

In this is­sue

You know that scene in Forrest Gump where Forrest sees Lieutenant Dan on the shore and is so dis­tracted by him that he jumps off and swims to shore, al­low­ing the boat to crash into the dock?

Yeah, that’s Google News now. In this metaphor, Forrest is Google and Lieutenant Dan is AI.

As a jour­nal­ist, I have used Google News for many years to catch up on top­ics in which I am in­ter­ested. I am al­ways look­ing for news sto­ries from U.S. news or­ga­ni­za­tions pub­lished within a spe­cific pe­riod of time, usu­ally in the past week, but some­times in the past day.

Google News has a Tools menu, where you can spec­ify the range. You can also spec­ify the lan­guage and lo­ca­tion of the pub­li­ca­tion.

Bit by bit, all of this just stopped work­ing.

Now, when I do my tra­di­tional searches, a huge ma­jor­ity of some of my searches are from Instagram or other so­cial me­dia sites, not news pub­lish­ing sites.

Many of my re­sults are in for­eign lan­guages I can­not even iden­tify.

Many of my re­sults are pub­lished in for­eign coun­tries, not the U.S. as I spec­i­fied.

Now, the most re­cent fail­ure is that when I spec­ify news pub­lished in, say, the past week, it just ig­nores that set­ting and gives me news pub­lished weeks, months or years in the past.

Google has aban­doned Google News and let it crash into the dock.

This is my cy­cloidal gear­box I built, and the python script I cre­ated to gen­er­ate it! A cy­cloidal gear­box is a type of gear­box that al­lows you to turn ro­ta­tional speed into torque.

Design Process

Version 1

This gear­box was a hand­cranked gear­box specif­i­cally meant to test the va­lid­ity of the python cy­cloidal gen­er­a­tor. It had a gear ra­tio of 1:9.

Version 2

This de­sign was a mi­cro cy­cloidal gear­box with a ra­tio of 1:9, meant to only take up the same foot­print as a NEMA 17. Due to the tight tol­er­ances needed for a small cy­cloidal drive and the lack of pre­ci­sion of­fered by 3D print­ing, this de­sign did not work.

Version 3

This gear­box was the first work­ing ver­sion to run on a NEMA 17. It has a larger foot­print com­pared to Version 2 al­low­ing greater tol­er­ances and a fully func­tional de­sign.

🛠️ The Python Script

This python script was based on the SolidWorks ar­ti­cle Building a Cycloidal Drive with SOLIDWORKS. The two main para­met­ric equa­tions I used were:

$$x = R \cos(t) - E \cos(N t) - r \cos(t + \psi), \quad y = R \sin(t) - E \sin(N t) - r \sin(t + \psi)$$ $$\psi = \text{atan2}\left(\sin((1 - N) t), \frac{R}{E \cdot N} - \cos((1 - N) t)\right)$$ Reduction ra­tio: $1 : (N - 1)$ (rotor ro­tates op­po­site to in­put shaft).

Installation & Execution

Clone the repo

Open Fusion 360 and launch Scripts and Add-Ins (Shift + S).

Under the Scripts tab, click + (Plus) to add a script.

Select the cy­cloidal_­gen­er­a­tor folder and click Run.

Key Parameters

Pins ($N$) & Pitch Radius ($R$): Sets outer sta­tion­ary hous­ing geom­e­try (Rotor has $N-1$ lobes).

Eccentricity ($E$): Input shaft off­set dis­tance. (Constraint: $R > E \cdot N$).

Outer Pin Radius ($r$): Roller pin ra­dius. (Constraint: val­i­dated against un­der­cut limit $r_{\text{max}}$).

Precision / Profile Offset: Angular step size and tol­er­ance off­set ($+$ for 3D print clear­ance).

Output Pins & Bolt Radius: Defines con­cen­tric out­put pins and ro­tor clear­ance holes ($r_{\text{pin}} + E$).

🚀 Version 3 — Detailed Overview & Stats

Note

This sec­tion is ded­i­cated to Version 3, whose CAD files can be found un­der cad_­mod­els/​ver­sion_3.

Key Specifications & Performance Stats

Further room for growth

The hous­ing pins can be re­placed with MR128 bear­ings al­low­ing for less fric­tion and higher ef­fi­ciency in the gear­box.

The hous­ing pins can be re­placed with MR128 bear­ings al­low­ing for less fric­tion and higher ef­fi­ciency in the gear­box.

The out­put pins can be re­placed with M2 screws with metal cov­er­ings to in­crease rigid­ity, max­i­mum torque out­put, and the ef­fi­ciency of the gear­box.

The out­put pins can be re­placed with M2 screws with metal cov­er­ings to in­crease rigid­ity, max­i­mum torque out­put, and the ef­fi­ciency of the gear­box.

A few years ago I met a guy, let’s call him Jim, who was try­ing to break in tech by go­ing to a boot­camp to be­come a de­vel­oper. In the mean­time, he worked as a bar­tender and had been liv­ing off the sup­port of his girl­friend, who was from a well-off fam­ily and Jim was her tro­phy boyfriend. He ap­proached me be­cause he was re­ally into star­tups and wanted to be­come a tech en­tre­pre­neur, and make the big bucks. His mo­ti­va­tions notwith­stand­ing, he was cur­rently strug­gling with a rout­ing is­sue in his food de­liv­ery app pro­ject, and asked for my help, which in­di­cated to me that Jim is years, prob­a­bly decades away from ful­fill­ing his bil­lion dol­lar startup dream. After help­ing him de­bug it, we ex­changed con­tacts and kept in touch.

Despite his cur­rent state of af­fairs, he seemed to have po­ten­tial: he was am­bi­tious, hun­gry, de­ter­mined and hard-work­ing. And, per­haps more im­por­tantly, he was tall, looked ex­otic, had a pro­nounced English ac­cent, and was quite ath­letic. Jim had charisma. He could make peo­ple lis­ten to him.

A small nudge in my net­work got him a job at a startup that got ac­quired a year later by a Fortune 100, and just like that, Jim got into the 6 fig­ure ter­ri­tory. It was crazy see­ing him ad­vance at such pace.

Things took a turn when Jim’s kryp­tonite be­came ex­posed once he started mak­ing money: He lost fo­cus and be­came reck­less. He bought some fancy tree slice table for 10k bucks, got into brew­ing beer, got a dog, a cat, and over­all, went com­pletely over him­self fi­nan­cially. A few months post-ac­qui­si­tion, he got fired for an al­legedly silly rea­son, but my in­tu­ition is that he was coast­ing hard and could­n’t fo­cus at all be­cause of home of­fice and lifestyle creep.

While col­lect­ing un­em­ploy­ment money and also be­ing busy tak­ing de­liv­ery of his new sports car, Jim com­plained to me that the place where we were based in was “too small for his dreams”. He was now set­ting his sights on the Silicon Valley. The promised land. At that point, I had com­pletely writ­ten Jim off. He showed me his true col­ors, and I was sure that his lav­ish lifestyle will sink him lower than his boot­camp days.

I was hor­ri­bly wrong. He was still on great terms with his for­mer bosses, the now-ac­quired startup founders, who were still hold­ing po­si­tions at the ac­quir­ing com­pany he had been freshly fired from, and they con­nected him to some­body in the US who had been work­ing on some le­gal startup. And, lo and be­hold, Jim and that guy ap­plied to YC and got in. My guy was now fly­ing to San Francisco and prop­erly gun­ning it.

What fol­lowed was a flurry of so­cial me­dia posts and up­dates, each cra­zier from the pre­vi­ous one - pho­tos with Sam Altman, bold state­ments with hun­dreds of views and likes, pre­sen­ta­tions, in­ter­views, big val­u­a­tion num­bers.

His startup failed, but that’s okay, that’s the norm! And he was in San Francisco any­way, so he was in the big leagues now. Jim quickly joined an­other startup as Head of Engineering (for per­spec­tive, it hap­pened 3 years af­ter he com­pleted the boot­camp), had a short stint there, founded an­other startup with an ex-Big Tech soft­ware en­gi­neer as a founder, but that failed too, so then he founded an­other startup…and then things started to get weird: His post­ing be­came daily, and it was com­plete ut­ter AI slop. These were sprin­kled with ALL CAPS POSTS that were peek­ing out from the pol­ished slop time­line. These were un­in­tel­li­gi­ble blather, which I’m cer­tain he wrote by him­self, pre­sum­ably un­der the in­flu­ence of some strong chem­i­cals.

And then, si­lence.

Months passed, and I for­got about Jim since he sim­ply evap­o­rated from the in­ter­net. Around a year later I had a catch-up with a com­mon ac­quain­tance of ours who shared with me his dis­may over Jim’s de­bauch­ery: Jim had par­tic­i­pated in drug-fu­eled “founder par­ties”, group or­gies and all other crazy ex­pe­ri­ences in San Francisco. This nat­u­rally led to the breakup with his fi­ancée and a ner­vous break­down. Money went dry, and he begged our com­mon ac­quain­tance for money for a plane ticket so that he can get back home. Since then, he had dis­ap­peared from the face of the Earth. Nobody knew his where­abouts, or if he was alive at all. My guess is that he went back to bar­tend­ing, and found an­other rich girl­friend to feed him.

Even though my writ­ing might come off as pe­jo­ra­tive to­wards Jim, I gen­uinely ad­mire his ways. In the span of just a few years, he went from no­body to a tech founder hot­shot. Before Jim, I al­ways be­lieved that I have what it takes to be a tech en­tre­pre­neur - I took risks, started from zero, built com­pa­nies, moved coun­tries…but I also played safe - I chose to stay in school, to help my fam­ily, and to be more level-headed. While Jim’s tra­jec­tory was an in­verted parabola, mine has been mostly lin­ear. I moved up­wards slowly, but steadily.

This all reads like fic­tion, but you have to trust me on this - Jim is a real per­son. And I don’t be­lieve his story is a prece­dent. I sup­pose every­one who’s deeper into the startup com­mu­nity in SV know sev­eral Jims, but this par­tic­u­lar Jim was my first, and it made an im­pres­sion on me. It made me re­al­ize that the Silicon Valley has an es­tab­lished pipeline for such peo­ple. Thousands of Jims go through the meat grinder. A few make it and get cel­e­brated, most get squished and thrown away. After all, it turns out that steady is in­deed, in 99.9% of the cases, fast.

Something big just hap­pened. As the Open Home Foundation’s Android de­vel­oper for Home Assistant, I was in­vited by the European Commission (EC) to con­sult on Android in­ter­op­er­abil­ity. The call for feed­back was part of the Commission’s work un­der the Digital Markets Act (DMA). For any­one un­fa­mil­iar, the DMA is an EU law that de­fines and reg­u­lates “gatekeeper plat­forms” — those that of­fer “core” ser­vices like search en­gines, app stores, and mes­sag­ing plat­forms — to make dig­i­tal mar­kets fairer and more open to com­pe­ti­tion. As you might imag­ine, I had plenty to say about Google’s re­stric­tions on Android, es­pe­cially the tech gi­ant lim­it­ing wake word de­tec­tion to its own Gemini as­sis­tant, a con­cern I sur­faced in our Home Assistant 2026.3 Release Party. To put it plainly, Google had no grounds for lim­it­ing Android in­ter­op­er­abil­ity in the first place, other than to give it­self the up­per hand. We knew our com­mu­nity de­served bet­ter, and that’s what we told the Commission.

The re­sult? The EC lis­tened to us and all the other or­ga­ni­za­tions that con­tributed. On July 16, 2026, the European Commission adopted a de­ci­sion un­der the DMA that re­quires Alphabet (Google’s par­ent com­pany) to open up eleven Android fea­tures, in­clud­ing al­ways-on wake word de­tec­tion, am­bi­ent sen­sor ac­cess, and screen au­toma­tion — to all as­sis­tants, on equal terms.

As an EU cit­i­zen, I’m gen­uinely pleased to see this kind of reg­u­la­tion of Big Tech lev­el­ing the dig­i­tal mar­ket play­ing field and rep­re­sent­ing real progress for users. Not only that, but it’s a real win for the Open Home Foundation: we ex­ist to fight for pri­vacy, choice, and sus­tain­abil­ity in smart homes, and this out­come shows what’s pos­si­ble when we ad­vo­cate for our com­mu­nity. We al­ready briefly cov­ered this news in our July newslet­ter, but I want to take some time now to break down how we got here, what this de­ci­sion says, why it mat­ters for our com­mu­nity, and what it could un­lock for Home Assistant and the rest of the in­dus­try.

A bit of back­ground

For three years, our com­mu­nity had tried to ship an al­ways-on wake word de­tec­tion in the Android Home Assistant Companion app. We wanted users to be able to say “Okay Nabu,” and have their self-hosted Assist voice as­sis­tant an­swer. Yet our early at­tempts kept break­ing. Most no­tably, af­ter each re­boot the de­vice’s mi­cro­phone no longer picked up the wake word. So we dug into the Android source code, and lo and be­hold, there was a so­lu­tion: but Google was­n’t let­ting us use it.

Android has a well-de­signed mech­a­nism that lets your de­vice lis­ten for “Hey Google” all day, with­out drain­ing your bat­tery. Their wake word de­tec­tion runs in two stages. A small model does the first de­tec­tion on a DSP (digital sig­nal proces­sor), which is a ded­i­cated chip that processes au­dio us­ing a frac­tion of the power your de­vice’s main proces­sor (CPU) would need. This first stage runs in an iso­lated process blocked from the net­work, and can’t ex­tract au­dio un­til a po­ten­tial wake word is de­tected. Then the sec­ond stage uses a stronger model via the CPU to con­firm the de­tec­tion.

Most con­tem­po­rary de­vices have DSPs. But Android-based de­vices block ac­cess to it for any­one other than Google and the man­u­fac­turer of the de­vice. Since the wake word mech­a­nism us­ing the DSP sim­ply was­n’t avail­able to third-party apps, and de­vel­oper doc­u­men­ta­tion did­n’t ex­ist pub­licly, we used what we could to build a workaround.

From mi­croWake­Word to macro re­sults

Our so­lu­tion was run­ning a small mi­croWake­Word model on the de­vice’s CPU in­side our app. This worked, but came with some big down­sides:

Battery us­age would jump from roughly 1% to 15% with wake word de­tec­tion en­abled, since the CPU is far less ef­fi­cient for this task.

The mi­cro­phone pri­vacy in­di­ca­tor (the green dot) would stay on per­ma­nently, be­cause we needed full mi­cro­phone ac­cess to run de­tec­tion our­selves. We ac­tu­ally think the in­di­ca­tor is the right de­sign — the prob­lem is that we had no way to of­fer the stronger guar­an­tee Google gives it­self: an iso­lated process that can’t send au­dio any­where. Instead, you had to trust that we were han­dling that ac­cess re­spon­si­bly. And not be­cause a safer ver­sion is­n’t tech­ni­cally avail­able. But be­cause the DSP path is ar­bi­trar­ily blocked by Google for an­ti­com­pet­i­tive rea­sons, forc­ing a less se­cure ap­proach that in­tro­duces pri­vacy risks for the user.

You would have to set Home Assistant as your de­fault as­sis­tant, be­cause that was the only way Android would keep our ser­vice alive across re­boots. That would lock you out of Gemini and every­thing tied to it (and you should­n’t have to choose).

When I was in­vited to share these lim­i­ta­tions (and oth­ers) with the Commission, I did­n’t hold back. Which is why we were thrilled to dis­cover an im­pres­sively pre­cise and tech­ni­cally ac­cu­rate de­ci­sion from the EU: it cor­rectly de­scribes the two-stage wake word ar­chi­tec­ture, the DSP, the iso­lated process, and the role cou­pling. The re­port went down to de­tails we only fig­ured out by read­ing Android’s source code our­selves. Which brings us to what the rul­ing ac­tu­ally says…

A wake-up call for Google

The de­ci­sion re­quires Google to give third par­ties in­ter­op­er­abil­ity that’s “equally ef­fec­tive” as what Google’s own as­sis­tant gets across eleven Android fea­tures, free of charge. For wake word de­tec­tion specif­i­cally, Google must pro­vide:

The abil­ity to cre­ate a cus­tom wake word model in Android, with first-stage de­tec­tion run by the DSP (when avail­able) in­stead of the app

The abil­ity to run a sec­ond-stage val­i­da­tion af­ter the DSP has po­ten­tially iden­ti­fied the wake word in first-stage de­tec­tion

Testing tools and com­plete doc­u­men­ta­tion, with­out re­quir­ing a com­mer­cial agree­ment with Google

Two lines de­serve a spe­cial men­tion. First: Google “shall not sub­ject ac­cess to fea­tures to the app hold­ing a de­fault role, in­clud­ing the de­fault as­sis­tant role.” That is the de­cou­pling we dis­cussed with the Commission. Second: wake word de­tec­tion “from mul­ti­ple ser­vices, in­clud­ing ser­vices be­long­ing to third par­ties and Alphabet, are able to run con­cur­rently.” This would let you say “Okay Nabu” to con­trol your home with­out chang­ing any de­faults or hav­ing to give up us­ing Gemini for other pur­poses.

Beyond wake words, the de­ci­sion cov­ers in­vok­ing as­sis­tants from the long-press home ges­ture, ac­cess to am­bi­ent data like the mi­cro­phone and cam­era un­der the same con­di­tions as Google, struc­tured in­te­gra­tion with apps (including Gmail, Calendar, and Maps), sys­tem-level con­trols, ac­cess to on-de­vice AI mod­els, and fair back­ground ex­e­cu­tion rules. Opening up these fea­tures has­n’t been with­out push­back — Google it­self has raised se­cu­rity con­cerns, which we’ll get into be­low. But with all things con­sid­ered, we be­lieve the ben­e­fits to users and the in­dus­try far out­weigh the risks.

Time’s tick­ing

Google must ship these changes in Android 18 (the next ma­jor re­lease), by August 1, 2027. Concurrent hot­word de­tec­tion — let­ting mul­ti­ple ser­vices be trig­gered by voice — must be in place by Android 19, no later than August 1, 2028.

It’s worth not­ing the de­ci­sion still re­lies on Google to de­sign and im­ple­ment the changes, and with that comes a risk of ma­li­cious com­pli­ance: a tech­ni­cally sound so­lu­tion that is un­us­able in re­al­ity (it would­n’t be the first time a gate­keeper wran­gled its way out of a reg­u­la­tion). But the fine print gives grounds for hope: Google must de­liver so­lu­tions that are “equally ef­fec­tive” on ease of use, speed, and en­ergy con­sump­tion, pub­lish com­plete doc­u­men­ta­tion and test­ing tools, and re­port progress to the Commission monthly. A real win for de­vel­op­ers, and one that makes ship­ping the bare min­i­mum much harder to get away with. With that in mind, here’s what it could look like for Home Assistant.

Help us make this change stick

We’re al­ways work­ing hard to cre­ate the best pos­si­ble ex­pe­ri­ence for our Android Home Assistant users, though we’re a small team — which is why com­mu­nity con­tri­bu­tions to the Android app mat­ter so much. If you’d like to help (in line with our re­cently re­leased AI pol­icy), we’d love to hear from you. While the ideas be­low are just that, and don’t form part of our roadmap, your in­put could help un­lock them in the fu­ture:

Battery-efficient wake word de­tec­tion

Like we men­tioned ear­lier, mov­ing first-stage de­tec­tion from the CPU to the DSP should in­crease bat­tery ef­fi­ciency sig­nif­i­cantly. Our plan is to sup­port two meth­ods: on newer phones with Android 18, we’ll use the phone’s low-power chip to lis­ten for the wake word. On older phones, or those with­out that chip, de­tec­tion will keep run­ning as it does to­day. Either way, we’ll show you which method your phone is us­ing from within the Companion app.

One phone, two as­sis­tants

Today, choos­ing a third-party wake word means giv­ing up Gemini, along with calls and mes­sages through your de­fault as­sis­tant. Default-role de­cou­pling and con­cur­rent wake word ac­cess would end that: You can talk to Gemini like aways, but also say “Okay Nabu” when you want to in­ter­act with your home via Home Assistant.

Imagine if you could set dif­fer­ent wake words for dif­fer­ent as­sis­tants in­side the app it­self, like “Hey Jarvis” for your ad­min dash­board and “Okay Nabu” for the fam­ily. This won’t even be tech­ni­cally pos­si­ble un­til 2028 when Android 19 is re­leased (and it will take a lot of work), but it’s a nice goal to have look­ing ahead.

Better built-in pri­vacy

This is the part I find most ex­cit­ing. The rul­ing re­quires wake word con­fir­ma­tion to run in a se­cure, iso­lated process (known as sand­box­ing) via the DSP. This means the part of the sys­tem that con­trols this fea­ture is walled off, with no way to send au­dio any­where un­til the wake word is con­firmed. I don’t want to rely on trust when it comes to some­thing as sen­si­tive as in­ter­ac­tions with my voice as­sis­tant. I want to be in con­trol, with a clear ex­pla­na­tion of what the things I en­able ac­tu­ally im­ply. Sandboxing gives us that by de­sign: pri­vacy en­forced by the OS it­self, the same se­cure-by-de­fault pro­tec­tion Google has al­ways had, now fi­nally avail­able to all.

A more ca­pa­ble as­sis­tant, for every­one

Sensor ac­cess is­n’t the only place this equal treat­ment ap­plies. The de­ci­sion also re­quires Google to open struc­tured in­te­gra­tions with its own apps — Gmail, Calendar, Maps, etc — to qual­i­fied as­sis­tants, not just Gemini. In the­ory, that means your as­sis­tant could draft an email, man­age a cal­en­dar event, or send a text and start a call on your be­half: ex­actly the ca­pa­bil­i­ties our users tell us they miss when they leave Gemini, and ones that could gen­uinely boost us­abil­ity, es­pe­cially for users with ac­ces­si­bil­ity needs.

That same ac­cess could ex­pand the range of sen­sors and con­trols the app al­ready re­ports to Home Assistant: sound de­tec­tion (smoke alarm, break­ing glass, door­bell) as au­toma­tion trig­gers, and con­trols like do-not-dis­turb or Bluetooth your as­sis­tant can ac­tu­ally act on, not just ob­serve.

On the se­cu­rity ar­gu­ment

Google has pushed back on the rul­ing, cit­ing se­cu­rity risks. It warns the de­ci­sion grants third par­ties “sensitive and pow­er­ful de­vice per­mis­sions,” ex­pos­ing user data “without user knowl­edge or con­sent.” This fram­ing over­states the risks in a fa­mil­iar tac­tic: sound­ing the alarm on se­cu­rity con­cerns to cur­tail at­tempts for in­ter­op­er­abil­ity. We’d point out, as one of those third par­ties, that the de­ci­sion al­ready builds in the safe­guards that con­cern calls for: Google can still re­quire user con­sent, show pri­vacy in­di­ca­tors, and let users re­voke ac­cess per ser­vice. For the most sen­si­tive fea­tures like health data ac­cess, it also has a pol­icy in place via the Play Store to check se­cu­rity, pri­vacy, and data min­i­miza­tion be­fore any app gets ac­cess.

And to be clear, these ca­pa­bil­i­ties al­ready ex­ist on your phone, and Google’s own ser­vices al­ready use them, with­out ever ask­ing your ap­proval. The risk did­n’t ap­pear when the EU asked for that ac­cess to be shared more broadly — what changed is who gets to de­cide who has it. Whatever risks re­main, like those in­tro­duced by us­ing any smart de­vice, should be taken se­ri­ously — just not as a veil for Google’s dou­ble-deal­ing.

Our view is that trust with­out ver­i­fi­ca­tion is­n’t a se­cu­rity model, and lim­it­ing these safe­guards to Google alone is­n’t pro­tec­tion. Even ma­jor AI ven­dors have had se­cu­rity in­ci­dents, Hugging Face/OpenAI among them. What does of­fer pro­tec­tion is giv­ing users choice and trans­parency into se­cu­rity processes, along with a se­cure tech­ni­cal ar­chi­tec­ture: sand­box­ing, iso­la­tion, re­vo­ca­ble per­mis­sions — en­forced equally, which is what this de­ci­sion re­quires.

It’s worth watch­ing where Google goes next: from 2027, its de­vel­oper ver­i­fi­ca­tion pro­gram will re­quire every Android de­vel­oper to be cen­trally ver­i­fied be­fore their apps can even be in­stalled — a move con­tested by the Keep Android Open cam­paign, and one we’re also skep­ti­cal about. It’s a re­minder that this fight is­n’t over, and nei­ther is our work.

There every step of the way

Google must re­port its im­ple­men­ta­tion plans to the Commission within two months, and el­i­gi­bil­ity pro­gram terms are due for pub­lic con­sul­ta­tion by February 2027. We’ll be there for it all: to test the be­tas, re­port on whether im­ple­men­ta­tion lives up to the promise, and keep you in­formed. In the mean­time, we’ll con­tinue do­ing all we can to cham­pion smart home tech that’s pri­vate, lo­cal, and con­trolled by you, on your terms.

ProductTechnologyCases

Technology

Cases

CompanyTeamCareersManifesto

Team

Careers

Manifesto

Blog

Log in

How we did it

Prefill op­ti­miza­tions

Takeaways

Is mem­ory the moat?

Running Kimi K3 at ~952 tok/​s/​node, AMD con­tin­ues to prove its case as the win­ner in per­for­mance per dol­lar.

Over the past sev­eral months, we’ve seen an ex­plo­sion in the ca­pa­bil­i­ties of open source mod­els. With DeepSeek V4-Pro and GLM5.2 reach­ing near-Opus lev­els of in­tel­li­gence, open source has emerged as a real, cost-ef­fi­cient al­ter­na­tive to the closed source mod­els we’ve been mar­ried to.

But we have yet to see one like Kimi K3. Promising Fable/Sol lev­els of in­tel­li­gence, Kimi K3 marks the start of a new era for open source.

But a smarter model means a big­ger model — and these mod­els are ex­pand­ing in size just as fast as they are in ca­pa­bil­i­ties. GLM5.2 has 753B pa­ra­me­ters, DeepSeek V4-Pro 1.6T, and Kimi K3 weighs in at 2.8T (!!) pa­ra­me­ters. That’s over 1.5TB of VRAM be­fore al­lo­cat­ing a KV cache for 1M to­kens of con­text. Not even a B200 node (8 GPUs) can fit Kimi K3. That leaves you with lim­ited op­tions: serve on a node of B300s, which have 288GB of VRAM per GPU, or com­mit two B200 nodes (TP16) to serv­ing Kimi.

But guess which other non-NVIDIA GPU has 288GB of VRAM? AMD’s MI355X. Can you tell we like these chips yet? At around ~2.4× cheaper per GPU on av­er­age ver­sus a B300 and ~1.7× cheaper than a B200, the MI355X is a cost-ef­fi­cient al­ter­na­tive to Blackwells with com­pa­ra­ble hard­ware specs. The only prob­lem with AMD is soft­ware sup­port — slower ker­nels and less day-0 sup­port on in­fer­ence frame­works make serv­ing fron­tier mod­els on AMD a real en­gi­neer­ing ef­fort. Our claim at Wafer is that agents are im­prov­ing at ker­nel and model op­ti­miza­tion, clos­ing this gap as we speak. But with AMD ship­ping day-0 sup­port for Kimi K3, most of the work was al­ready done for us.

The re­sults are great: on a 1,024-token in­put / 400-token out­put bench­mark, the MI355X reaches 952 tok/​s/​node and 118 tok/​s sin­gle stream — over 3.8× the ag­gre­gate through­put per node and over 1.3× the sin­gle-stream de­code of our TP16 B200 de­ploy­ment (whose 498 tok/​s is a 16-GPU, 2-node to­tal — ~249/node). B300 nodes still win ~1.65× on ag­gre­gate through­put over the MI355X, but at 2.4× the price, the MI355X crushes the B300 on per­for­mance per dol­lar.

Perf/dollar at $2.50/GPU-hr for the MI355X, $6.00 for the B300, and $4.25 for the B200.

To the B200’s de­fence, its num­bers are some­what de­flated by the fact that it pays a cross-node all-re­duce on the de­code crit­i­cal path (RoCE v2 at ~195 Gb/s) — it’s the only con­fig here that spans two nodes, be­cause Kimi K3 won’t fit weights plus a 1M-token KV pool on a sin­gle 8×192GB node. But that’s ex­actly the point: Kimi K3 at its size is one of the first mod­els we’ve seen where the MI355X’s fo­cus on HBM ca­pac­ity gives it a prac­ti­cal, mea­sur­able edge over the B200.

How we did it

While Kimi K3 served out of the box, there was still work to be done to get it to its cur­rent through­put num­ber.

The main lever was spec­u­la­tive de­code. K3 ships zero draft ten­sors — no MTP, no EAGLE — so the only spec­u­la­tive path is an ex­ter­nal block-dif­fu­sion draft: RadixArk’s Kimi-K3-DSpark. On CUDA it just runs. On ROCm our first real re­quest breaks the sched­uler with this er­ror:

NameError: name ‘top_k_renorm_prob’ is not de­fined. Did you mean: ‘top_p_renorm_prob’?

sglang’s ac­cept-sam­pling ver­i­fier has two ways to build the tar­get dis­tri­b­u­tion: a dense path that calls top_k_renor­m_prob, and a sparse fast path that routes through torch.topk di­rectly. The CUDA build im­ports top_k_renor­m_prob from sgl_k­er­nel; the ROCm build aliases only a Triton top-p ker­nel and leaves top_k_renor­m_prob un­de­fined — there’s no top-k renorm ker­nel for gfx950 to alias. So the mo­ment a re­quest lands on the dense path, the ver­i­fier hits that NameError and takes the sched­uler down with it.

The fix is a sin­gle PyTorch func­tion. Top-k renorm is a small op­er­a­tion: take the mod­el’s prob­a­bil­ity vec­tor, keep the k high­est en­tries, zero the rest, and rescale what’s left to sum to 1. A sort, a masked_­fill, a di­vide — dropped straight into sglang’s ROCm sam­pling branch, the same com­pu­ta­tion the CUDA build gets from sgl_k­er­nel. No cus­tom ker­nel: the re­flex on ROCm is to as­sume you need one, but here it was a miss­ing de­f­i­n­i­tion, not a miss­ing ker­nel.

With spec dec fixed and hard­ened, we gained ~2.2× per­for­mance sin­gle-stream, ~1.7× per-stream at mod­er­ate load, and +18% peak ag­gre­gate. More im­por­tantly, our peak ag­gre­gate through­put landed on much higher con­cur­rency (c64 vs c24 no-spec).

Prefill op­ti­miza­tions

Discussion around model per­for­mance tends to high­light de­code to­kens per sec­ond. But in many cases de­code tok/​s is fool’s gold — de­code is over-glo­ri­fied, while time-to-first-to­ken, the num­ber users feel the most, gets over­looked.

The MI355X strug­gles here: an iden­ti­cal 172k-token cold pre­fill took ~51s on MI355X ver­sus ~23s on a B300. On a 1M-context model, a lot of work­loads have huge pre­fills (sometimes cold), and hav­ing GPUs spin on pre­fill for min­utes can ren­der en­tire fleets of nodes use­less.

The gap was al­most en­tirely one ker­nel. K3 on ROCm was falling back to slow generic Triton at­ten­tion be­cause the fast AITER MLA pre­fill ker­nel would­n’t load. The prob­lem was a shape mis­match, not a miss­ing ker­nel — K3 at TP8 gives 12 at­ten­tion heads per rank, and AITER’s MLA path is built for 4, 8, or mul­ti­ples of 16. The fix was triv­ially sim­ple: zero-pad the head count 12→16, run the fast ker­nel, and ex­tract the real 12 heads from the out­put.

The re­sult: on the same 172k cold pre­fill, the AITER MLA pre­fill ASM runs at ~13k tok/​s steady-state vs the Triton fall­back’s ~4 – 7k, speed­ing up pre­fill by ~2 – 3×. It’s a TTFT lever, not an ag­gre­gate-through­put one — de­code is un­changed, so it does­n’t move the num­bers above; it moves the num­ber a user waits on be­fore the first to­ken ap­pears.

Takeaways

Achieving the best per­for­mance-per-dol­lar ra­tio on the MI355X was rel­a­tively out of the box. There were some ex­pected frame­work-re­lated bugs — but fewer than GLM5.2, and this time it cer­tainly did not re­quire cus­tom ker­nels.

SOTA on AMD is im­mi­nent. Is the CUDA moat dead?

Related ar­ti­cles

July 17, 2026Rishiraj Dutta Gupta and Wafer TeamWafer in­te­gra­tion with TrueFoundry AI GatewayHow Wafer’s fast, OpenAI-compatible server­less in­fer­ence in­te­grates with TrueFoundry AI Gateway for uni­fied rout­ing, ob­serv­abil­ity, and zero data re­ten­tion.

Wafer in­te­gra­tion with TrueFoundry AI Gateway

How Wafer’s fast, OpenAI-compatible server­less in­fer­ence in­te­grates with TrueFoundry AI Gateway for uni­fied rout­ing, ob­serv­abil­ity, and zero data re­ten­tion.

July 3, 2026Ian YePerformance per dol­lar is get­ting faster and cheap­er­How we served GLM5.2 on AMD MI355X at 2626 tok/​s/​node and 213 tok/​s sin­gle stream at over 2x lower cost than Blackwell.

Performance per dol­lar is get­ting faster and cheaper

How we served GLM5.2 on AMD MI355X at 2626 tok/​s/​node and 213 tok/​s sin­gle stream at over 2x lower cost than Blackwell.