I am loving Buzz. Made a team of 6 agents - assistant (terra-high) - builder (sol-med) - designer (opus-5) - planner (opus-5/sol-high) - architect (fable-5) - debugger (sol-high) Seems like this may become my default work environment going ahead. Still testing. https://t.co/U0UPKOJbQt

Published and tested vLLM 0.25.1 compatibility overlay and TP=2 reference deployment for DeepSeek V4 Flash plus DSpark/NVFP4 on 2× NVIDIA DGX Spark / ASUS GX10 systems. Includes integration fixes, a live dashboard, deployment tooling and reproducible benchmarks. This integration builds on work from @vllm_project, FlashInfer, Luke Alonso/b12x, @MiaAI_lab, @rafaelcaricio, Keys/drowzeys, @2WildTech and many other contributors. https://t.co/l5U6vK7GMh Benchmarks 👇

Learn 99% of ChatGPT Work in 61 minutes: GPT Work is like Codex in the cloud. It works on phone, web, and desktop. And I've been using it to run my business. These are the 14 knowledge work capabilities. 00:00 Intro 03:18 #1 Presentations 09:16 #2 Plugins 17:36 #3 Blocks 23:34 #4 Websites & Apps & Hosting 30:09 #6 Branching Chats 31:51 #7 Desktop App (Cloud vs Local) 37:01 #8 Voice Mode 41:36 #9 Remote Voice Mode 45:52 #10 In-App Browser 48:50 #11 Skills 51:45 #12 Scheduled Automations 54:37 #13 Spreadsheets 56:58 #14 Multi-Agent Workspace 59:19 Final Review

my favorite way to explain people herdr is to just open a new workspace, launch an agent and tell it to: read `herdr --skill` then split 10 other panels that make my computer look like some scifi hacker terminal from the movies https://t.co/b6m6RzCO6W

我把我用 AI 视频做动画的 Skill 开源啦：https://t.co/RQwQEgDTDA 整个 Skill 的流程大概是这样的： 参考素材、表达目的和控制方式 ↓ 先确认开始、中间和结束时应该是什么样子 ↓ 使用 AI 视频生成这些画面之间的连续动作 ↓ 逐帧检查，删除停顿、重复和异常画面 ↓ 按照页面中的实际显示大小整理并压缩资源 ↓ 把滚动、鼠标、拖动、触摸或设备方向对应到动画进度 因为整个流程还是有点复杂的，所以我把我实际做的时候的一些实现做成脚本放进去了，这样生成后处理动画会更加稳定一些，而且我还补充了一些创意方面的参考文档，比如说大家能够在视频里面看到的那个苹果的滚动爆炸图的效果。 欢迎大家体验～

@Simeon_Cps I disagree with this framing. The incident wasn't a 3-month long undetected attack, we actually responded twice, and we are very transparent about security issues. You can critique me for many reasons - but not caring about security, or transparency, ain't on the list.

What are reverse proxy phishing kits?

One reason why we’re going to get uneven diffusion rates of agents is because different workflows in the enterprise are more or less aligned to continuous, uninterrupted computer work. A big reason why agentic coding growth has gone completely vertical is because it’s a type of work where economic value is directly correlated with the output of solely digital information, and where the task size can in theory be unbounded in a single session. This means that as AI agents can do larger amounts of work at a time, and as model capability improves on this task type, they can directly be deployed at larger workloads near instantaneously. Lots of work doesn’t natively have this property in how today’s workflows are designed. A sales rep needs a feedback loop with the customer before they can do additional work for a specific account, a lawyer needs to talk to the client, and a doctor needs to interact with a patient. So large agentic work will likely not look the same as it has in coding, at least by default. Instead, in many of these domains, the agents will actually need to tie into a workflow that is reengineered for AI. Matan Grinberg at Factory had a good way of thinking about this on the Training Data podcast: if everyone called in sick tomorrow, token usage would plummet because no one would be there to prompt them. This shows how early we are in agents running in the background for most processes; whereas this should be the majority of volume of agentic work in the future. In legal, it will be about processing every contract that comes in, in sales it will be agents that roam through customer records and figure out signals of when to better do outreach, in life sciences research it will be about swarms of agents reading through every test or all research. To do that these business processes have to be wired up to support agents, as opposed to the vast amounts of manual work that we do today. This is the big opportunity right now, but it’s going to diffuse differently from something like agentic coding. Lots of change management, lots of data cleanup, lots of workflow reengineering, and more.

