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.

July 31, 2026, 4:52pm

1

I just no­ticed Cursor Usage win­dow switched from $$ to Token amount. I use this Usage win­dow closely to keep tabs on my daily/​ac­tive spend­ing, not from the spend­ing over­all page. Today, the $$ amount is re­placed by to­ken amount which is com­pletely use­less. Any way to re­vert back to $$ amount as I can’t seem to find this in set­tings or else­where. Is it just me, or does Cursor feel like it’s more buggy than be­fore, ie. auto se­lect sub agents de­spite hav­ing the de­fault sub­agent setup.

Kaleb_Maul

(Kaleb Maul)

July 31, 2026, 4:59pm

4

I am also miss­ing the $$ on the us­age page. I don’t un­der­stand why things are be­ing moved around ran­domly, and now I can’t ac­cess my us­age data any­more. I could­n’t find any dev an­nounce­ments about this from to­day but will keep search­ing. Hopefully they will fix this is­sue or tell us where this data has been moved to.

eli.wavv

(Eli Smith)

July 31, 2026, 5:27pm

6

Cursor needs to be trans­par­ent about the per-re­quest cost if that is what we are be­ing billed for(with on-de­mand us­age). This is un­ac­cept­able and makes it im­pos­si­ble for team mem­bers to track their own per­sonal us­age when work­ing on a team with a shared on-de­mand us­age cap.

Kris_Gunnars

(Kris Gunnars)

July 31, 2026, 7:11pm

7

I’m also see­ing this. The dol­lar break­down is sud­denly GONE from the us­age page. Cursor, please fix this im­me­di­ately.

kevinn

(Kevin Neilson)

July 31, 2026, 7:23pm

9

Thanks for flag­ging this. There is­n’t cur­rently a set­ting to switch back to dol­lar amounts for in­di­vid­ual plans. Enterprise Plans will still show dol­lar amounts here, but in­di­vid­ual plans will not. This is de­lib­er­ate de­sign be­cause of the dif­fer­ences in how en­ter­prise plans are struc­tured (pooled us­age) vs. in­di­vid­ual plans with in­cluded us­age. We did briefly dis­play dol­lar amounts for in­di­vid­ual plans, but that led to some con­fu­sion be­cause the dol­lar amounts dis­played were of­ten higher amounts than the user’s plan cost (due to the gen­er­ous in­cluded us­age of the Cursor in­di­vid­ual plans).

Ultra runs on us­age-based (token) pric­ing. On that model, any­thing cov­ered by your plan shows to­ken counts and is marked “Included” be­cause noth­ing is charged for it. Usage you ac­tu­ally pay for, mean­ing on-de­mand be­yond your in­cluded amount, still shows a dol­lar fig­ure in the Cost col­umn. That split is the in­tended de­sign.

Where to find the dol­lars:

Dashboard > Spending shows an On-Demand Spending fig­ure for your cur­rent cy­cle. That is the num­ber match­ing what you will be billed.

Dashboard > Usage, set your date range, then Export CSV. The Cost col­umn has dol­lar amounts for every on-de­mand row. If it’s part of your in­cluded us­age of your plan, it won’t show a dol­lar amount but rather the word “Included”.

kevinn

(Kevin Neilson)

July 31, 2026, 7:28pm

10

One fol­low up here: You’re prob­a­bly re­fer­ring to the ex­plore sub­agent model choice, which is one type of sub­agent. Agents can spin up other types of sub­agents with dif­fer­ent model choices, here’s more info on that: Sub agents trig­gers even when dis­abled and uses Opus for no rea­son - #5 by kevinn

Axel_Trange

(Axel Trange)

July 31, 2026, 7:30pm

11

I know count­less of Cursor users who used this Spending Graph fea­ture dozens of times a day to keep track of their bud­get. Now you’re com­pletely hid­ing the cost. Who cares about to­kens? It’s ir­rel­e­vant as it’s highly dif­fer­ent to each model. Please don’t tell me and my team we have to write a cus­tom script to break down the bud­get from your .csv be­cause you fa­vor ob­scu­rity

Kris_Gunnars

(Kris Gunnars)

July 31, 2026, 7:31pm

13

