X Archive

My secret conspiracy theory about AI companies is they nerf models to save on compute Then they check X to see if anyone notices it If yes, give back compute If not, continue

@DamiDina @onusoz Yes, its a browser extension that grabs the posts: https://t.co/QYnJB2zaRD Expect some rough edges here and there with heavy use, but I'll iron them out if you encounter and report them.

Open-source contributions can literally get you hired... with zero interviews

OpenClaw 2026.3.1 🦞 ⚡ OpenAI WebSocket streaming 🧠 Claude 4.6 adaptive thinking 🐳 Better Docker and Native K8s support 🧵 Discord threads, TG DM topics, Feishu fixes 🔧 Agent-powered visual diffs plugin Reports of our death were greatly exaggerated. https://t.co/ISJH09of5U

Thanks to the ACP plugin @openclaw v26 has (you need to activate it): the full integration between your OpenClaw agent and Claude Code CLI is possible. Blows my mind. Docs: https://t.co/qJCJA7qG0R

When you tell Claude Code to ultrathink

We have long paid close attention to improving user experience (UX) and developer experience (DX) when building apps and tools. There is no doubt that we are now entering an era where the apps and services we produce must also—if not primarily—cater to the needs of a new type of consumer: AI agents. This means that from now on, we need to think about delivering good AX (Agent Experience). We have seen this trend forming ever since the birth of MCP and, later, the popularity of Skills. A recent blog post from the Next.js team discussed the necessity of exposing more information to agents within development tooling, allowing coding agents to make better decisions based on a more complete awareness of errors and outputs. It is living proof that the software we build needs to adapt to this new type of user. With OpenClaw becoming the embodiment of the powerful personal agent almost overnight, we are seeing platforms dedicated to agents, like MoltBook and ClawNews, burst onto the scene. Moreover, the simplicity of OpenClaw (and the underlying pi agent it uses) regarding tool calling has boosted the practice of packaging web services into simple, local CLIs. This form of interface had long fallen "out of fashion" for common users due to its abstract UX, but it is now regaining popularity because of its simplicity and token-efficiency for AI agents. Even though we might not have fully figured out where these agent-oriented web platforms will lead—they might simply be slop art, or they might one day catalyze meaningful agent self-growth and collaboration—there is no doubt that what an agent needs when interacting with the web, apps, and services is vastly different from what human users need. ## The Loop Humans and AI agents both rely on a loop when consuming information and completing tasks. We, the humans, access information mostly via apps and websites. We open an interface, we read, click, type, think, and repeat. AI agents, on the other hand, receive initial prompts from humans and then basically stay in a loop of communicating with LLMs and calling tools to obtain more context and data until a conclusion is reached and they report back. (The human element might become less important or even unnecessary once these agents become highly autonomous.)  ## The Beauty of Files and CLIs Tool calling is clearly the most vital mechanism an agent relies on to interact with the external world. As demonstrated by the Pi agent, the tools an agent needs generally boil down to just two categories: file operations (read, write, edit) and command execution (to consume services or obtain data). Humans prefer rich, smooth interactions and visually appealing UIs to efficiently consume information, produce artifacts, and complete tasks. For agents, however, efficiency looks entirely different: the more straightforward the path between request and result, and the fewer tokens the process imposes, the better. This is why the progressive disclosure of data employed by the Skills system is highly favored over MCP. The input-output efficiency of command-line tooling has become the easiest way for agents to gain knowledge of the outside world. ## The Middleware Obstacle For agents, traditional webpages and app interfaces are essentially obstacles. There are already countless attempts to help agents navigate existing webpages or operate mobile apps. Google recently released WebMCP in an attempt to lower the barrier for agents operating on websites. While this looks very promising as a unified approach catering to a massive number of legacy websites, a browser still sits in the middle, forcing agents to interact with interfaces built for human consumption. Understandably, these middleman approaches will likely persist for some time, as there is no unified mechanism to retroactively fit the old web into the new world. Beyond the asymmetrical demands between humans and agents when accessing information, we cannot ignore the fact that a large number of websites actively and aggressively block autonomous agents. This seems logical for social and UGC platforms like X—after all, we aren't quite ready to socialize with agents yet. However, these protective measures vividly demonstrate that the web, its apps, and the mindset behind them were fundamentally not designed for agents. ## APIs and CLIs - The Agentic Way It has become clear that for agents, direct access to functionality—even in the form of raw, low-level APIs—is far superior to wiggling through complex UIs. In that sense, many companies currently selling apps and tools to human users will eventually pivot to selling APIs or CLIs to agents. If the business value exposed through these APIs isn't sophisticated enough to prevent an agent from replicating it with relatively little effort, the business model itself might not survive as LLMs evolve. This is exactly what Karpathy discussed in a recent tweet: > "99% of products/services still don't have an AI-native CLI yet." -- Andrej Karpathy In 2026, new and existing services will become hyper-aware of agent ergonomics and will start offering better experiences via CLIs or streamlined APIs. When building products or producing digital artifacts, developers will always have to consider "the other type of user." For all apps, functionalities currently exposed via human-oriented UIs are destined to be transformed into CLI arguments or API parameters. Either that, or someone will build an AI-native alternative specifically to cater to agent needs. Documentation that teaches users how to navigate specific workflows will also start to be complemented with agent Skill specifications. This transformation will be fast for some categories of apps and slow for others. Applications that employ proprietary formats, rely on highly complex data manipulation logic, or fundamentally require human intuition will probably retain their current forms for a while. Eventually, however, agents will find a way to become the primary users of even the most complex software. Looking further ahead, sensors bridging the physical and digital worlds—or devices providing pure physical utility—can also benefit from this transformation. Even when agents gain a physical form, like a humanoid robot, and possess the skills to navigate environments designed for humans, an agent-friendly digital interface will still be superior in certain contexts. Imagine a humanoid operating a rice cooker: it absolutely needs vision and motors to lift the lid and pour the rice. But when it comes to setting the timer or selecting the cooking mode, a direct API exchange will always be more efficient than using a camera to look for a digital panel and using a robotic finger to press the buttons. ## The Inevitable Standard of AX We are rapidly approaching a tipping point where AX will require universal standards. Just as we have spent the last decade obsessing over SEO and performance metrics to help search engines parse our sites, we will soon need standardized protocols for agent interaction. Whether these emerge as universally adopted CLI wrappers, predictable API architectures, or even decentralized agent-centric standards like ERC-8004, a structured framework is inevitable. The platforms and developers who define these protocols will ultimately dictate the next decade of digital infrastructure. Ultimately, this transition from UX to AX is not about removing humans from the equation; it is about removing friction for the increasingly autonomous tools we employ. When our software is optimized for the entities that process data the fastest—our agents—our own capabilities are amplified. We are moving past the point where an agent-friendly interface is just a clever feature. Very soon, building for agents won't just be an alternative to building for humans; it will be the prerequisite for participating in the digital ecosystem.