ok, apologies in advance because i do so hate to provide actual signal. openai basically sucked at pre-training for a while and crushed at post. their answer to this was spud. spud was the large new pre-train for the new family of models: sol, terra, and luna. the upcoming model, ‘astra’, has an even bigger pre-train, codenamed ‘doug’. (this was a running joke, as doug was the name for the world’s largest spud, although that’s not technically accurate — look it up). still with me? ok good, so sol is a 5t model based on the spud pre-train. astra is a 10t model based on the doug pre-train. this is the model i’ve discussed that openai researchers have been considerably more excited for. not only does it crush fable on all benchmarks, it’s genuinely delightful to talk to, high eq (4.5 vibes), and this is the first model that is genuinely incredible at writing, with output indistinguishable from that of great human writers. ok im tired and i have a lot of ssi news coming but ill keep you updated on this. everything here is well sourced and im highly confident. very well sourced.

Easy SEO win: - go to google search console -> performance - set date to 12mo -> export - upload Pages.csv and Queries.csv to any AI tool Tell it to find queries you rank for but don't have content for. Go write the content and you will rank quick

@elonmusk Bandwidth is half of it. Most congestion control still assumes a stable path and a stable RTT. LEO is neither. Area needs innovation all the way down the stack. @Cloudflare and @Starlink should be building that together.