Hey Kevin, I’m on the Teams plan and I have mul­ti­ple em­ploy­ees on the plan with a com­bined us­age cost of 30K USD in the cur­rent billing cy­cle. Almost all of our spend is based on API pric­ing. How can I track the per-user and per-model spend like be­fore???

Axel_Trange

(Axel Trange)

July 31, 2026, 7:42pm

15

Suggestion: Just in­clude a tog­gle or drop­down but­ton to en­able this. You can de­fault to “Tokens” if you pre­fer. But at least give the op­tion to show the old $$ graph that so many users are ac­cus­tomed to

kevinn

(Kevin Neilson)

July 31, 2026, 7:48pm

16

To shed a lit­tle more light on this change, a change shipped to­day made the Usage page to­kens-only for self-serve plans, in­clud­ing Teams. The Spend met­ric and Cost col­umn were re­moved, and the Usage CSV no longer con­tains dol­lar costs.

@Kris_Gunnars As a Teams ad­min, you can still use Dashboard > Members > On-Demand for per-user on-de­mand to­tals. However, there is cur­rently no per-model dol­lar break­down for self-serve Teams and in­di­vid­ual plans.

Kris_Gunnars

(Kris Gunnars)

July 31, 2026, 7:52pm

17

I hope you will re­vert this change be­cause I think it is a ter­ri­ble prod­uct de­ci­sion. I liked hav­ing the per-day, per-model and per-re­quest break­down and I looked at this screen sev­eral times per day. Now it’s just gone for no good rea­son. Just see­ing each user’s to­tal is not even re­motely as use­ful to me.

JPPIX4D

July 31, 2026, 7:35pm

18

Until to­day, https://​cur­sor.com/​api/​dash­board/​get-fil­tered-us­age-events re­turned per-re­quest cost fields (chargedCents, us­age­Based­Costs, to­kenUsage.to­tal­Cents). As of 2026 – 07-31 these are ze­roed out (chargedCents: 0, us­age­Based­Costs: “$0.00”, to­tal­Cents omit­ted) — for all events, in­clud­ing his­tor­i­cal ones that pre­vi­ously showed real val­ues, and in­clud­ing on-de­mand us­age I am ac­tu­ally billed for.

I’m on a Teams plan with us­age-based pric­ing en­abled. I need per-re­quest costs to eval­u­ate model ef­fi­ciency and con­trol spend. The pe­riod to­tals still ex­ist, so the data is clearly still tracked in­ter­nally.

Please re­store per-re­quest cost fields in the API (and the dash­board cost col­umn). Transparency about what I’m be­ing charged per re­quest is not op­tional for a me­tered prod­uct — re­mov­ing it retroac­tively breaks any in­de­pen­dent cost track­ing.

kevinn

(Kevin Neilson)

July 31, 2026, 8:44pm

19

Hi @JPPIX4D Thank you for the post. I un­der­stand the frus­tra­tion, es­pe­cially since you built re­port­ing around these fields, and the change also af­fects his­tor­i­cal re­sults.

This was an in­ten­tional change, not a tem­po­rary re­port­ing is­sue. Usage re­port­ing for self-serve plans, in­clud­ing Teams, is now to­ken-based, so dol­lar val­ues are no longer re­turned by the dash­board Usage end­point. Because this is ap­plied when records are read, his­tor­i­cal re­sults are af­fected, too.

I rec­og­nize that ag­gre­gate billing to­tals are not equiv­a­lent to the cost data you were us­ing. For Teams ad­mins, the sup­ported Admin API still pro­vides spend­ing data and cost fields for us­age events.

Kaleb_Maul

(Kaleb Maul)

July 31, 2026, 8:46pm

20

On 7/30/2026 I was able to view my cost data in the us­age tab and even ex­port it along with the other data as per usual. On 7/31/2026 the cost col­umn com­pletely dis­ap­peared from my us­age tabs table. Checking fur­ther I saw that the col­umn still ex­ists when you ex­port your us­age data, but the cost for every record is set to 0.0. Even with ad­min ac­cess there is no stream­lined way to view the cost data per user, why would this be re­moved? It is so sketchy to be re­mov­ing some­thing like this and very frus­trat­ing. Is any­one else ex­pe­ri­enc­ing this is­sue? If so, is there a workaround for it or do we just sit, suf­fer, and hope that cur­sor stops be­ing so shady?