It's pretty disingenuous to specifically set up an application in all ways it isn't meant to be then claim they red teamed it. - openclaw is a personal assistant. It isn't meant to be thrown in a discord channel with a dozen users and others agents with elevated tool access. - methodology is severely lacking. No comparison with other personal agent systems like Claude Cowork. Repeatedly doing something not meant to be done with openclaw and claiming "agent is compromised" is a deceptive methodology. - this paper opened up openclaw to moltbook (lol). The researchers opened themselves up to far serious vulnerabilities than what the agent did by itself. - it's just sad to see a poorly structured research and paper being advertised as new and necessary research. And riding on the popularity of openclaw.

Oxidize everything!

The part of the SaaS bear thesis I actually agree with is "margins will have to come down, due to increased ease of migration & increased competition." SaaS margins were often way too high and that wasn't sustainable forever. It's a very different take than "SaaS is dead" though

I am asking once again Who is building a self hostable discord clone that supports token streaming? PLEASE I beg you I don’t want another side project 💀

So who is building actually good open source self hostable discord that supports token streaming now? And who is building an open source version of codex desktop app?

First there was chat, then there was code, now there is claw. Ez

With this extremely unwise move, anthropic will soon witness moltbot’s brand recognition surpass that of claude and realize they could have rided that wave all along

I see @bcherny and raise one. I not only did not open an IDE, I did not touch a terminal since last night, thanks to @steipete's @openclaw Opus in k8s pod pulls errors from gcloud, debugs the issue, and creates PR all inside Discord. I call this Discord Driven Development

People like the farmer analogy for AI Like before tractors and industrial revolution 80% of the population had to farm. Once they came all those jobs disappeared So analogy makes perfect sense. Instead of 30 people tending a field, you just need 1. Instead of 30 software developers, you just need one Except that people forget one crucial thing about land: it's a limited resource Unlike land, digital space is vast and infinite. Software can expand and multiply in it in arbitrarily complex ways If you wanted the farming analogy to keep up with this, you would have to imagine us creating contintent-sized hydroponic terraces up until the stratosphere, and beyond...

Over 1,300 Stripe pull requests merged each week are completely minion-produced, human-reviewed, but contain no human-written code (up from 1,000 last week). How we built minions: https://t.co/GazfpFU6L4.

