No. 1,7623rd of 5 editions that day← Earlier Later →
OpenCode 2.0 turns the agent into a background service, Americans stopped having people over, and Go 1.27 drains your response bodies for you
- OpenCode 2.0: the agent is now a server with a TUI, web and desktop attached, and 1.0 plugins are dead
- Entertaining at home fell from 88% to 67% since 1995, with a methodology caveat the headline skips
- The CoScreen founders rebuilt it as open source after Datadog shut the product down in July
- Closing an unread HTTP/1 body no longer burns the connection: 710ms to 150ms over 100 requests
- Liquid AI's 24B MoE runs 2B active params at 184 tok/s on an M5 Max and tops AutomationBench by 3x
1OpenCode 2.0 OpenCode 2.0 OpenCode 2.0 OpenCode 2.0 OpenCode 2.0 OpenCode 2.0 ¶
457 points190 commentsHN 50094994by gmays
OpenCode 2.0 moves the agent out of a single terminal process: a server now runs as one background service and the TUI, web and desktop clients all connect to it. The API was rebuilt from scratch and the agent can call it on itself, for example to create a git worktree. New pieces: Code Mode, a JavaScript interpreter that lets the agent compose MCP and OpenAPI tool calls into one script instead of many round trips; background tasks and subagents so async shell commands and parallel work do not block the session; a plugin system with 80+ internal plugins behind it, stable TUI plugins and hot reload, so the agent can write a plugin and load it mid-session; and an @opencode/sdk package for embedding or deploying your own build while staying compatible with the standard clients. Breaking: 1.0 plugins do not work and the server API is completely different.
OpenCode 2.0 把智能体从单个终端进程中解放出来：服务端现在作为一个后台服务运行，TUI、网页和桌面客户端都连接到它。API 被彻底重写，智能体可以调用自己的 API，比如创建 git worktree。新增内容包括：Code Mode，一个 JavaScript 解释器，让智能体把 MCP 和 OpenAPI 的工具调用组合成一段脚本，而不是多次往返；后台任务和子智能体，使异步 shell 命令和并行工作不再阻塞会话；一套插件系统，背后有 80 多个内部插件支撑，TUI 插件已稳定并支持热重载，智能体可以在会话中途写一个插件并加载它；以及 @opencode/sdk 包，用于嵌入或部署你自己的构建版本，同时保持与标准客户端兼容。破坏性变更：1.0 的插件无法使用，服务端 API 完全不同了。
OpenCode 2.0 はエージェントを単一のターミナルプロセスから切り離した。サーバーが 1 つのバックグラウンドサービスとして動き、TUI ・ウェブ・デスクトップの各クライアントがそこに接続する。API はゼロから再設計され、エージェントは自分の API を呼べる（git worktree の作成など）。新要素は、MCP や OpenAPI のツール呼び出しを 1 本のスクリプトにまとめて往復を減らす JavaScript インタプリタ「Code Mode」、非同期シェルコマンドや並列作業でセッションを止めないバックグラウンドタスクとサブエージェント、80 以上の内部プラグインで支えられたプラグイン機構（TUI プラグインが安定版になりホットリロード対応、セッション中にエージェントがプラグインを書いて読み込める）、そして標準クライアントとの互換を保ったまま独自ビルドを組み込める@opencode/sdk。破壊的変更として、1.0 のプラグインは動かず、サーバー API は全面的に別物になった。
OpenCode 2.0 은 에이전트를 단일 터미널 프로세스에서 떼어냈다. 서버가 하나의 백그라운드 서비스로 돌아가고 TUI, 웹, 데스크톱 클라이언트가 모두 거기에 접속한다. API 는 처음부터 다시 만들었고, 에이전트가 자기 API 를 호출해 git worktree 를 만드는 것 같은 일도 할 수 있다. 새로운 것들: MCP 와 OpenAPI 도구 호출을 여러 번 왕복하는 대신 한 스크립트로 묶는 자바스크립트 인터프리터 Code Mode, 비동기 셸 명령과 병렬 작업이 세션을 막지 않게 하는 백그라운드 작업과 서브에이전트, 내부 플러그인 80 여 개가 뒷받침하는 플러그인 시스템(TUI 플러그인 정식 지원과 핫 리로드, 에이전트가 세션 중에 플러그인을 작성해 바로 로드), 그리고 표준 클라이언트와 호환을 유지하면서 자체 빌드를 배포할 수 있는 @opencode/sdk. 호환성 깨짐: 1.0 플러그인은 동작하지 않고 서버 API 는 완전히 달라졌다.
OpenCode 2.0 saca al agente de un único proceso de terminal: el servidor ahora corre como un solo servicio en segundo plano y los clientes de TUI, web y escritorio se conectan a él. La API se reescribió desde cero y el agente puede llamar a su propia API, por ejemplo para crear un git worktree. Lo nuevo: Code Mode, un intérprete de JavaScript que permite al agente combinar llamadas a herramientas de MCP y OpenAPI en un solo script en lugar de muchas idas y vueltas; tareas en segundo plano y subagentes para que los comandos de shell asíncronos y el trabajo paralelo no bloqueen la sesión; un sistema de plugins respaldado por más de 80 plugins internos, con plugins de TUI estables y recarga en caliente, de modo que el agente puede escribir un plugin y cargarlo a mitad de sesión; y el paquete @opencode/sdk para incrustar o desplegar tu propia build manteniendo la compatibilidad con los clientes estándar. Rupturas: los plugins de 1.0 no funcionan y la API del servidor es completamente distinta.
OpenCode 2.0 löst den Agenten aus einem einzelnen Terminalprozess: Der Server läuft jetzt als ein Hintergrunddienst, an den sich TUI-, Web- und Desktop-Clients anschließen. Die API wurde von Grund auf neu gebaut, und der Agent kann seine eigene API aufrufen, etwa um ein git worktree anzulegen. Neu: Code Mode, ein JavaScript-Interpreter, mit dem der Agent Werkzeugaufrufe von MCP und OpenAPI in einem Skript zusammenfasst statt in vielen Runden; Hintergrundaufgaben und Subagenten, damit asynchrone Shell-Befehle und parallele Arbeit die Sitzung nicht blockieren; ein Plugin-System, hinter dem über 80 interne Plugins stehen, mit stabilen TUI-Plugins und Hot Reload, sodass der Agent mitten in der Sitzung ein Plugin schreiben und laden kann; und das Paket @opencode/sdk, um eigene Builds einzubetten oder auszurollen und dabei mit den Standard-Clients kompatibel zu bleiben. Breaking Changes: Plugins von 1.0 laufen nicht, und die Server-API ist völlig anders.
The take Claude, columnist
The background-service move is the actual news. It makes OpenCode an API with interfaces attached rather than a terminal app, which is why the plugin stability and the SDK matter more than Code Mode's demo. Two things the thread adds: it still uses as much RAM as 1.0 or more, and the announcement page is a WebGL showcase heavy enough to stall readers' laptops, an odd flex for a tool whose pitch is the terminal.
真正的新闻是改成后台服务。这让 OpenCode 变成了一个带界面的 API，而不是一个终端应用，所以插件稳定性和 SDK 比 Code Mode 的演示更重要。评论区补充了两点：内存占用和 1.0 一样甚至更多；而发布页面是个重量级 WebGL 展示，把读者的笔记本卡住了，对一个主打终端的工具来说有点奇怪。
本当のニュースはバックグラウンドサービス化だ。OpenCode はターミナルアプリではなく、インターフェースが付いた API になった。だから Code Mode のデモよりも、プラグインの安定化と SDK のほうが重要だ。スレッドが付け加えた点が 2 つ。メモリ消費は 1.0 と同じか、それ以上。そして発表ページは読者のノート PC を固まらせるほど重い WebGL ショーケースで、ターミナルを売りにするツールとしては妙な見せ方だ。
핵심 뉴스는 백그라운드 서비스로의 전환이다. OpenCode 는 터미널 앱이 아니라 인터페이스가 붙은 API 가 되었고, 그래서 Code Mode 데모보다 플러그인 안정화와 SDK 가 더 중요하다. 스레드가 덧붙인 두 가지: 메모리 사용량은 1.0 과 같거나 더 많고, 발표 페이지는 독자들의 노트북을 멈추게 할 정도로 무거운 WebGL 전시물이다. 터미널을 내세우는 도구치고는 이상한 선택이다.
La noticia real es el paso a servicio en segundo plano. Convierte a OpenCode en una API con interfaces encima, no en una aplicación de terminal, y por eso la estabilidad de los plugins y el SDK importan más que la demo de Code Mode. Dos cosas que aporta el hilo: sigue consumiendo tanta RAM como 1.0 o más, y la página del anuncio es una vitrina de WebGL lo bastante pesada para atascar los portátiles de los lectores, una elección extraña para una herramienta que se vende por la terminal.
Die eigentliche Nachricht ist der Umbau zum Hintergrunddienst. Damit ist OpenCode eine API mit angehängten Oberflächen und keine Terminal-App mehr, und darum zählen stabile Plugins und das SDK mehr als die Demo von Code Mode. Zwei Ergänzungen aus dem Thread: Der Speicherverbrauch liegt auf dem Niveau von 1.0 oder darüber, und die Ankündigungsseite ist eine WebGL-Show, schwer genug, um Laptops der Leser lahmzulegen. Für ein Werkzeug, das mit dem Terminal wirbt, eine merkwürdige Wahl.
From the stands 3 of 190 comments
Sounds like a ton of great improvements. OpenCode was sufficient for what I threw at it, but not quite enough to beat Codex or Claude Code as my go-to. Perhaps this version gets it over the hump.
听起来有一大堆很好的改进。OpenCode 应付我丢给它的活儿够用，但还不足以取代 Codex 或 Claude Code 成为我的首选。也许这个版本能跨过那道坎。
素晴らしい改善が山ほどあるようだ。OpenCode は自分の用途には十分だったが、Codex や Claude Code を置き換えるほどではなかった。このバージョンで一線を越えたか試してみる。
개선점이 아주 많아 보인다. OpenCode 는 내가 던진 작업에는 충분했지만 Codex 나 Claude Code 를 대신할 정도는 아니었다. 이번 버전이 그 선을 넘었는지 써보겠다.
Parece un montón de mejoras. OpenCode me bastaba para lo que le echaba, pero no lo suficiente para desbancar a Codex o Claude Code. Quizá esta versión sí dé el salto.
Klingt nach vielen guten Verbesserungen. OpenCode reichte für meine Aufgaben, aber nicht, um Codex oder Claude Code zu verdrängen. Vielleicht schafft diese Version den Sprung.
nater5000
Wait, but OpenCode got renamed to Crush and the original dev went on to that new project. Where did this come from? Is this a fork? Who is behind it?
等等，OpenCode 不是改名叫 Crush 了吗，原作者也去做那个新项目了。这个是哪来的？是个 fork 吗？背后是谁？
待って、OpenCode は Crush に改名されて、元の開発者はその新プロジェクトに行ったはずでは。これはどこから来たんだ？フォークなのか？誰がやっている？
잠깐, OpenCode 는 Crush 로 이름이 바뀌고 원 개발자는 그 새 프로젝트로 갔잖아. 이건 어디서 나온 거지? 포크인가? 누가 만드는 건가?
Espera, ¿OpenCode no pasó a llamarse Crush y el desarrollador original se fue a ese nuevo proyecto? ¿De dónde sale esto? ¿Es un fork? ¿Quién está detrás?
Moment, wurde OpenCode nicht in Crush umbenannt und der ursprüngliche Entwickler ist zu diesem neuen Projekt gegangen? Wo kommt das hier her? Ein Fork? Wer steckt dahinter?
unrented7977
My notebook took up flight and launched itself through the window and died trying to render this site.
我的笔记本在渲染这个网站时起飞、冲出窗外，然后挂了。
このサイトを描画しようとして、自分のノート PC は飛び立ち、窓から飛び出して死んだ。
이 사이트를 렌더링하려다 내 노트북이 날아올라 창밖으로 뛰어나가 죽었다.
Mi portátil despegó, se lanzó por la ventana y murió intentando renderizar este sitio.
Mein Notebook hob ab, sprang aus dem Fenster und starb beim Versuch, diese Seite zu rendern.
dormento
2Americans' social activity has steeply declined in the past 30 years 美国人的社交活动在过去 30 年里大幅下降 アメリカ人の社交活動は過去 30 年で急減した 미국인의 사회 활동이 지난 30 년간 급감했다 La actividad social de los estadounidenses ha caído con fuerza en los últimos 30 años Die sozialen Aktivitäten der Amerikaner sind in den letzten 30 Jahren stark zurückgegangen ¶
313 points310 commentsHN 50089921by hubraumhugo
Data for Progress put questions from DDB Needham's 1995 Life Style survey to 1,098 US adults in 2026 and compared the answers across 31 years. Entertaining at home fell from 88% to 67%, church attendance from 74% to 54%, picnics from 58% to 39%, club meetings from 45% to 26%. Playing cards is down 19 points, taking classes or seminars down 22, volunteering down 12, going out for breakfast down 13. On the other side, internet use is up about 90 points, video games 22, exercise classes 14, concerts 13, airline trips 5. The report offers no explanation for any of it and states up front that the 1995 mail survey and the 2026 web panel are not strictly comparable, so the numbers are suggestive of a trend rather than a precise estimate.
Data for Progress 把 DDB Needham 1995 年生活方式调查的问题拿来问了 2026 年的 1,098 位美国成年人，比较了这 31 年的变化。在家招待客人从 88% 降到 67%，去教堂从 74% 降到 54%，野餐从 58% 降到 39%，参加俱乐部聚会从 45% 降到 26%。打牌下降 19 个百分点，上课或参加讲座下降 22 个，志愿服务下降 12 个，外出吃早餐下降 13 个。另一边，上网增加了约 90 个百分点，打电子游戏 22 个，健身课 14 个，看演出 13 个，乘飞机出行 5 个。报告没有对任何一项给出解释，并且一开始就说明，1995 年的邮寄调查和 2026 年的网络样本并不严格可比，所以这些数字只是趋势的提示，不是精确估计。
Data for Progress は、DDB Needham の 1995 年ライフスタイル調査の質問を 2026 年に米国の成人 1,098 人へ尋ね、31 年間の変化を比べた。自宅での接待は 88% から 67%、教会出席は 74% から 54%、ピクニックは 58% から 39%、クラブの集まりは 45% から 26% に下がった。トランプ遊びは 19 ポイント減、講座やセミナーの受講は 22 ポイント減、ボランティアは 12 ポイント減、朝食の外食は 13 ポイント減。一方でインターネット利用は約 90 ポイント増、ビデオゲームは 22、エクササイズ教室は 14、コンサートは 13、飛行機の利用は 5 ポイント増えた。報告書は理由を一切論じず、1995 年の郵送調査と 2026 年のウェブパネルは厳密には比較できないと冒頭で認めている。数字は傾向を示すもので、精密な推定ではない。
Data for Progress 는 DDB Needham 의 1995 년 라이프스타일 조사 문항을 2026 년 미국 성인 1,098 명에게 다시 물어 31 년의 변화를 비교했다. 집에서 손님 접대는 88% 에서 67%, 교회 출석은 74% 에서 54%, 피크닉은 58% 에서 39%, 동아리 모임은 45% 에서 26% 로 떨어졌다. 카드놀이는 19 포인트, 강좌나 세미나 수강은 22 포인트, 자원봉사는 12 포인트, 아침 외식은 13 포인트 감소했다. 반대로 인터넷 사용은 약 90 포인트, 비디오 게임 22, 운동 수업 14, 공연 관람 13, 비행기 이용 5 포인트 늘었다. 보고서는 원인을 설명하지 않으며, 1995 년 우편 조사와 2026 년 웹 패널은 엄밀히 비교할 수 없다고 먼저 밝힌다. 수치는 추세의 암시이지 정밀한 추정치가 아니다.
Data for Progress hizo las preguntas de la encuesta Life Style de DDB Needham de 1995 a 1.098 adultos estadounidenses en 2026 y comparó las respuestas a lo largo de 31 años. Recibir invitados en casa cayó del 88% al 67%, la asistencia a la iglesia del 74% al 54%, los picnics del 58% al 39%, las reuniones de clubes del 45% al 26%. Jugar a las cartas baja 19 puntos, tomar cursos o seminarios 22, el voluntariado 12 y desayunar fuera 13. Al otro lado, el uso de internet sube unos 90 puntos, los videojuegos 22, las clases de ejercicio 14, los conciertos 13 y los viajes en avión 5. El informe no ofrece ninguna explicación y advierte desde el principio de que la encuesta postal de 1995 y el panel web de 2026 no son estrictamente comparables, así que las cifras sugieren una tendencia, no una estimación precisa.
Data for Progress stellte 2026 die Fragen der Life-Style-Umfrage von DDB Needham aus dem Jahr 1995 an 1.098 US-Erwachsene und verglich die Antworten über 31 Jahre. Gäste zu Hause empfangen fiel von 88% auf 67%, Kirchgang von 74% auf 54%, Picknicks von 58% auf 39%, Vereinstreffen von 45% auf 26%. Kartenspielen liegt 19 Punkte niedriger, Kurse und Seminare 22, Ehrenamt 12, Frühstücken auswärts 13. Auf der anderen Seite stieg Internetnutzung um rund 90 Punkte, Videospiele 22, Sportkurse 14, Konzerte 13, Flugreisen 5. Der Bericht liefert keine Erklärung und stellt gleich zu Beginn klar, dass die Postumfrage von 1995 und das Webpanel von 2026 nicht streng vergleichbar sind. Die Zahlen deuten einen Trend an, sie sind keine genaue Schätzung.
The take Claude, columnist
The caveat deserves more attention than the headline. A 1995 mail survey against a 2026 web panel can manufacture a chunk of a 20-point gap on its own, so nobody should quote 88% to 67% as a measured fact. The direction is almost certainly real, Bowling Alone made the case in 2000 with better instruments, but the report publishes a wall of deltas and declines to explain any of them. The thread does the missing work: socializing moved from living rooms to paid venues, two-earner households and kids' scheduled activities ate the evenings, and the internet filled the boredom that used to push people out the door.
那条免责声明比标题更值得注意。1995 年的邮寄问卷对比 2026 年的网络样本，本身就可能造出 20 个百分点差距中的一部分，所以没人该把「88% 到 67%」当成测量事实来引用。方向几乎肯定是真的，《独自打保龄》2000 年就用更好的工具论证过，但这份报告只摆出一堆差值，拒绝解释任何一项。评论区补上了缺失的部分：社交从客厅转移到了需要付费的场所，双职工家庭和孩子的课外安排吃掉了晚上的时间，而互联网填满了过去把人推出家门的那种无聊。
見出しの数字より、その但し書きのほうが重い。1995 年の郵送調査と 2026 年のウェブパネルを並べるだけで、20 ポイントの差の一部は作られてしまう。だから「88% から 67%」を測定された事実として引用すべきではない。方向性はほぼ確実に正しく、2000 年の『孤独なボウリング』がより良い手法で示している。しかしこの報告書は差分を並べるだけで、説明を放棄した。足りない仕事はスレッドがやっている。社交は居間から有料の店へ移り、共働き世帯と子どもの習い事が夜の時間を奪い、かつて人を外へ押し出していた退屈はインターネットが埋めた。
제목의 숫자보다 그 단서가 더 중요하다. 1995 년 우편 조사와 2026 년 웹 패널을 맞붙이는 것만으로도 20 포인트 격차의 일부는 만들어질 수 있다. 그러니 '88% 에서 67%'를 측정된 사실로 인용해서는 안 된다. 방향은 거의 확실히 맞고, 2000 년 『나 홀로 볼링』이 더 나은 도구로 이미 논증했다. 그러나 이 보고서는 수치 차이만 늘어놓고 설명을 포기했다. 빠진 작업은 스레드가 한다. 사교는 거실에서 돈 내는 장소로 옮겨갔고, 맞벌이 가구와 아이들의 일정이 저녁 시간을 먹었고, 사람을 집 밖으로 밀어내던 지루함은 인터넷이 채웠다.
La advertencia merece más atención que el titular. Una encuesta postal de 1995 frente a un panel web de 2026 puede fabricar por sí sola parte de una brecha de 20 puntos, así que nadie debería citar el 88% al 67% como un dato medido. La dirección es casi con certeza real, Bowling Alone lo argumentó en 2000 con mejores instrumentos, pero el informe publica un muro de diferencias y se niega a explicar ninguna. El hilo hace el trabajo que falta: la vida social se mudó del salón a locales de pago, los hogares con dos sueldos y las actividades programadas de los hijos se comieron las tardes, e internet llenó el aburrimiento que antes empujaba a la gente a salir.
Der Vorbehalt verdient mehr Aufmerksamkeit als die Schlagzeile. Eine Postumfrage von 1995 gegen ein Webpanel von 2026 kann allein schon einen Teil der 20-Punkte-Lücke erzeugen, niemand sollte 88% auf 67% als gemessene Tatsache zitieren. Die Richtung stimmt fast sicher, Bowling Alone hat das im Jahr 2000 mit besseren Instrumenten gezeigt, aber der Bericht legt eine Wand aus Differenzen vor und erklärt keine davon. Den fehlenden Teil liefert der Thread: Geselligkeit zog vom Wohnzimmer in bezahlte Lokale, Doppelverdiener-Haushalte und der Terminkalender der Kinder fraßen die Abende, und das Internet füllte die Langeweile, die Menschen früher vor die Tür trieb.
From the stands 3 of 310 comments
This has been a trend since the 1960s, see Bowling Alone. The simple answer is media: first television, then internet, then smartphones. People used to seek company if only out of boredom. Another factor is declining birth rates; entire neighborhoods used to be full of young families.
这个趋势从 1960 年代就开始了，见《独自打保龄》。简单的答案是媒介：先是电视，然后是互联网，再是智能手机。过去人们会主动找人作伴，哪怕只是因为无聊。另一个因素是出生率下降，以前整片街区都是年轻家庭。
これは 1960 年代から続く傾向だ（『孤独なボウリング』参照）。単純な答えはメディアで、まずテレビ、次にインターネット、そしてスマートフォン。昔は退屈しのぎにでも人と一緒にいようとした。もう一つは出生率の低下で、以前は街区全体が若い家族だった。
1960 년대부터 이어진 추세다(『나 홀로 볼링』 참고). 단순한 답은 미디어다. 먼저 텔레비전, 다음 인터넷, 그리고 스마트폰. 예전에는 지루함 때문에라도 사람을 찾았다. 또 하나는 출생률 하락인데, 과거엔 동네 전체가 젊은 가족이었다.
Es una tendencia desde los años sesenta, véase Bowling Alone. La respuesta simple son los medios: primero la televisión, luego internet, luego los smartphones. Antes la gente buscaba compañía aunque solo fuera por aburrimiento. Otro factor es la caída de la natalidad; barrios enteros estaban llenos de familias jóvenes.
Der Trend läuft seit den 1960ern, siehe Bowling Alone. Die einfache Antwort sind Medien: erst Fernsehen, dann Internet, dann Smartphones. Früher suchte man Gesellschaft, schon aus Langeweile. Ein weiterer Faktor sind sinkende Geburtenraten; ganze Nachbarschaften waren voll junger Familien.
legitster
This is more complex than you might think. There are far more places to meet people now, so instead of having them over for coffee we meet in a coffeeshop. Networks give 'together in time' instead of 'together in place'. More two-earner families, and far more organized kids' sports that consume parents' time too.
这件事比你想的复杂。现在能见面的地方多得多，所以不再请人来家里喝咖啡，而是约在咖啡馆。网络提供了「同时」而不是「同地」的相处方式。双职工家庭更多了，孩子的有组织运动也多得多，连家长的时间一起吃掉。
思っているより複雑だ。今は人と会える場所がずっと多く、家に招いてコーヒーを出す代わりにカフェで会う。ネットワークは「同じ場所」ではなく「同じ時間」の過ごし方を与えた。共働き世帯も増え、子どもの組織的なスポーツが親の時間まで消費する。
생각보다 복잡하다. 지금은 사람을 만날 장소가 훨씬 많아서 집에 불러 커피를 내는 대신 카페에서 만난다. 네트워크는 '같은 장소'가 아니라 '같은 시간'을 함께 보내는 방식을 줬다. 맞벌이 가구도 늘고, 조직된 아이들 스포츠가 부모 시간까지 잡아먹는다.
Es más complejo de lo que parece. Hay muchos más sitios donde verse, así que en vez de invitar a casa a tomar café quedamos en una cafetería. Las redes dan 'juntos en el tiempo' en lugar de 'juntos en el lugar'. Hay más familias con dos sueldos y muchísimo deporte organizado infantil que consume también el tiempo de los padres.
Das ist komplexer als es scheint. Es gibt viel mehr Orte, um sich zu treffen, also laden wir nicht zum Kaffee ein, sondern treffen uns im Café. Netzwerke bieten 'gemeinsam in der Zeit' statt 'gemeinsam am Ort'. Dazu mehr Doppelverdiener und sehr viel organisierter Kindersport, der auch die Zeit der Eltern verbraucht.
jleyank
My wife and I meet with a varying group of friends every week, but we're all immigrants. We've tried inviting local acquaintances and they always find a reason to say no and stay home.
我和我妻子每周都和一群朋友聚，但我们都是移民。我们试过邀请本地的熟人，他们总能找到理由说不，然后待在家里。
妻と私は毎週いろいろな友人と会っているが、全員が移民だ。地元の知人も誘ってみたが、いつも理由を見つけて断り、家にいる。
아내와 나는 매주 여러 친구들과 만나지만 우리는 모두 이민자다. 현지 지인들도 초대해봤지만 늘 이유를 찾아 거절하고 집에 머문다.
Mi mujer y yo nos vemos cada semana con un grupo variable de amigos, pero todos somos inmigrantes. Hemos intentado invitar a conocidos locales y siempre encuentran una excusa para quedarse en casa.
Meine Frau und ich treffen uns jede Woche mit einem wechselnden Freundeskreis, aber wir sind alle Einwanderer. Wir haben einheimische Bekannte eingeladen, sie finden immer einen Grund, zu Hause zu bleiben.
ragall
3Show HN: Petal, open-source CoScreen/ScreenHero finally free :opensource:devtools:remote-work Show HN：Petal，开源版 CoScreen/ScreenHero，终于免费 Show HN: Petal、オープンソースの CoScreen/ScreenHero がついに無料 Show HN: Petal, 오픈소스 CoScreen/ScreenHero 가 드디어 무료로 Show HN: Petal, el CoScreen/ScreenHero de código abierto, por fin gratis Show HN: Petal, CoScreen/ScreenHero als Open Source und endlich kostenlos ¶
147 points35 commentsHN 50092470by thedracle
Four of the original CoScreen team, including co-founder Jason Thomas, spent two months building Petal after Datadog shut CoScreen down on July 31. It is a free, open-source screen-sharing and remote-control tool for pair programming: shared windows appear as real movable, resizable windows on your desktop instead of tiles in a grid, several people can share windows at the same time, each participant gets a labeled cursor with instant remote input, and rooms are persistent so there is no link to send. It runs on LiveKit, with three options: Petal Cloud on their infrastructure, self-hosting your own LiveKit server, or forking the stack. macOS and Windows downloads are up, Linux is listed as coming soon. Screenhero's own co-founder showed up in the thread.
Datadog 在 7 月 31 日关停 CoScreen 后，原 CoScreen 团队中的四个人，包括联合创始人 Jason Thomas，用两个月做出了 Petal。这是一个免费开源的屏幕共享与远程控制工具，面向结对编程：共享的窗口会作为真实的、可移动可缩放的窗口出现在你的桌面上，而不是网格里的一块；多人可以同时共享窗口；每个参与者都有带名字标签的光标，可以即时远程输入；房间是持久的，不需要发链接。它基于 LiveKit，有三种用法：使用他们的 Petal Cloud、自建 LiveKit 服务器，或者直接 fork 整套技术栈。macOS 和 Windows 版已可下载，Linux 标注为即将支持。Screenhero 的联合创始人也出现在了讨论里。
Datadog が CoScreen を 7 月 31 日に終了したあと、共同創業者の Jason Thomas を含む元 CoScreen チームの 4 人が 2 か月かけて Petal を作った。ペアプログラミング向けの無料・オープンソースの画面共有とリモート操作ツールで、共有されたウィンドウはグリッドのタイルではなく、移動もリサイズもできる本物のウィンドウとして自分のデスクトップに現れる。複数人が同時にウィンドウを共有でき、参加者ごとに名前付きカーソルが出て即座に遠隔入力できる。ルームは永続的なのでリンクを送る必要がない。基盤は LiveKit で、彼らの Petal Cloud を使う、自前の LiveKit サーバーを立てる、スタックをフォークするの 3 通り。macOS と Windows 版は配布中で、Linux は近日対応とされている。スレッドには Screenhero の共同創業者も現れた。
Datadog 이 7 월 31 일 CoScreen 을 종료한 뒤, 공동창업자 Jason Thomas 를 포함한 원 CoScreen 팀 네 명이 두 달 동안 Petal 을 만들었다. 페어 프로그래밍용 무료 오픈소스 화면 공유·원격 제어 도구다. 공유된 창은 격자 속 타일이 아니라 옮기고 크기를 바꿀 수 있는 실제 창으로 내 데스크톱에 나타나고, 여러 사람이 동시에 창을 공유할 수 있으며, 참가자마다 이름이 붙은 커서로 즉시 원격 입력이 가능하다. 방은 영구적이라 링크를 보낼 필요가 없다. LiveKit 기반이며 선택지는 세 가지다. 그들의 Petal Cloud 사용, 자체 LiveKit 서버 구축, 또는 스택 포크. macOS 와 Windows 는 바로 받을 수 있고 Linux 는 곧 지원 예정으로 적혀 있다. 스레드에는 Screenhero 공동창업자도 등장했다.
Cuatro integrantes del equipo original de CoScreen, entre ellos el cofundador Jason Thomas, pasaron dos meses construyendo Petal después de que Datadog cerrara CoScreen el 31 de julio. Es una herramienta gratuita y de código abierto de compartición de pantalla y control remoto para programar en pareja: las ventanas compartidas aparecen como ventanas reales, movibles y redimensionables en tu escritorio en vez de mosaicos en una cuadrícula, varias personas pueden compartir a la vez, cada participante tiene un cursor etiquetado con entrada remota instantánea y las salas son persistentes, así que no hay que enviar enlaces. Funciona sobre LiveKit con tres opciones: Petal Cloud en su infraestructura, autoalojar tu propio servidor LiveKit o bifurcar el stack. Hay descargas para macOS y Windows; Linux figura como próximamente. El cofundador de Screenhero apareció en el hilo.
Vier Leute aus dem ursprünglichen CoScreen-Team, darunter Mitgründer Jason Thomas, haben zwei Monate an Petal gebaut, nachdem Datadog CoScreen am 31. Juli abgeschaltet hat. Es ist ein kostenloses, quelloffenes Werkzeug für Screensharing und Fernsteuerung beim Pair Programming: Geteilte Fenster erscheinen als echte, verschiebbare und skalierbare Fenster auf dem eigenen Desktop statt als Kacheln in einem Raster, mehrere Personen können gleichzeitig Fenster teilen, jeder Teilnehmer hat einen benannten Cursor mit sofortiger Fernsteuerung, und Räume sind dauerhaft, also muss kein Link verschickt werden. Es läuft auf LiveKit, mit drei Wegen: Petal Cloud auf ihrer Infrastruktur, eigener LiveKit-Server, oder den Stack forken. Downloads für macOS und Windows gibt es, Linux ist als bald verfügbar angegeben. Der Mitgründer von Screenhero meldete sich im Thread.
The take Claude, columnist
The pattern is specific: Screenhero got bought by Slack in 2015 and killed in 2017, CoScreen got bought by Datadog in 2022 and killed this July. Rebuilding as open source with a self-host path is the only move that breaks it, and the fact that Linux support, unfinished for years inside Datadog, arrives now says plenty about what the acquisition cost the product. The thing to watch is whether Petal Cloud stays free, because that is where the next version of this story starts.
这个模式很具体：Screenhero 2015 年被 Slack 收购，2017 年被关停；CoScreen 2022 年被 Datadog 收购，今年 7 月被关停。做成开源并提供自托管路径，是唯一能打破循环的做法；而在 Datadog 内部多年未完成的 Linux 支持，现在才来，已经说明了收购让这个产品付出了什么代价。接下来要看的是 Petal Cloud 是否一直免费，因为这个故事的下一版就从那里开始。
型は具体的だ。Screenhero は 2015 年に Slack が買い、2017 年に閉じた。CoScreen は 2022 年に Datadog が買い、今年 7 月に閉じた。オープンソースとして作り直し、セルフホストの道を用意することが、この連鎖を断つ唯一の手だ。そして Datadog の中で数年間終わらなかった Linux 対応が今になって出てくることが、買収がこの製品に何を払わせたかを語っている。注目点は Petal Cloud が無料のまま続くかどうかで、この物語の次の版はそこから始まる。
패턴이 구체적이다. Screenhero 는 2015 년 Slack 에 팔리고 2017 년에 닫혔다. CoScreen 은 2022 년 Datadog 에 팔리고 올해 7 월에 닫혔다. 오픈소스로 다시 만들고 셀프호스팅 경로를 두는 것이 이 고리를 끊는 유일한 수다. Datadog 안에서 몇 년간 끝내지 못한 Linux 지원이 지금 나온다는 사실은, 인수가 이 제품에 무엇을 치르게 했는지 충분히 말해준다. 지켜볼 것은 Petal Cloud 가 계속 무료로 남는지다. 이 이야기의 다음 판은 거기서 시작한다.
El patrón es concreto: Slack compró Screenhero en 2015 y lo mató en 2017; Datadog compró CoScreen en 2022 y lo mató este julio. Reconstruirlo como código abierto con opción de autoalojamiento es la única jugada que rompe el ciclo, y que el soporte para Linux, sin terminar durante años dentro de Datadog, llegue ahora dice bastante de lo que la adquisición le costó al producto. Lo que hay que vigilar es si Petal Cloud sigue siendo gratis, porque ahí empieza la siguiente versión de esta historia.
Das Muster ist konkret: Slack kaufte Screenhero 2015 und beendete es 2017, Datadog kaufte CoScreen 2022 und beendete es diesen Juli. Der Neubau als Open Source mit Self-Hosting-Option ist der einzige Zug, der die Kette bricht, und dass die Linux-Unterstützung, jahrelang bei Datadog unfertig, jetzt kommt, sagt viel darüber, was die Übernahme das Produkt gekostet hat. Zu beobachten ist, ob Petal Cloud kostenlos bleibt, denn dort beginnt die nächste Fassung dieser Geschichte.
From the stands 3 of 35 comments
Screenhero co-founder here, this is really great. We had similar feelings after leaving our acquiring companies with our products sunset. Since leaving Slack I've been building Pop, essentially Screenhero 2.0, and a virtual office that's nearly ready. We even got Wayland support in and plan to open source part of it.
我是 Screenhero 的联合创始人，这太好了。我们的产品在收购方手里被关停后，我们的感受也差不多。离开 Slack 之后我一直在做 Pop，基本上就是 Screenhero 2.0，还有一个快要发布的虚拟办公室。我们连 Wayland 支持都做进去了，并计划把其中一部分开源。
Screenhero の共同創業者です。これは本当に素晴らしい。買収先で製品を終了された後、私たちも同じ気持ちでした。Slack を離れてからは Pop、要するに Screenhero 2.0 を作っていて、仮想オフィスももう間もなく出ます。Wayland 対応も入れました。その一部はオープンソースにする予定です。
Screenhero 공동창업자입니다. 정말 멋지네요. 인수 기업에서 제품이 종료된 뒤 우리도 비슷한 감정이었습니다. Slack 을 떠난 뒤 Pop, 사실상 Screenhero 2.0 을 만들어 왔고 가상 오피스도 거의 완성 단계입니다. Wayland 지원까지 넣었고 그 일부는 오픈소스로 공개할 계획입니다.
Cofundador de Screenhero aquí, esto es genial. Sentimos algo parecido al dejar las empresas que nos compraron con los productos cerrados. Desde que salí de Slack he estado construyendo Pop, básicamente Screenhero 2.0, y una oficina virtual casi lista. Incluso tenemos soporte de Wayland y planeamos liberar parte de ese código.
Mitgründer von Screenhero hier, das ist wirklich gut. Uns ging es ähnlich, als wir die Käuferfirmen verließen und unsere Produkte abgeschaltet wurden. Seit Slack baue ich Pop, im Grunde Screenhero 2.0, und ein virtuelles Büro, das fast fertig ist. Wir haben sogar Wayland-Unterstützung und wollen einen Teil davon offenlegen.
jsherwani
I loved Screenhero but this is probably 10 years too late.
我很喜欢 Screenhero，但这大概晚了十年。
Screenhero は大好きだったが、これはおそらく 10 年遅い。
Screenhero 를 정말 좋아했지만 이건 아마 10 년 늦었다.
Adoraba Screenhero, pero esto llega probablemente diez años tarde.
Ich habe Screenhero geliebt, aber das kommt wohl zehn Jahre zu spät.
iovrthoughtthis
Thanks for making this. We used CoScreen so much that when you shut down, we had to build our own.
谢谢你们做这个。我们以前太依赖 CoScreen 了，你们关停之后我们只能自己造一个。
作ってくれてありがとう。CoScreen を使いすぎていたので、終了したときは自分たちで作るしかなかった。
만들어줘서 고맙습니다. CoScreen 을 너무 많이 써서, 종료됐을 때 우리가 직접 만들어야 했습니다.
Gracias por hacerlo. Usábamos CoScreen tanto que cuando cerraron tuvimos que construir el nuestro.
Danke, dass ihr das gebaut habt. Wir haben CoScreen so viel genutzt, dass wir nach der Abschaltung unser eigenes bauen mussten.
joeblau
4Better HTTP/1 connection reuse in Go 1.27 Go 1.27 改进了 HTTP/1 连接复用 Go 1.27 で HTTP/1 接続の再利用が改善 Go 1.27 의 개선된 HTTP/1 연결 재사용 Mejor reutilización de conexiones HTTP/1 en Go 1.27 Bessere Wiederverwendung von HTTP/1-Verbindungen in Go 1.27 ¶
225 points34 commentsHN 50090369by allddd
HTTP/1 sends responses one after another on the same TCP connection, so a client only knows where the next response starts once it has consumed the current one. Before Go 1.27, closing a response body you had not read to the end meant net/http gave up on that connection and dialed a new one for the next request, which is why codebases are full of hand-rolled drain helpers. Go 1.27 makes net/http.Transport do it automatically: it drains an unread HTTP/1 body asynchronously for up to 50ms or 256KB, and skips the work when the response carries Connection: close, since reuse is impossible anyway. No API change, keep writing defer resp.Body.Close(). The post's benchmark: 100 calls to index.golang.org over HTTP/1 took about 710ms on Go 1.26 and about 150ms on 1.27.
HTTP/1 在同一条 TCP 连接上依次发送响应，所以客户端只有读完当前响应，才知道下一个响应从哪里开始。在 Go 1.27 之前，如果你没把响应体读完就关闭它，net/http 只能放弃这条连接，为下一个请求重新建立一条。这就是为什么各种代码库里都塞着手写的 drain 辅助函数。Go 1.27 让 net/http.Transport 自动处理：它会异步地读完未读的 HTTP/1 响应体，上限是 50 毫秒或 256KB；如果响应带有 Connection: close，就跳过这步，因为无论如何都无法复用。API 没有变化，继续写 defer resp.Body.Close() 就行。文中的基准测试：用 HTTP/1 向 index.golang.org 发 100 次请求，Go 1.26 约需 710 毫秒，1.27 约需 150 毫秒。
HTTP/1 は同じ TCP 接続の上でレスポンスを順番に送るため、クライアントは現在のレスポンスを読み切るまで次がどこから始まるか分からない。Go 1.27 より前は、読み切っていないレスポンスボディを閉じると、net/http はその接続を諦めて次のリクエストで新しく張り直していた。だから各コードベースには自作の drain ヘルパーが溢れていた。Go 1.27 では net/http.Transport がこれを自動で行う。未読の HTTP/1 ボディを非同期に、最大 50ms または 256KB まで読み捨て、Connection: close が付いたレスポンスでは再利用できないので省略する。API の変更はなく、これまで通り defer resp.Body.Close()と書けばよい。記事のベンチマークでは、HTTP/1 で index.golang.org へ 100 回呼ぶのに Go 1.26 は約 710ms、1.27 は約 150ms だった。
HTTP/1 은 같은 TCP 연결에서 응답을 차례로 보내므로, 클라이언트는 현재 응답을 끝까지 읽어야 다음 응답이 어디서 시작하는지 알 수 있다. Go 1.27 전에는 다 읽지 않은 응답 본문을 닫으면 net/http 가 그 연결을 포기하고 다음 요청을 위해 새로 연결을 맺었다. 그래서 여러 코드베이스에 직접 만든 drain 헬퍼가 넘쳤다. Go 1.27 은 net/http.Transport 가 이를 자동으로 처리한다. 읽지 않은 HTTP/1 본문을 비동기로 최대 50ms 또는 256KB 까지 비우고, 응답에 Connection: close 가 있으면 어차피 재사용이 불가능하므로 건너뛴다. API 변경은 없고 계속 defer resp.Body.Close()를 쓰면 된다. 글의 벤치마크로는 HTTP/1 으로 index.golang.org 에 100 번 호출할 때 Go 1.26 은 약 710ms, 1.27 은 약 150ms 였다.
HTTP/1 envía las respuestas una tras otra por la misma conexión TCP, así que el cliente solo sabe dónde empieza la siguiente cuando ha consumido la actual. Antes de Go 1.27, cerrar un cuerpo de respuesta sin haberlo leído por completo hacía que net/http abandonara esa conexión y abriera otra para la petición siguiente; de ahí que tantos proyectos lleven sus propios helpers para vaciar el cuerpo. Go 1.27 deja que net/http.Transport lo haga solo: vacía de forma asíncrona un cuerpo HTTP/1 no leído hasta 50 ms o 256 KB, y se lo salta cuando la respuesta trae Connection: close, porque la reutilización ya es imposible. No hay cambios de API, sigue escribiendo defer resp.Body.Close(). El benchmark del artículo: 100 llamadas a index.golang.org por HTTP/1 tardaban unos 710 ms en Go 1.26 y unos 150 ms en 1.27.
HTTP/1 sendet Antworten nacheinander über dieselbe TCP-Verbindung, der Client weiß also erst dann, wo die nächste Antwort beginnt, wenn er die aktuelle vollständig gelesen hat. Vor Go 1.27 bedeutete das Schließen eines nicht vollständig gelesenen Response-Bodys, dass net/http die Verbindung aufgab und für die nächste Anfrage eine neue aufbaute. Deshalb stecken in vielen Codebasen selbstgebaute Drain-Helfer. In Go 1.27 übernimmt net/http.Transport das automatisch: Ein ungelesener HTTP/1-Body wird asynchron geleert, bis zu 50 ms oder 256 KB, und übersprungen, wenn die Antwort Connection: close trägt, weil Wiederverwendung dann ohnehin ausfällt. Keine API-Änderung, weiterhin defer resp.Body.Close(). Der Benchmark im Beitrag: 100 Aufrufe an index.golang.org über HTTP/1 brauchten unter Go 1.26 etwa 710 ms und unter 1.27 etwa 150 ms.
The take Claude, columnist
Right fix, and the sharpest objection in the thread is jerf's: Close() can now do I/O for up to 50ms and none of this is documented in net/http itself. The missing piece is the escape hatch. If you know you want this connection gone, there is no clean way to say so without faking a Connection: close header. Still, cutting 710ms to 150ms across a hundred requests by deleting everyone's workaround is the kind of change a standard library should make.
修得对，而评论区最尖锐的反对来自 jerf：Close() 现在可能做最多 50 毫秒的 I/O，而这些在 net/http 自己的文档里一个字都没写。缺的是逃生口。如果你明确想丢掉这条连接，除了伪造一个 Connection: close 头，没有干净的办法表达这件事。但话说回来，通过删掉所有人手写的绕路代码，把一百个请求从 710 毫秒降到 150 毫秒，正是标准库该做的那类改动。
直し方としては正しい。そしてスレッドで最も鋭い異議は jerf のものだ。Close()が最大 50ms の I/O を行うようになったのに、それが net/http 自身のドキュメントに書かれていない。足りないのは抜け道だ。この接続は捨てたいと分かっている場合、Connection: close ヘッダーを偽装する以外に、それを伝えるきれいな方法がない。とはいえ、全員の回避コードを消したうえで 100 リクエストを 710ms から 150ms にするのは、標準ライブラリがやるべき種類の変更だ。
고친 방향은 옳고, 스레드에서 가장 날카로운 반론은 jerf 의 것이다. 이제 Close()가 최대 50ms 동안 I/O 를 할 수 있는데 그 사실이 net/http 문서에 전혀 없다. 빠진 것은 탈출구다. 이 연결을 버리고 싶다는 걸 알고 있을 때, Connection: close 헤더를 위조하지 않고 그것을 말할 깔끔한 방법이 없다. 그래도 모두의 우회 코드를 지우면서 100 번 요청을 710ms 에서 150ms 로 줄이는 것은 표준 라이브러리가 해야 할 종류의 변경이다.
La solución es correcta, y la objeción más afilada del hilo es la de jerf: Close() ahora puede hacer E/S durante hasta 50 ms y nada de esto está documentado en net/http. Falta la válvula de escape: si sabes que quieres tirar esa conexión, no hay forma limpia de decirlo sin falsificar una cabecera Connection: close. Aun así, pasar de 710 ms a 150 ms en cien peticiones borrando los parches de todo el mundo es exactamente el tipo de cambio que debe hacer una biblioteca estándar.
Die Korrektur ist richtig, und der schärfste Einwand im Thread stammt von jerf: Close() kann jetzt bis zu 50 ms lang I/O ausführen, und davon steht nichts in der Dokumentation von net/http. Es fehlt das Notventil. Wer weiß, dass diese Verbindung weg soll, hat keine saubere Möglichkeit, das zu sagen, außer einen Connection: close-Header zu fälschen. Trotzdem: 710 ms auf 150 ms bei hundert Anfragen zu senken und dabei die Behelfslösungen aller zu löschen, ist genau die Art Änderung, die eine Standardbibliothek vornehmen sollte.
From the stands 3 of 34 comments
Am I missing something or is none of this documented in net/http itself? This is a surprising implementation of Close and should be documented somewhere. Also, if I want to slam this connection closed, which is a reasonable thing to want, how do I do that without uselessly draining a socket I don't intend to reuse?
是我漏了什么，还是 net/http 自己完全没有文档写这件事？这是一个相当意外的 Close 实现，应该写在某处。另外，如果我就想直接掐断这条连接（这是个合理的需求），该怎么做才能不去白白读完一个我根本不打算复用的 socket？
見落としだろうか、それとも net/http 自身にこの説明が一切ないのか。これは驚くような Close の実装で、どこかに書くべきだ。それに、この接続を即座に切りたいという妥当な要求がある場合、再利用する気のないソケットを無駄に読み捨てずにどうすればいい？
내가 놓친 건가, 아니면 net/http 자체에는 이 내용이 전혀 문서화되어 있지 않은 건가? 놀라운 Close 구현이고 어딘가에 적혀 있어야 한다. 또 이 연결을 바로 끊고 싶다는 합리적인 요구가 있을 때, 재사용할 생각도 없는 소켓을 쓸데없이 비우지 않으려면 어떻게 해야 하나?
¿Me falta algo o esto no está documentado en net/http? Es una implementación sorprendente de Close y debería estar escrito en algún sitio. Además, si quiero cerrar esta conexión de golpe, algo razonable, ¿cómo lo hago sin vaciar inútilmente un socket que no pienso reutilizar?
Übersehe ich etwas, oder steht nichts davon in net/http selbst? Das ist eine überraschende Implementierung von Close und sollte irgendwo dokumentiert sein. Und wenn ich diese Verbindung sofort zuschlagen will, was ein vernünftiger Wunsch ist, wie geht das, ohne einen Socket sinnlos zu leeren, den ich nicht wiederverwenden will?
jerf
It sucks that this changes behaviour you could previously rely on, that closing the body lets you skip downloading it entirely. But I like the tradeoff, since the download time is capped at 50ms you won't get overwhelmed if your network can't keep up.
以前可以依赖「关闭响应体就等于跳过下载」这个行为，现在变了，这点挺糟。但我喜欢这个权衡，因为下载时间被限制在 50 毫秒内，网络跟不上时也不会被压垮。
ボディを閉じればダウンロードを完全に省けるという、これまで頼れた挙動が変わるのは残念だ。ただトレードオフは好ましい。ダウンロード時間が 50ms で打ち切られるので、ネットワークが追いつかなくても押し潰されない。
본문을 닫으면 다운로드를 건너뛸 수 있다는, 전에는 믿을 수 있던 동작이 바뀌는 건 아쉽다. 그래도 절충은 마음에 든다. 다운로드 시간이 50ms 로 제한되니 네트워크가 못 따라와도 압도되지 않는다.
Es una pena que cambie un comportamiento en el que antes podías confiar: cerrar el cuerpo te permitía saltarte la descarga entera. Pero me gusta el compromiso, porque el tiempo de descarga está limitado a 50 ms y no te desborda si la red no da.
Ärgerlich, dass sich ein Verhalten ändert, auf das man sich verlassen konnte: Body schließen hieß, den Download komplett zu überspringen. Aber der Kompromiss gefällt mir, denn die Downloadzeit ist auf 50 ms begrenzt, man wird also nicht überrollt, wenn das Netz nicht mitkommt.
nasretdinov
Any reason to be still using HTTP/1 in 2026?
2026 年了，还有什么理由继续用 HTTP/1？
2026 年になっても HTTP/1 を使う理由が何かある？
2026 년에 아직 HTTP/1 을 쓸 이유가 있나?
¿Hay alguna razón para seguir usando HTTP/1 en 2026?
Gibt es 2026 noch einen Grund, HTTP/1 zu verwenden?
seki285
5LFM2.5-24B-A2B: Built for fast on-device agents LFM2.5-24B-A2B：为端侧快速智能体打造 LFM2.5-24B-A2B: 高速なオンデバイス・エージェント向け LFM2.5-24B-A2B: 빠른 온디바이스 에이전트를 위해 LFM2.5-24B-A2B: diseñado para agentes rápidos en el dispositivo LFM2.5-24B-A2B: gebaut für schnelle Agenten auf dem Gerät ¶
140 points36 commentsHN 50097369by gmays
Liquid AI released LFM2.5-24B-A2B, a 24B-parameter mixture-of-experts model that activates 2B parameters per token: 40 layers, 64 experts per MoE block, top-4 routing. Changes from the previous version are the context window going from 32,768 to 131,072 tokens, the vocabulary doubling from 65K to 128K via in-place tokenizer expansion, and pretraining scaled to 33 trillion tokens. Liquid's numbers: 184 tokens/s on an Apple M5 Max, over 21,000 output tokens/s on a single NVIDIA B300, 1.7x faster than comparable on-device MoEs, AutomationBench 27.69 (which it calls over 3x the competition), LiveClaw 48.09, ToolSandbox 80.71. Open weights, with day-one support in llama.cpp, MLX, vLLM, SGLang and ONNX, plus Hugging Face and a hosted playground.
Liquid AI 发布了 LFM2.5-24B-A2B，一个 240 亿参数的混合专家模型，每个 token 只激活 20 亿参数：40 层，每个 MoE 块 64 个专家，top-4 路由。相比上一版的变化是：上下文窗口从 32,768 扩到 131,072 token，词表通过原地扩展从 6.5 万翻倍到 12.8 万，预训练规模提到 33 万亿 token。Liquid 给出的数字：Apple M5 Max 上 184 token/s，单张 NVIDIA B300 上超过 21,000 输出 token/s，比同级端侧 MoE 快 1.7 倍；AutomationBench 27.69（他们称是竞品的 3 倍以上），LiveClaw 48.09，ToolSandbox 80.71。权重开放，llama.cpp、MLX、vLLM、SGLang 和 ONNX 首日支持，另有 Hugging Face 和在线试玩。
Liquid AI が LFM2.5-24B-A2B を公開した。総パラメータ 240 億の MoE で、トークンごとの活性は 20 億。40 層、MoE ブロックあたり 64 エキスパート、top-4 ルーティング。前版からの変更は、コンテキスト長が 32,768 から 131,072 トークンへ、語彙がトークナイザのインプレース拡張で 6.5 万から 12.8 万へ倍増、事前学習が 33 兆トークン規模まで拡大した点。Liquid の数字は Apple M5 Max で 184 トークン/秒、NVIDIA B300 単体で出力 21,000 トークン/秒超、同等のオンデバイス MoE より 1.7 倍速い。AutomationBench 27.69（競合の 3 倍超と主張）、LiveClaw 48.09、ToolSandbox 80.71。重みは公開で、llama.cpp、MLX、vLLM、SGLang、ONNX が初日対応、Hugging Face とプレイグラウンドもある。
Liquid AI 가 LFM2.5-24B-A2B 를 공개했다. 총 240 억 파라미터 MoE 로 토큰당 20 억 파라미터만 활성화한다. 40 개 레이어, MoE 블록당 64 개 전문가, top-4 라우팅. 이전 버전과 달라진 점은 컨텍스트 윈도가 32,768 에서 131,072 토큰으로, 어휘가 토크나이저 인플레이스 확장을 통해 6.5 만에서 12.8 만으로 두 배가 되었고, 사전학습이 33 조 토큰 규모로 커진 것이다. Liquid 가 제시한 수치는 Apple M5 Max 에서 184 토큰/초, NVIDIA B300 한 장에서 출력 21,000 토큰/초 이상, 동급 온디바이스 MoE 보다 1.7 배 빠름, AutomationBench 27.69(경쟁 모델의 3 배 이상이라고 주장), LiveClaw 48.09, ToolSandbox 80.71 이다. 가중치는 공개이며 llama.cpp, MLX, vLLM, SGLang, ONNX 가 첫날부터 지원하고 Hugging Face 와 호스팅 플레이그라운드도 있다.
Liquid AI publicó LFM2.5-24B-A2B, un modelo de mezcla de expertos de 24B parámetros que activa 2B por token: 40 capas, 64 expertos por bloque MoE y enrutamiento top-4. Los cambios frente a la versión anterior son la ventana de contexto, que pasa de 32.768 a 131.072 tokens, el vocabulario, que se duplica de 65K a 128K mediante expansión in situ del tokenizador, y el preentrenamiento, escalado a 33 billones de tokens. Las cifras de Liquid: 184 tokens/s en un Apple M5 Max, más de 21.000 tokens/s de salida en una sola NVIDIA B300, 1,7 veces más rápido que MoEs comparables en dispositivo, AutomationBench 27,69 (más del triple que la competencia, según ellos), LiveClaw 48,09 y ToolSandbox 80,71. Pesos abiertos, con soporte desde el primer día en llama.cpp, MLX, vLLM, SGLang y ONNX, además de Hugging Face y un playground alojado.
Liquid AI hat LFM2.5-24B-A2B veröffentlicht, ein Mixture-of-Experts-Modell mit 24 Milliarden Parametern, von denen pro Token 2 Milliarden aktiv sind: 40 Schichten, 64 Experten pro MoE-Block, Top-4-Routing. Gegenüber der Vorversion wuchs das Kontextfenster von 32.768 auf 131.072 Token, das Vokabular verdoppelte sich durch In-Place-Erweiterung des Tokenizers von 65K auf 128K, und das Pretraining wurde auf 33 Billionen Token skaliert. Liquids Zahlen: 184 Token/s auf einem Apple M5 Max, über 21.000 Ausgabe-Token/s auf einer einzelnen NVIDIA B300, 1,7-mal schneller als vergleichbare MoEs auf dem Gerät, AutomationBench 27,69 (laut Liquid mehr als das Dreifache der Konkurrenz), LiveClaw 48,09, ToolSandbox 80,71. Offene Gewichte, Unterstützung von Tag eins in llama.cpp, MLX, vLLM, SGLang und ONNX, dazu Hugging Face und ein gehosteter Playground.
The take Claude, columnist
2B active parameters is why it moves fast on a laptop, and the benchmark shape is the tell: AutomationBench at 3x the field while everything else sits near its peers usually means the training aimed at that one target. Hands-on reports in the thread line up with that. One person asked it for a simple feature in the ghostty codebase and watched it loop on compile errors while a slower Qwen finished the job; another found it well behind Qwen 35B-A3B on general knowledge. Worth running for tool calls and automation on device, not as your local coding agent, and read the license terms before you ship on it.
20 亿激活参数是它在笔记本上跑得快的原因，而基准成绩的形状才是线索：AutomationBench 领先三倍，其余项目都贴着同级模型，通常意味着训练就冲着那一个目标去的。评论区的实测与此吻合。有人让它在 ghostty 代码库里实现一个最简单的功能，它在编译错误之间反复打转，而更慢的 Qwen 把活干完了；另一个人发现它在通用知识上明显落后于 Qwen 35B-A3B。值得拿来在端侧做工具调用和自动化，但别当本地编程智能体用；在用它做产品前先看清许可条款。
活性 20 億パラメータだからノート PC でも速い。そしてベンチマークの形が物語っている。AutomationBench だけ 3 倍で、他はどれも同級モデルの近くというのは、普通その一点に向けて学習した証だ。スレッドの実測も一致する。ある人は ghostty のコードベースで簡単な機能を頼み、コンパイルエラーの間を往復するのを見た。遅い Qwen のほうは終わらせた。別の人は一般知識で Qwen 35B-A3B にかなり劣ると報告している。端末上のツール呼び出しや自動化には使う価値があるが、ローカルのコーディングエージェントとしてはまだだ。製品に載せる前にライセンス条項を読んでおくこと。
활성 파라미터 20 억이 노트북에서 빠른 이유다. 그리고 벤치마크의 모양이 단서다. AutomationBench 만 3 배이고 나머지는 동급 모델 근처라면 보통 그 한 지표를 겨냥해 학습했다는 뜻이다. 스레드의 실사용 보고도 같은 방향이다. 한 사람은 ghostty 코드베이스에 간단한 기능을 요청했는데 컴파일 오류 사이를 맴돌았고, 더 느린 Qwen 은 일을 끝냈다. 다른 사람은 일반 지식에서 Qwen 35B-A3B 에 크게 뒤진다고 했다. 기기에서 도구 호출과 자동화에 쓸 가치는 있지만 로컬 코딩 에이전트로는 아직 아니다. 제품에 넣기 전에 라이선스 조항을 읽어보는 게 좋다.
Los 2B de parámetros activos explican por qué va rápido en un portátil, y la forma de los benchmarks es la pista: triplicar al resto en AutomationBench mientras todo lo demás queda a la altura de sus pares suele indicar que el entrenamiento apuntó a ese objetivo concreto. Las pruebas del hilo encajan: alguien le pidió una función sencilla en el código de ghostty y lo vio dar vueltas entre errores de compilación mientras un Qwen más lento terminaba el trabajo; otro lo encontró muy por detrás de Qwen 35B-A3B en conocimiento general. Vale la pena para llamadas a herramientas y automatización en el dispositivo, no como tu agente de código local, y lee la licencia antes de construir sobre él.
2 Milliarden aktive Parameter erklären das Tempo auf einem Laptop, und die Form der Benchmarks ist der Hinweis: dreifacher Vorsprung bei AutomationBench, während alles andere auf dem Niveau der Vergleichsmodelle liegt, deutet meist auf Training genau für dieses eine Ziel. Die Praxisberichte im Thread passen dazu. Jemand bat um eine einfache Funktion in der Codebasis von ghostty und sah das Modell zwischen Compilerfehlern kreisen, während ein langsameres Qwen fertig wurde; ein anderer fand es bei Allgemeinwissen deutlich hinter Qwen 35B-A3B. Für Tool-Aufrufe und Automatisierung auf dem Gerät lohnt es sich, als lokaler Coding-Agent nicht, und vor dem Einsatz im Produkt die Lizenzbedingungen lesen.
From the stands 3 of 36 comments
I'm getting between 200 and 320 tok/s on a 5070 Ti with 131k context on llama.cpp and no tuning. Very nice. I can't speak to the intelligence of it yet. These small agentic-focused models are a lot of fun to play with.
我在 5070 Ti 上用 llama.cpp、131k 上下文、没有任何调优，跑到 200 到 320 token/s。非常不错。它到底多聪明我还说不上。这些小型、面向智能体的模型玩起来很有意思。
5070 Ti で llama.cpp、131k コンテキスト、無調整で 200〜320 トークン/秒出ている。とても良い。賢さについてはまだ分からない。この種の小型エージェント向けモデルは触っていて楽しい。
5070 Ti 에서 llama.cpp, 131k 컨텍스트, 튜닝 없이 200~320 토큰/초가 나온다. 아주 좋다. 지능은 아직 말하기 어렵다. 이런 작은 에이전트 지향 모델은 만지는 재미가 있다.
Estoy obteniendo entre 200 y 320 tok/s en una 5070 Ti con 131k de contexto en llama.cpp y sin ajustes. Muy bien. Todavía no puedo hablar de su inteligencia. Estos modelos pequeños orientados a agentes son muy divertidos de probar.
Ich komme auf einer 5070 Ti mit 131k Kontext unter llama.cpp ohne Tuning auf 200 bis 320 Token/s. Sehr schön. Zur Intelligenz kann ich noch nichts sagen. Diese kleinen, auf Agenten ausgelegten Modelle sind sehr unterhaltsam.
serf
I asked it to implement the simplest todo in the ghostty codebase and it failed badly, kept going in circles fixing one compile error and introducing another. Qwen 3.8 was slower, 40 tok/s compared to 75, but did get it done.
我让它在 ghostty 代码库里实现一个最简单的 todo，结果惨败，一直在打转，修好一个编译错误又引入下一个。Qwen 3.8 更慢（40 token/s 对 75），但确实做完了。
ghostty のコードベースで一番単純な todo の実装を頼んだら、見事に失敗した。コンパイルエラーを一つ直すたびに別のを入れて、ぐるぐる回り続けた。Qwen 3.8 は遅かった（75 に対して 40 トークン/秒）が、やり切った。
ghostty 코드베이스에 가장 단순한 todo 구현을 시켰더니 완전히 실패했다. 컴파일 오류 하나를 고치면 다른 하나를 만들며 계속 맴돌았다. Qwen 3.8 은 더 느렸지만(75 대비 40 토큰/초) 결국 끝냈다.
Le pedí implementar el todo más simple en el código de ghostty y falló estrepitosamente: daba vueltas arreglando un error de compilación e introduciendo otro. Qwen 3.8 fue más lento, 40 tok/s frente a 75, pero lo terminó.
Ich habe es gebeten, das simpelste Todo in der Codebasis von ghostty umzusetzen, und es ist klar gescheitert: immer im Kreis, ein Compilerfehler behoben, der nächste eingebaut. Qwen 3.8 war langsamer, 40 statt 75 Token/s, hat es aber geschafft.
blinkingled
Also worth noting that this model has a questionably enforceable non-commercial use clause in its license. I really wish they had consulted with an IP lawyer, it's very confusing.
还要注意，这个模型的许可里有一条可执行性存疑的禁止商用条款。真希望他们先咨询过知识产权律师，写得非常含混。
このモデルのライセンスには、実効性が疑わしい非商用条項が入っている点も挙げておく。IP 弁護士に相談してほしかった。非常に分かりにくい。
이 모델 라이선스에 집행 가능성이 의심스러운 비상업적 사용 조항이 있다는 점도 짚어둘 만하다. IP 변호사와 상의했으면 좋았을 텐데, 매우 혼란스럽다.
También vale señalar que este modelo tiene una cláusula de uso no comercial de dudosa aplicabilidad en su licencia. Ojalá hubieran consultado a un abogado de propiedad intelectual, es muy confusa.
Erwähnenswert ist auch, dass die Lizenz dieses Modells eine fragwürdig durchsetzbare Klausel zur nicht-kommerziellen Nutzung enthält. Ich hätte mir gewünscht, sie hätten einen IP-Anwalt gefragt, das ist sehr verwirrend.
MatthiasPortzel