Kaleb_Maul

(Kaleb Maul)

July 31, 2026, 9:09pm

22

This does not re­ally make a lot of sense for me. So, the Cursor team de­cided yes­ter­day that they want to hide all cost data for non-en­ter­prise cus­tomers when they had ac­cess to it pre­vi­ously? I would love an ex­pla­na­tion as to how this ben­e­fits cur­rent non-en­ter­prise cus­tomers and how this helps with any con­fu­sion re­gard­ing us­age costs. Additionally, can I get a di­rect link to the spe­cific end­point used to grab the cost data for a range of dates for a spe­cific user?

Archit

July 31, 2026, 9:12pm

23

I agree. This feels like a step back for trans­parency. Even on the Individual plan, the dol­lar fig­ure was some­thing I reg­u­larly re­lied on to gauge roughly how much $ worth I was us­ing on a daily, weekly, or monthly ba­sis.

If the worry is that peo­ple mis­take that num­ber for an ac­tual charge, maybe there’s a way to fix that with­out los­ing the dol­lar fig­ure al­to­gether. Eg: show­ing a clear split in the chart be­tween what’s in­cluded in the plan and what would ac­tu­ally show up on the bill. That way the num­ber stays use­ful, but it’s un­am­bigu­ous which part is cov­ered us­age and which part is a real charge.

@kevinn I hope the team re­con­sid­ers this de­ci­sion or im­proves the vi­su­al­iza­tion to re­duce con­fu­sion while be­ing trans­par­ent.

GeorgeRay

(George Ray)

July 31, 2026, 9:38pm

24

That is too bad. I liked see­ing the dol­lar amount. I looked at that dol­lar amount as the value (cost sav­ings) I was get­ting from us­ing Cursor.

Mihai_Cracan

(Mihai Cracan)

August 1, 2026, 8:06am

26

I agree - Cursor Usage tab was per­ma­nently open in my browser.

And just to be clear - Not to ver­ify or track against Cursor sub­scrip­tion in the sense to keep them ac­count­able → but for ex­am­ple:

I was us­ing Cursor Grok 4.5 - sent a mes­sage - re­freshed us­age page - saw an in­crease of about $0.32

then maybe switch­ing to Opus 5 - did stuff - re­freshed us­age page - in­creased by $2.56

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.”

༒ Nhac Ny ༒, CC BY-SA 4.0 , via Wikimedia Commons

July 23, 2026

Last week, the gov­ern­ment an­nounced that Canada has signed the United Nations Convention against Cybercrime, with Ministers Anita Anand, Gary Anandasangaree and Sean Fraser tout­ing the treaty’s child pro­tec­tion pro­vi­sions and hu­man rights safe­guards, which were de­scribed as “among the strongest found in an in­ter­na­tional crim­i­nal jus­tice treaty.” The an­nounce­ment, re­leased in mid-July with few pay­ing at­ten­tion, left out much of the story. The re­al­ity is that the con­ven­tion is not pri­mar­ily a cy­ber­crime treaty at all, but rather a sweep­ing cross-bor­der sur­veil­lance and elec­tronic ev­i­dence-shar­ing agree­ment that Canada orig­i­nally op­posed, that lead­ing hu­man rights groups and twenty Canadian or­ga­ni­za­tions and ex­perts urged the gov­ern­ment to re­ject, and that key al­lies have thus far de­clined to sign. While sign­ing the con­ven­tion does not cre­ate bind­ing oblig­a­tions (that re­quires rat­i­fi­ca­tion), the de­ci­sion to sign a treaty that the gov­ern­ment de­clined to sign at the of­fi­cial cer­e­mony less than a year ago raises trou­bling ques­tions. This post seeks to an­swer three of them: what is this treaty, what are the risks, and what, if any­thing, changed in the last nine months?