on ai psychosis 80% of people need to use ai agents in a very sterile and boring way in order not to go crazy majority of the population does not have the skepticism muscle. they don't have theory of mind, and will subconsciously and emotionally associate with machines, while on the surface lying to themselves that they don't especially those that grew up in the us under hardcore consumerism and adjacent cultures you thought 4o addicts were bad? wait a few years, it will get much worse. we will have to regulate all this if you don't want to become a victim of this, make your openclaw SOUL. md as bland as possible. mine knows it's just a tool and this is a subjective view of course. @steipete might disagree with me. his instance feels much more interesting and fun. i truly like that one better but that is exactly the problem for me. i know myself, and i know it is a slippery slope for me. so i self regulate and set up my system accordingly. thankfully, im an adult and my brain has set enough such that any damage would be limited but there is a risk for emotionally vulnerable people, or children, specifically a risk of dissociating and losing touch with reality why do i write all this? because being in this project, i feel responsible, and feel like we should prepare for what is to come

Excited to work with Peter Steinberger to build the future of agents for everyone and to continue to improve Codex in leaps and bounds. We are committed to OSS, continuing to make OpenClaw flourish and bringing agents to life in a way that is fun, safe and highly productive. Can’t wait to see what we ship together!

codex 5.3 is definitely more trigger-friendly than 5.2. A simple "discuss" no longer works reliably. Changed my habits to use "give me options" to prevent it from running along writing code.

lol when did codex develop humor

Filter your X feed against unwanted content with local open models Announcing my new project: InternetCondom Fast, and small model (< 1mb), open dataset. See it in action:

moltbook vs clawdbot/moltbot/openclaw

got fully sandboxed @openclaw to run finally, starting scrape the UNDESIRABLE now I'm a security nut and didn't want to run even the gateway unsandboxed. openclaw apparently currently doesn't have support for FULL sandboxing. it took me a few hours to get it to work because docker builds suck. I'm also tired this, so I'm just gonna wipe an old thinkpad and go full yolo so yeah, time to scrape some posts

Charles Stross must be very entertained now

We need better filters both for ourselves and the agents. Locally runnable models to filter out undesirable content with high precision. Fully open source datasets, weights, MIT license

ahhhh f... shift + enter doesn't work in codex on vscode

gave our internal @openclaw instance zeno a hubspot cli, because hubspot's own cli is limited to developer stuff It's called hubspot++. should we open source it?

Automated AI reviews on github by creating an ai-review skill and a script to paste trigger prompts and wait for their response. It is instructed to loop and not stop until all AI review feedback is resolved. This AI review workflow developed gradually based on the current capabilities, and I've realized recently that it became quite mechanical. So decided to automate it in full ralph spirit (it's ok because it's addressing feedbacks and fixing minor bugs) In the current state, we paste the contents of REVIEW_PROMPT.md into a comment, which automatically tags claude (opus 4.5) and codex (whatever model openai is serving) It then waits until both have responded. In the ai-review skill, it is instructed to take the feedback from SLopus with a grain of salt and ignore feedback that doesn't make sense It works! See in the images below. If the review is stupid, you will of course see it on the PR and what the model has done, and can revert it

It is clear at this point is that github's trust and data models will have to change fundamentally to accommodate agentic workflows, or risk being replaced by other SCM One *cannot* do these things easily with github now: - granular control: this agent running in this sandbox can only push to this specific branch. If an agent runs amok, it could delete everybody's branches and close PRs. github allows for recovery of these, but still inconvenient even if it happens once - create a bot (exists already), but remove reviewing rights from it so that an employee cannot bypass reviews by tricking the bot to approve - in general make a distinction between HUMAN and AGENT so that you can create rulesets to govern the relationships in between cc @jaredpalmer

It is clear at this point is that github's trust and data models will have to change fundamentally to accommodate agentic workflows, or risk being replaced by other SCM One *cannot* do these things easily with github now: - granular control: this agent running in this sandbox can only push to this specific branch. If an agent runs amok, it could delete everybody's branches and close PRs. github allows for recovery of these, but still inconvenient even if it happens once - create a bot (exists already), but remove reviewing rights from it so that an employee cannot bypass reviews by tricking the bot to approve - in general make a distinction between HUMAN and AGENT so that you can create rulesets to govern the relationships in between cc @jaredpalmer

I propose a new way to distribute agent skills: like --help, a new CLI flag convention --skill should let agents list and install skills bundled with CLI tools Skills are just folders so calling --skill export my-skill on a tool could just output a tarball of the skill. I then set up the skillflag npm package so that you can pipe that into: ... | npx skillflag install --agent codex which installs the skill into codex, or any CLI tool you prefer. Supports listing skills bundled with the CLI, so your agents know exactly what to install