how our read tool saves billions of tokens vs claude code command code is purpose-built for open models, so we optimize things other coding agents get to ignore. for the v1 release i rebuilt the read tool from scratch. it's now one of the most complicated, carefully engineered pieces of the system, and it saves billions of tokens a month. here's what we learned. context: we wanted the `read_file` in command code to be the best among coding agents, then benchmarked it capability-by-capability against the nine other common harnesses: claude code, opencode, cline, kilo, codex, grok, hermes, pi, openclaw. most were open-source; claude code ships none, so its column came from feeding the live tool crafted files and watching what came back. count the reads in any agent session. every edit starts with a read. every grep hit becomes a read. a plan step opens 3 files. a few hundred reads per session, ~50 million a month across command code. you've seen the failure modes. it reads a file, learns nothing, reads it again. it reads a 5MB lockfile straight into context. it reads a minified bundle once and that junk sits in the window for every turn after. napkin math: ``` 500 junk tokens × 50M reads/month ───────── 25B junk tokens × every turn they stay in context ``` i think the `read_file` tool is like a compiler that turns your filesystem into the model's context. every decision inside it is a token budget decision multiplied by fifty million times it's used every month. and that's why coding agents feel expensive: the bill is mostly reads building context. what "saves billions of tokens" means here: cost per successful read. claude code's read tool succeeds by spending more: more tokens per call, more turns per miss, and a model smart enough to fish the signal out of the noise. ours had to succeed by spending less, because our models can't peek over a sloppy read and our users care about the token bill. ask claude code to read a 3,000-line file and it hands the model all 3,000 lines. ask it for a file with a 3,900-character minified line and it hands over the whole line. no window, no byte ceiling, no per-line clamp. i ran the probe twice because i didn't believe it the first time. everybody ships a read tool in week one. readFile, slice by offset, return the string. first tool you write, last one you think about. ours ended up as dozens of modules with 98 tests, and it was the highest-leverage thing in v1. a naive read and a harness engineered read are both "correct". they both work. the difference is that one of them quietly spends a fifth of your context window on bytes the model never needed, and occasionally deadlocks against your own write tool. a few things i learned worth sharing: 1/ you need three ceilings, not one, and it's always the third one people skip. every codebase keeps a small zoo of hostile files: the 80,000-line lockfile, the minified bundle that's technically one line, the log that never stops growing. each ceiling handles one animal file if you will. ``` 2,000 lines longfiles 128 KB logs 2,000 ch/line bundles ``` the line window bounds an ordinary large file. the byte budget bounds a file whose lines are wide rather than many. the per-line clamp catches the case the other two miss: one minified line that sits comfortably inside the 2,000-line window and, on its own, eats the entire byte budget. you get back a single unusable mega-string that displaced everything the model actually needed to see. drop any one ceiling and there's a shape of file that costs you the whole read. no log will ever show it, just a turn where the model got nothing and paid full price for it. 2/ the most expensive thing a tool can return is silence. the costliest failure is an ambiguous non-answer. an empty result string is indistinguishable, from inside the model, from a broken tool. so it re-reads. widens the window. tries a different path. burns three turns learning what one sentence notice could have told it. so every dead end names its own recovery: ``` empty → "is empty" past EOF → "retry smaller" byte cap → "offset=1847" line cap → "offset=2001" pdf → "pdftotext" ``` two details carry most of the value here. the resume offsets are precomputed, so the model never does pagination arithmetic (which it does in reasoning tokens you pay for, and gets wrong often enough to cost another round trip). and none of these carry an `Error:` prefix, so the tui doesn't paint them red and the model doesn't treat a fact about the world as a failure worth apologizing for. (the byte-truncated case deliberately resumes ON the last line shown rather than the line after it, because that line got cut mid-content. an off-by-one in a resume hint is a silently corrupted read, which is the one bug class here that's worse than a wasted turn.) 3/ the bug that taught us the most was relational, and no input validation could ever have caught it. `read_file` records what the model has SEEN of each file into a ledger: the content, the mtime at read time, and a flag for whether the view was partial. `write_file` consults it and refuses to overwrite a file you've only partly seen, because you'd silently destroy the part it never saw. now compose that with the per-line clamp: ``` read ↓ one clamped line ↓ ledger says partial ↓ write DENIED ↓ model re-reads ↓ dedup returns "unchanged" ↺ forever ``` we hit it in the wild, on plan files during plan reviews and refinement. every field in every call was valid. the invariant that broke lived in the relationship between three tools that never call each other. shape invariants are checkable per field, and every schema you write already checks them. relational invariants across stateful tools are where the real bugs live, and you only find them by watching production traffic. 4/ a cache whose stale hit is catastrophic should expire itself on use. re-reading the same window of an unchanged file is pure waste: the content is already sitting in the conversation. so we return a short stub. fires only when mtime, size, and the exact (offset, limit) window all match. but that stub points at an earlier tool result. what if compaction ate it? now the model has been told to refer to something it can no longer see. forever. ``` read → content read → stub (eaten) read → content again ``` a dedup hit consumes its record. worst case is one wasted turn instead of an unbounded loop. cheap miss, catastrophic stale hit → self-expiring cache. that shape shows up all over a harness once you look for it. i settled with this design as it was a good enough tradeoff between complexity and risk, and it was the only one that did well in our benchmark. 5/ filenames are adversarial and the model can't see why. macos names screenshots with a NARROW NO-BREAK SPACE before AM/PM. it stores filenames NFD-decomposed. finder renames turn `'` into `’`. ``` "Screenshot 3.04 PM.png" "Screenshot 3.04 PM.png" ``` different byte strings. in a terminal, the same picture. the model reads the path off the screen, retypes it faithfully, gets "file not found", and no amount of reasoning recovers because the difference isn't rendered. you can burn an entire session on this and never learn anything. so before failing we retry 7 candidate spellings: narrow space ↔ regular, NFD, NFC, straight ↔ curly quote, NFD+curly. each one re-checked against the workspace boundary, because a repair must never quietly become an escape hatch. then, and only then, "did you mean?": substring match plus a bounded levenshtein of 2, which is what catches `AGENT.md` → `AGENTS.md` where substring matching finds nothing. these are the most common super cheap open model problems we now repair saving more tokens than silly token compression tricks. when a failure is invisible to the model, retrying is the tool's job. the model would retry the same wrong bytes forever. this is what harness engineering is about: finding the invisible failure modes and fixing them in the tool so the model can focus on reasoning. 6/ my favourite bug lives at a chunk boundary. reads stream chunk by chunk instead of loading the file, so a 400MB line sitting BEFORE your window never accumulates. fine. but it turns out that if the line limit is hit EXACTLY at a chunk boundary, you're standing in a spot where the answer to "is there more file?" doesn't exist yet. ``` limit hit at chunk end ↓ more bytes? → partial stream end? → complete ``` saying "more of the file remains" at that moment is a lie roughly half the time, and it's a lie that costs a turn every time it fires. so defer the decision to the next chunk instead of guessing. when you can't know yet, say nothing yet. (also: don't `break` out of the for-await. it calls the iterator's `return()` and destroys the stream underneath you.) 7/ images attach for real. ``` 4K screenshot ↓ jpeg ladder 95→80→60→40→20 ↓ attach at first fit ``` vision models get the actual image, compressed down a jpeg quality ladder (95 → 80 → 60 → 40 → 20). a 4K screenshot degrades instead of failing to attach. format detection sniffs magic bytes, never the extension: garbage in a .png must never reach the api, real webp must pass. we also gave vision to non-vision models using a VISION tool. so fun. 8/ downscaled images disclose their scale factor. ``` on disk 3024x1964 attached 1092x709 ↓ "multiply displayed coords by 2.77" ``` without that line, every click coordinate computed off a screenshot is confidently wrong. nothing in the image says it was resized on the way in. and at the end of the day you're saving tokens costs. 9/ notebooks render as documents. ``` .ipynb json soup ↓ tagged cells plots → real images 10K+ cell → jq hint ``` raw .ipynb is json soup: base64 blobs, per-character source arrays. we return tagged cells, plots attached as images. any cell output over 10,000 chars becomes a jq pointer, so one dataframe dump can't eat the read budget. if you do a lot of data work in notebooks, you can now read the notebook without reading the entire dataframe. the model can still reason about the data, but it doesn't have to pay for it in tokens. major time savings for the user, and a major token savings for the model. 10/ boring formats get one-line answers. ``` .svg → text (xml) binary → mime note .pdf → pdftotext hint ``` svg is text (it's xml, the model can edit it). binary returns its mime type, never garbage bytes. pdf gets a pdftotext hint for now; inline is on the list. and we have a tools to read and parse different formats as needed loaded on demand. the model can reason about the file without reading it all, and the user doesn't pay for it in tokens. 11/ numbering matches cat -n. ``` model → line 412 editor → line 412 trace → line 412 ``` 1-indexed, prefix on every line. the model, your editor, and your stack traces agree on what "line 412" means. every resume offset and edit target depends on that. 12/ repair inputs, don't bounce them. ``` filePath → file_path "2000" → 2000 "2abc" → rejected 1.5 → rejected ``` 10 aliases for file_path (filePath, absolutePath, target_file...) get repaired. numeric strings coerce via Number(), never parseInt: "2abc" is rejected, never silently read as 2. fractional offsets are rejected, never floored. a silently wrong window is worse than an error. our repair harness engineering shows up every where. 13/ some paths must never be opened. ``` /dev/zero refused /dev/urandom refused /proc/N/fd/0 refused ↑ before any i/o ``` /dev/zero, /dev/urandom, /dev/stdin, /proc/<pid>/fd/* are refused by name before any i/o. no extension to check, and the workspace boundary won't save you when cwd is /. a read tool that hangs on /dev/zero is a denial of service you shipped yourself. 14/ hygiene you only notice when it bites. ``` BOM stripped CRLF → LF utf-8 never split dedup kill-switch ``` bom stripped. crlf normalized. byte-cap truncation binary-searches a utf-8 prefix so it never splits a codepoint. the dedup ships with a kill-switch env var, because every cache needs one. so where does everyone else land? the top of the table is basically solved. eight of ten harnesses have a line window (500 to 2,000) and a second ceiling (25K tokens to 128 KB). that part is common knowledge now. the bottom of the table is empty almost everywhere. across all ten: ``` deferred chunk cut 1/10 unicode name retry 1/10 device blocklist 1/10 EOF note not error 1/10 coord scale note 3/10 did-you-mean 2/10 partial-view ledger 2/10 ``` the pattern: none of those rows show up in a demo. every one of them starts costing you in hour nine of a long session (remembering what the model has already seen, giving it a way back when a read misses, refusing to read /dev/zero). teams build them only after production forces it. no one nowadays is sitting watching their agents run and fixing the coding agent's bad behaviors. most developers just select a harness on some random vibe in the first week and never look back. this harness is minimal, it must be the best, this harness is from the model maker, this must be the best. wrong! 🤦‍♂️ … whatever happened to the engineer in us? I hope this post helps you see the difference between a harness that just works and one that was engineered to work well. claude code is the interesting column precisely because it's the incumbent: ledger, notebooks, vision, empty-file note, and then no window, no byte cap, no clamp, no resume offset, no streaming, no suggestion on a miss. that team just hasn't been forced yet, and it runs on models forgiving enough to absorb the waste. we were forced. we run open models where a wasted turn is visible in the eval score the same day, which is the entire reason any of the above got built. constraint is a feature - it forces you to engineer the right solution instead of hoping the model will figure it out. i hope this post helps you see the difference between a harness that just works and one that was engineered to work well. you can try all of this yourself in Command Code (we're also going open source soon so you'll be able to read the code yourself). i'd love to share more deep dives on harness engineering of command code, let me know what y'all wanna read about.

If you’re not reading the code, whether explicitly or through agentic inquiry, one or more of these is true: ○ You’re a beginner ○ Software is throwaway ○ You’re prototyping ○ You have no users / revenue ○ You’re taking on debt & risk ○ Your problems are basic And btw. All of this is fine. But the reality is that models are still not at the “full autonomy” stage yet. They make rookie mistakes, they go down bad architectural paths. I just had the best model in the world add a nonsensical 700ms delay to “settle” something and it told me “you’re right, I was cargo-culting” 🤨 I am on the camp that this need will diminish more and more. Most code is indeed going to be assembly-like. But we also have the global internet and software infrastructure riding on these models and narrative, and we have to respect that.