The treaty be­gan as a Russian ini­tia­tive in 2017, de­signed to dis­place the Council of Europe’s Budapest Convention, the long­stand­ing cy­ber­crime frame­work that Russia re­fuses to join. When the UN General Assembly voted in 2019 to launch ne­go­ti­a­tions, Canada joined the United States and European Union in op­pos­ing the res­o­lu­tion, warn­ing that the process was a ve­hi­cle for ex­pand­ing state sur­veil­lance pow­ers. Having lost that vote, the democ­ra­cies faced an un­com­fort­able choice: boy­cott the ne­go­ti­a­tions and let Russia, China, and Iran write the rules, or en­gage from within and try to limit the dam­age. They chose en­gage­ment with Canada among the most ac­tive del­e­ga­tions press­ing for hu­man rights safe­guards. The strat­egy suc­ceeded in keep­ing the au­thor­i­tar­ian bloc’s wish list of speech and con­tent crimes out of the fi­nal text be­fore the con­ven­tion was adopted by con­sen­sus in December 2024.

Yet de­spite lim­it­ing the dam­age, Canada was a no-show at the sign­ing cer­e­mony in Hanoi last October, joined by the U.S., New Zealand, Japan, the Netherlands, Italy, Norway, Denmark, and Finland. Signatories in­cluded Russia, China, Iran, North Korea, Belarus, Cuba, Venezuela, and Saudi Arabia, as well as the United Kingdom, Australia, France, Germany, and the European Union. Canada is­sued a state­ment that em­pha­sized the treaty’s suc­cess “rests on states’ com­mit­ment to full ap­pli­ca­tion of the hu­man rights safe­guards in the text.” Nine months later, the gov­ern­ment signed with­out ex­plain­ing what had changed.

Canada’s pre­vi­ous con­cern with the treaty is well placed. While it enu­mer­ates a list of cy­ber­crime of­fences, its pro­ce­dural pow­ers ap­ply to elec­tronic ev­i­dence of any crim­i­nal of­fence, and its in­ter­na­tional co­op­er­a­tion oblig­a­tions ex­tend to any “serious crime,” de­fined as any of­fence pun­ish­able by four or more years’ im­pris­on­ment un­der do­mes­tic law. Since some states im­pose such penal­ties for crit­i­cism of the gov­ern­ment, jour­nal­ism, blas­phemy, or same-sex re­la­tion­ships, the treaty ef­fec­tively con­verts re­pres­sive do­mes­tic laws into trig­gers for cross-bor­der ev­i­dence gath­er­ing. Further, the Electronic Frontier Foundation, Human Rights Watch and a coali­tion of lead­ing dig­i­tal rights groups have all warned that the con­ven­tion func­tions as a global sur­veil­lance pact since it re­quires states to es­tab­lish real-time in­ter­cep­tion and data col­lec­tion pow­ers while leav­ing out safe­guards such as prior ju­di­cial au­tho­riza­tion to the dis­cre­tion of do­mes­tic law, per­mit­ting gag or­ders on co­op­er­a­tion re­quests, and omit­ting a po­lit­i­cal of­fence ex­cep­tion.

In December 2024, nearly two dozen Canadian or­ga­ni­za­tions and ex­perts, in­clud­ing Amnesty International Canada, the Criminal Lawyers’ Association, PEN Canada, OpenMedia, and the Citizen Lab’s Ron Deibert and Kate Robertson, is­sued a de­tailed let­ter urg­ing the gov­ern­ment not to sign. The let­ter warned that the treaty would cre­ate a stand­ing chan­nel for transna­tional re­pres­sion tar­get­ing di­as­pora com­mu­ni­ties in Canada and ex­plained how the con­ven­tion could sub­vert the safe­guards built into Canada’s mu­tual le­gal as­sis­tance frame­work. Robertson has sep­a­rately warned that the treaty is poised to be­come a ve­hi­cle for com­plic­ity in the mer­ce­nary spy­ware trade, while over 120 se­cu­rity re­searchers cau­tioned that its of­fences threaten to crim­i­nal­ize good-faith se­cu­rity re­search. Despite the con­cerns, the gov­ern­ment has said noth­ing, with no pub­lic con­sul­ta­tion pre­ced­ing the sig­na­ture and none of the let­ter’s con­cerns ad­dressed in the an­nounce­ment.