Within the CLI, you can now steer codex mid-turn without interrupting and watch the agent adapt in almost real time. Enable in /experimental

Just some thoughts after using Claude Code intensively for 1 week 👆

75k lines of Rust later, here is what I’ve built during the first Christmas with agents, using OpenAI Codex 🎄🤖 - A full mobile rewrite and port of my Python Instagram video production pipeline (single video production time: 1hr -> 5min) (ig: nerdonbars) - Bespoke animation engine using primitives (think Adobe Flash, Manim) - Proprietary new canvas UI library in Rust, because I don’t want to lock myself into Swift - Thanks to that, it’s cross platform, runs both on desktop and iOS. It will be a breeze porting this to Android when the time comes - A Rust port of OpenCV CSRT algorithm, for tracking points/objects - In-engine font rendering using rustybuzz, so fonts render the same everywhere - Many other such things Why would I choose to do it that way? Because I have developed it primarily on desktop where I have much faster iteration speed. Aint nobody got time for iOS compilation and simulator. Once I finished the hard part on desktop, porting to iOS was much easier, and I didn’t lock myself in to Apple Some of these would have been unimaginable without agents, like creating a UI library from scratch in Rust. But when you have infinite workforce, you can ask for crazy things like “create a textbox component from scratch” What I’ve built is very similar in nature to CapCut, except that I am a single person and I’ve built it over 1 week What have you built this Christmas with agents? cc @thsottiaux

So is somebody already building “LLVM but for LLM APIs” in stealth or not? We have numerous libraries @langchain, Vercel AI SDK, LiteLLM, OpenRouter, the one we have built at @TextCortex, etc. But to my knowledge, none of these try to build a language agnostic IR for interoperability between providers (or at least market themselves as such) Like some standard and set of tools that will not lock you in langchain, ai sdk or anything like that, something lower level and less opinionated I feel like this is a job for the new Agentic AI Foundation cc @linuxfoundation, so maybe they are already working on it? I desperately want to start on such a project, but feel like I might get sniped 2 months after Anybody has any information on all this? cc @mitsuhiko @badlogicgames @steipete

I think X removed one of my posts yesterday about the new encrypted "Chat" rolling out to all users, and how you might lose all your past messages if you forget your passcode and do not have the app installed I can swear I clicked Post. Do they classify posts based on their topic and delete the ones they don't like? Anyway, we shall see, I am taking a screenshot and saving the URL.

CLI coding tools should give more control over message queueing Codex waits until end of turn to handle user message, Claude Code injects as soon as possible after tool response/assistant reply There is no reason why we cannot have both! New post (link below):

How to stop AI agents from littering your codebase with Markdown files? I wrote a new post on how to create documentations with AI agents, without having it add markdown files in your repo root, and have chronological order to the files it creates

CLI coding tools should give more control over message queueing Codex waits until end of turn to handle user message, Claude Code injects as soon as possible after tool response/assistant reply There is no reason why we cannot have both! New post (link below):

TIL @OpenAI now has a GitHub action for Codex, similar to Claude Code This lets you invoke Codex in a more controlled way in your repos You must still pay API prices though. Let's see if OpenAI will introduce a way to connect your Pro plan, like in @AnthropicAI paid plans

My >10 yr old programming habits have changed since Claude Code launched. Python is less likely to be my go-to language for new projects anymore. I am managing projects in languages I am not fluent in---TypeScript, Rust and Go---and seem to be doing pretty well

Products with extensive/rich UIs lots of sliders, switches, menus, with no scripting support, and built on opaque, custom, binary formats are ngmi in the era of heavy human+AI collaboration. If an LLM can't read the underlying representations and manipulate them and all of the related settings via scripting, then it also can't co-pilot your product with existing professionals and it doesn't allow vibe coding for the 100X more aspiring prosumers. Example high risk (binary objects/artifacts, no text DSL): every Adobe product, DAWs, CAD/3D Example medium-high risk (already partially text scriptable): Blender, Unity Example medium-low risk (mostly but not entirely text already, some automation/plugins ecosystem): Excel Example low risk (already just all text, lucky!): IDEs like VS Code, Figma, Jupyter, Obsidian, ... AIs will get better and better at human UIUX (Operator and friends), but I suspect the products that attempt to exclusively wait for this future without trying to meet the technology halfway where it is today are not going to have a good time.

.@AnthropicAI @bcherny @_catwu blink twice if you already have internally: $ claude sandbox I can't wait until you release this, I'm gonna build it myself :)

I've been using Claude Code extensively since last week What I'm wondering is, since you can run Claude Code locally, why isn't there any tooling to let you run it in a sandboxed mode in local Docker containers yet? Or did I miss it? cc @AnthropicAI