So what changed and why sign now? It is not clear that any­thing has changed and the con­cerns that an­i­mated Canada’s de­ci­sion to not sign nine months ago are still there. One the­ory is that this is linked to law­ful ac­cess. Indeed, the treaty and the law­ful ac­cess agenda are mu­tu­ally re­in­forc­ing, since rat­i­fi­ca­tion will re­quire im­ple­ment­ing leg­is­la­tion fea­tur­ing pre­cisely the ex­panded pro­duc­tion or­ders and cross-bor­der data shar­ing pow­ers found in Bill C-22. Lawful ac­cess was al­ready a source of con­cern, and this only makes it worse. Canada al­ready has the Budapest Convention and bi­lat­eral treaties cov­er­ing co­op­er­a­tion with the coun­tries it wants to work with, mean­ing the new con­ven­tion’s mar­ginal value lies chiefly in co­op­er­a­tion with the very states, in­clud­ing Russia, China, and Iran, that cre­ate its great­est risks. The en­tire de­ci­sion, in­clud­ing sign­ing in the mid­dle of the sum­mer when few are pay­ing at­ten­tion, is deeply trou­bling and re­quires far more than a sunny press re­lease that avoids the hard ques­tions the treaty raises.

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]

Please tick this box to con­firm you have re­viewed the above.

I have a dif­fer­ent is­sue.

What ver­sion of rip­grep are you us­ing?

rip­grep 15.2.0 (rev e89fff8)

fea­tures:+pcre2 simd(com­pile):+SSE2,-SSSE3,-AVX2 simd(run­time):+SSE2,+SSSE3,+AVX2

PCRE2 10.45 is avail­able (JIT is avail­able)

How did you in­stall rip­grep?

I orig­i­nally en­coun­tered this bug in the rg bun­dled with OpenAI Codex. That bi­nary is byte-for-byte iden­ti­cal with the one in https://​github.com/​BurntSushi/​rip­grep/​re­leases/​down­load/​15.2.0/​rip­grep-15.2.0-x86_64-un­known-linux-musl.tar.gz and I’ve re­pro­duced the bug from that in­de­pen­dently of any Codex de­pen­dency. For the analy­sis be­low, I built rg-15.2 with de­bug sym­bols in­cluded by way of CROSS_CONTAINER_ENGINE=podman CARGO_PROFILE_RELEASE_DEBUG=true ~/.cargo/bin/cross build –release –target x86_64-un­known-linux-musl.

What op­er­at­ing sys­tem are you us­ing rip­grep on?

OpenSUSE Tumbleweed Linux x86_64

Describe your bug.

Ripgrep built for x86_64-un­known-linux-musl oc­ca­sion­ally crashes with a SIGSEGV when search­ing very-large trees at a high de­gree of con­cur­rency. The crash­ing line is an in­tegrity as­ser­tion re­gard­ing heap meta­data in­side MUSL’s mal­locng, in a cal­loc call made from opendir. The com­plete back­trace is be­low.

What are the steps to re­pro­duce the be­hav­ior?

Having a suf­fi­ciently large search tree seems to be es­sen­tial for re­pro­duc­tion. Run the at­tached gen­er­ate_re­pro_tree.py. This is an LLM-written pro­gram which pro­duces a tree full of ran­dom files which mimic the sta­tis­tics of the repo in which I orig­i­nally en­coun­tered the bug. It will pro­duce a tree con­tain­ing roughly 20GiB of data across 1.8M files.

Then from the root of that tree, run rg in a loop, search­ing for some ar­bi­trary lit­eral string that is­n’t pre­sent in the tree: while true; do rg tno­heue­unot­shis­nthukoethn­sueothn­si­uothone­suioseuinth; done. On my 24-core sys­tem, hav­ing enough free RAM for the search tree to fit in the ker­nel’s block cache, it typ­i­cally takes about a minute for the SIGSEGV to ap­pear.

What is the ac­tual be­hav­ior?

I get a core­dump with the fol­low­ing back­trace:

#0 get_meta () at ../src_musl/src/malloc/mallocng/meta.h:141 #1 __malloc_allzerop () at ../src_musl/src/malloc/mallocng/malloc.c:384 #2 0x00007f71f8381b2d in cal­loc () at ../src_musl/src/malloc/calloc.c:41 #3 0x00007f71f83810f4 in opendir () at ../src_musl/src/dirent/opendir.c:15 #4 0x00007f71f835c133 in std::sys::fs::unix::read­dir::{clo­sure#0} () at li­brary/​std/​src/​sys/​fs/​unix.rs:2081 #5 std::sys::helpers::smal­l­_c_string::run_with­_c­str_s­tack<*mut libc::unix::DIR> () at li­brary/​std/​src/​sys/​helpers/​smal­l­_c_string.rs:48 #6 std::sys::helpers::smal­l­_c_string::run_with­_c­str<*mut libc::unix::DIR> () at li­brary/​std/​src/​sys/​helpers/​smal­l­_c_string.rs:28 #7 std::sys::helpers::smal­l­_c_string::run_­path_with­_c­str<*mut libc::unix::DIR> () at li­brary/​std/​src/​sys/​helpers/​smal­l­_c_string.rs:18 #8 std::sys::fs::unix::read­dir () at li­brary/​std/​src/​sys/​fs/​unix.rs:2081 #9 std::sys::fs::read­_dir () at li­brary/​std/​src/​sys/​fs/​mod.rs:68 #10 0x00007f71f8206b5c in std::fs::read­_dir<&std::path::Path> (path=…) at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/fs.rs:3265 #11 ig­nore::walk::Work::read­_dir (self=0x7f71f5bfeb20) at crates/​ig­nore/​src/​walk.rs:1551 #12 ig­nore::walk::Worker::run_one (self=0x7f71f5bfef08, work=…) at crates/​ig­nore/​src/​walk.rs:1749 #13 ig­nore::walk::Worker::run (self=…) at crates/​ig­nore/​src/​walk.rs:1697 #14 0x00007f71f821c866 in ig­nore::walk::{impl#15}::visit::{clo­sure#0}::{clo­sure#1}::{clo­sure#0} () at crates/​ig­nore/​src/​walk.rs:1463 #15 std::sys::back­trace::__rust_be­gin_short­_back­trace<ig­nore::walk::{impl#15}::visit::{clo­sure#0}::{clo­sure#1}::{clo­sure_env#0}, ()> (f=…) at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:166 #16 0x00007f71f8224596 in std::thread::life­cy­cle::spawn_unchecked::{clo­sure#1}::{clo­sure#0}<ig­nore::walk::{impl#15}::visit::{clo­sure#0}::{clo­sure#1}::{clo­sure_env#0}, ()> () at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/lifecycle.rs:70 #17 core::panic::un­wind_safe::{impl#23}::cal­l_once<(), std::thread::life­cy­cle::spawn_unchecked::{clo­sure#1}::{clo­sure_env#0}<ig­nore::walk::{impl#15}::visit::{clo­sure#0}::{clo­sure#1}::{clo­sure_env#0}, ()>> (self=…) at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panic/unwind_safe.rs:275 #18 std::pan­ick­ing::catch_un­wind::do_­call<core::panic::un­wind_safe::As­ser­tUn­wind­Safe<std::thread::life­cy­cle::spawn_unchecked::{clo­sure#1}::{clo­sure_env#0}<ig­nore::walk::{impl#15}::visit::{clo­sure#0}::{clo­sure#1}::{clo­sure_env#0}, ()>>, ()> (data=<error read­ing vari­able: Cannot ac­cess mem­ory at ad­dress 0x0>) at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:581 #19 std::pan­ick­ing::catch_un­wind<(), core::panic::un­wind_safe::As­ser­tUn­wind­Safe<std::thread::life­cy­cle::spawn_unchecked::{clo­sure#1}::{clo­sure_env#0}<ig­nore::walk::{impl#15}::visit::{clo­sure#0}::{clo­sure#1}::{clo­sure_env#0}, ()>>> (f=…) at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:544 #20 std::panic::catch_un­wind<core::panic::un­wind_safe::As­ser­tUn­wind­Safe<std::thread::life­cy­cle::spawn_unchecked::{clo­sure#1}::{clo­sure_env#0}<ig­nore::walk::{impl#15}::visit::{clo­sure#0}::{clo­sure#1}::{clo­sure_env#0}, ()>>, ()> (f=…) at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:359 #21 std::thread::life­cy­cle::spawn_unchecked::{clo­sure#1}<ig­nore::walk::{impl#15}::visit::{clo­sure#0}::{clo­sure#1}::{clo­sure_env#0}, ()> () at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/lifecycle.rs:68 #22 core::ops::func­tion::FnOnce::cal­l_once<std::thread::life­cy­cle::spawn_unchecked::{clo­sure_env#1}<ig­nore::walk::{impl#15}::visit::{clo­sure#0}::{clo­sure#1}::{clo­sure_env#0}, ()>, ()> () at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250 #23 0x00007f71f8361fcf in al­loc::boxed::{impl#31}::cal­l_once<(), (dyn core::ops::func­tion::FnOnce<(), Output=()> + core::marker::Send), al­loc::al­loc::Global> () at li­brary/​al­loc/​src/​boxed.rs:2275 #24 std::sys::thread::unix::{impl#2}::new::thread­_s­tart () at li­brary/​std/​src/​sys/​thread/​unix.rs:118 #25 0x00007f71f8388788 in start () at ../src_musl/src/thread/pthread_create.c:207 #26 0x00007f71f8389e6c in __clone () at ../src_musl/src/thread/x86_64/clone.s:22

Here is the core dump and the cor­re­spond­ing rg bi­nary which pro­duced it.

What is the ex­pected be­hav­ior?

Not a seg­fault.

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.

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.

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.

Machine-Level OOP, Exceptions, and Concurrency

by Randall Hyde

Available June 2026, 792 pp.

ISBN-13:

9781718504349

Contents

Download Chapter 1: Advanced Macros

You can ask an AI to ex­plain how vta­bles work in x86. It will give you some­thing that sounds right. What it won’t give you is what Windows ac­tu­ally ex­pects the vtable to look like, why method dis­patch be­haves the way it does at the in­struc­tion level, or what breaks when you de­vi­ate from con­ven­tion. This vol­ume of The Art of 64-Bit Assembly closes the gap be­tween a plau­si­ble ex­pla­na­tion and gen­uine un­der­stand­ing.

Every chap­ter takes a con­struct you’ve used in C++, Python, or Rust, strips away the run­time, and re­builds it from scratch in MASM, run­ning un­der Windows. Objects, ex­cep­tions, clo­sures, corou­tines, con­cur­rency: Each is dis­sected at the in­struc­tion level, with every de­ci­sion made vis­i­ble and ex­plicit.

What you’ll build:

Object-oriented pro­grams in MASM: vta­bles, method dis­patch, and in­her­i­tance, from scratch by hand

Windows struc­tured ex­cep­tion han­dling (SEH) in­stalled and man­aged at the in­struc­tion level

Thunks, clo­sures, and it­er­a­tors that be­have like higher-or­der func­tions

Coroutines, gen­er­a­tors, and fibers with­out re­sort­ing to HLL code

Concurrent pro­grams with real syn­chro­niza­tion prim­i­tives, di­rectly from as­sem­bly

Unicode string han­dling done cor­rectly, at the level where most code gets it wrong

Domain-specific macro lan­guages in­side MASM, built from first prin­ci­ples

If you al­ready know as­sem­bly and want to stop tak­ing the hard parts on faith, this is the book.

Author Bio

Randall Hyde has spent decades writ­ing as­sem­bly for med­ical de­vices, nu­clear sys­tems, and em­bed­ded hard­ware where cor­rect­ness is not op­tional. He taught as­sem­bly lan­guage pro­gram­ming at the uni­ver­sity level and is the au­thor of The Art of Assembly Language, The Art of ARM Assembly, and the Write Great Code se­ries, all from No Starch Press.

Table of con­tents

Acknowledgments Introduction

Chapter 1: Advanced Macros Chapter 2: Unicode Strings Chapter 3: Transcendental Functions Chapter 4: Advanced Procedures Chapter 5: Concurrent Programming Chapter 6: Object-Oriented Programming With MASM Chapter 7: Exception Handling Chapter 8: Thunks and Closures Chapter 9: Advanced Parameter Implementation Chapter 10: Iterators Chapter 11: Coroutines, Generators, and Fibers

Appendix A: ASCII Character Set Appendix B: Glossary Appendix C: Installing and Using Visual Studio

Index

View the Copyright page View the de­tailed Table of Contents View the Index