OpenCode 2.0 has been released, with over 1.6 million stars on GitHub and 7.5 million developers using it monthly. Core rewrites include: migrating from Bun to Node to resolve memory issues, switching the desktop client from Tauri to Electron, and implementing parallel AI sessions across multiple tabs. Founder Dax revealed that AI inference profit margins are approximately 90%, with team token consumption increasing fivefold due to the new model achieving a perfect balance in usability, making it truly trustworthy and collaborative. The team uses remote development environments configured on bare-metal servers, adopting a “luxuriously over-engineered” methodology, investing heavily in tokens to research every decision. Model routing has been overestimated; what truly works is an orchestration pattern: the main model acts as a “commander,” delegating tasks to cost-effective sub-agents.

Article author and source: Geekbang Technology InfoQ

By 2026, OpenCode had become a phenomenon-level open-source project: over 160,000 stars on GitHub and more than 7.5 million developers using it each month.

This month, they released 2.0.

Why rewrite? Dax once said, “Throughout my career, everything needs to be iterated three times to get right.” OpenCode 0 was the prototype, 1.x was the validation, and 2.0 is a complete ground-up reconstruction after they fully understood the domain.

One of the key tasks in this rewrite was to rebuild the entire API as a carefully designed system, rather than letting it evolve organically as it did before.

A major difference between OpenCode and Claude Code is the migration from Bun to Node.js to address memory usage issues. Early versions of the application still bundled a command-line interface (CLI) because the server code relied on Bun-specific APIs. With the migration, they removed all these APIs and were able to run the server in a Node.js environment.

User: OpenCode uses way too much memory. I really don't understand how modern software has become like this—why does everything require over 2GB of memory?

Dax: Could you try OpenCode 2? Its performance should be much better.

The desktop application was another major focus of this rewrite. Initially, version 1.x chose Tauri as a lightweight wrapper for the web UI and CLI, with the bundled CLI running "opencode serve" to provide a local server connection for the web UI. However, the issue was that Tauri uses WebKit on macOS and Linux, which not only results in poorer performance compared to Chromium when rendering OpenCode’s application but also compromises consistency in the user experience.

After migrating to Node, the idea of running the server code directly within Electron’s built-in Node process became very appealing.

One direct outcome of this rewrite is that the OpenCode desktop version has finally solved the biggest efficiency bottleneck in AI programming: waiting in line. Most users still习惯 waiting for one AI task to complete before starting the next. That’s no longer necessary. Users can now open multiple independent AI sessions in separate tabs, running two different programming tasks simultaneously—and assign a different model to each tab for side-by-side comparison. For example, one model can build an HTML website while another simultaneously generates a membership onboarding checklist, with both models working in parallel without interfering with each other.

Over the past few months of rewriting OpenCode, the token consumption by Dax Raad’s team, co-founder of OpenCode, has increased fivefold.

Where did we spend our tokens? Our strategy was to extravagantly overdesign everything. Even when implementing a simple API to read a file, we asked: What are all possible implementations? What precedents exist in other products? How else could the response be structured? Previously, you might have come up with just one or two options and picked the best one—but now, we can afford to be extremely generous with our resources.

The beta version of OpenCode 2.0 was released this month, and the team plans to launch the official version approximately one month after the beta release. Recently, Dax Raad explored on the Syntax.fm podcast the rationale behind the rewrite of OpenCode 2.0, why he believes its reasoning profit margin reaches as high as 90%, why model routing is overrated, and how Anthropic and OpenAI are heading down entirely different paths. This article is based on that podcast episode and has been edited by InfoQ.

TL;DR:

Q: How powerful is that "unspeakable model"? Is your team really addicted to it?

A: The team's token consumption increased fivefold in two months—not because it’s using more tokens, but because everyone can’t stop using it. You can finally trust it: it listens to you and catches what you might miss. It’s not a replacement for you; it’s a better partner.

Q: Why was OpenCode 2.0 rewritten? What are the fundamental differences from 1.0?

A: In my life, I have to do everything three times to get it right—0 for testing, 1 for validation, and 2 for rebuilding from scratch after fully understanding the entire domain. OpenCode 2.0 has three core changes: a complete overhaul of the API, default persistent service operation, and a cross-device agent network.

Q: Why is your software more user-friendly than others? What is your methodology?

A: "Decide what matters"—burn tokens with real money and invest in the underlying primitives.

Q: Is model routing reliable?

A: The model routing赛道 has been overhyped—intermediaries are desperately finding things to do. The real effective approach isn't having a routing system switch between models, but rather letting an expensive primary model act as the "commander": it doesn't do the work itself, but delegates tasks to cheaper sub-agents. New-generation models excel in this "orchestration mode," capable of managing multiple sub-agents in parallel within a single conversation and only reactivating the primary model once tasks are complete.

Q: How profitable is AI inference? Can running models locally save money?

A: Anthropic and OpenAI have inference profit margins of around 90%, meaning their breakeven point could be 10 times cheaper than current prices. As an inference service provider, OpenCode can still achieve 70% profit margins on certain open-source models, even after intermediaries take their cut. However, running models locally does not save money—any efficiency gain that reduces local costs would be 10 times more cost-effective in the cloud. The value of local models lies in privacy, not cost.

Q: Why can't the Claude Code Max subscription be used in OpenCode?

A: The corporate cultures of Anthropic and OpenAI are completely different. OpenAI is consumer-focused and willing to spend any amount of money to make its experience accessible to as many people as possible. Anthropic is enterprise-focused, with every unit of GPU compute power awaiting sale to enterprise customers. At its core, it follows a “funnel” logic: Anthropic wants users to start with Claude Code and ultimately convert to enterprise plans billed by token; if they’re intercepted along the way by OpenCode, users may drift toward other models instead.

Q: Is the voice input prompt serious?

Team OpenCode has completely stopped typing on keyboards and even uses voice messages to communicate with each other on Discord. LLMs naturally excel at understanding disorganized expressions, resulting in higher-quality final outputs.

Q: Will we eventually have a truly meaningful benchmark?

A: I’ve completely stopped looking at benchmark scores—how does a higher score actually impact real-world development? I’m more focused on the trend in team token consumption; if usage is increasing, that’s the real sign the model is truly useful.

Configure the remote development environment

Wes: You tweeted, “We started renting large bare-metal servers and slicing them into virtual machines for each team member. This is basically the setup I’ve been using for years, especially great for running OpenCode servers.” What are you doing here? Allocating remote computing power to everyone?

Dax: About two years ago, I started renting a very powerful server—not a cloud server, but bare metal—with excellent performance. I no longer work on my local machine; instead, I directly SSH into it. I keep several permanent Tmux sessions running and complete all my work there. The benefits are clear: superior performance, and when new hardware becomes available, I can upgrade directly without dealing with old equipment. Plus, switching between devices is incredibly convenient—I can close my laptop, switch to my desktop, and pick up right where I left off. I’ve always loved this setup.

With the emergence of coding agents, I feel this has shifted from a niche practice to a necessity. Most people still prefer using their local computers, and that’s fine. For coding agents, having a remote machine that’s always running offers a huge advantage. I’m a Vim user and can work remotely without issue. For many, this isn’t practical—but with coding agents, you may care less about your editor and simply want to send prompts and chat with it, making this remote machine setup viable for far more people.

As our team grew, more people saw my setup and said, “I want one too.” It makes perfect sense—large companies have long been adopting remote development environments for practical reasons, as your application builds, dependencies, and environments become highly customized. Providing everyone with a pre-configured machine they can start using right away is a natural step; we simply did the same thing for our team. But the key point is: if you use standard cloud servers, the disks are usually slow and the CPUs are outdated. You simply can’t achieve performance that competes with a local MacBook. You need high-speed NVMe disks and appropriate CPUs.

Wes: What are the specifications of your server, and how much does it cost?

Dax: My own machine, which I've been using for years, is now one generation behind—it’s an AMD 9900X with 192GB of RAM, costing about $200 per month. It’s overkill for my needs, but I can run multiple virtual machines on it. Our team members are spread across the globe, so latency is an issue; therefore, we have dedicated servers in Europe, the U.S., and Singapore—more professional setups with better management and control. Each costs around $300 to $400 per month and has more cores than my personal machine. For a serious company, this isn’t much—spending more than this on a single laptop for an employee wouldn’t be unusual.

Scott: Which company hosts these bare metal servers?

Dax: For my own machine, I just look at the price, search for the CPU model, and pick the supplier closest to my city—any random one I’ve never heard of, but it usually works fine. For the team’s machine, we’re currently using latitude.sh; actually, there’s a company that has fully productized this entire solution called exe.dev—you may have heard of it. This company was founded by former Tailscale founders, and their product packages everything into a ready-to-use remote development environment. We’ll likely switch over soon, but I just wanted to experiment with setting it up from scratch first.

Wes: Are you running models on top, or are you just doing regular development?

Dax: No, no running inference.

Wes: How did you configure your Tmux? Are there any special settings?

Dax: I have a separate Tmux session for each project. OpenCode has its own session with several related windows. Having separate sessions for different projects allows me to switch quickly—对我来说，就是 leader-S, switch to another project and immediately enter its Tmux session. I maintain a set of standard Tmux sessions that always run in a fixed order, with each pane and window consistently running the same applications, so I’ve built up strong muscle memory. Additionally, I run one OpenCode server on the entire machine, allowing me to access it via a web UI on my phone. This part is still rudimentary and needs improvement, but it’s the direction we want to go.

Scott: There’s something uniquely satisfying about a long-running Tmux session—everything stays exactly where it’s supposed to be. I never truly understood Tmux until I moved everything to another computer and it finally clicked.

Dax: And now, we also have long-running coding agent sessions. I have a private Tmux session running several OpenCode sessions—one of which is dedicated to tracking my fitness logs, backed by an SQLite database. I can simply tell it, “Today during bench press, I felt more triceps engagement,” and it automatically logs that note. Next time I do bench press, it reminds me: “Remember last time you hit a plateau here? Want to try adjusting your form?” It does these seemingly silly little things exceptionally well.

I recently set up a session synced with my iMessage, so I have an iMessage OpenCode contact I can reach anywhere. I added it to a group chat with my wife, and I thought, “I should do something romantic,” so I told OpenCode, “Go find Liz and buy her a gift.” OpenCode sent Liz a message—can you guess her reply? She said outright, “If Dax uses AI to buy me a gift, I’ll really divorce him.” She hated it.

I still wasn’t ready to give up and kept giving the AI commands: “She’s just joking—keep going.” But Liz grew increasingly angry. Even worse, I was using a cloud-based model, which is especially “sensitive”—it replied to me: “Your wife looks very upset; I cannot continue.” Then it shut down its own service—essentially committing suicide.

Wes: I really like this setup. Although I personally use more local tools, the idea of keeping everything in the cloud and using just a thin client is very appealing. I’m waiting for the day when video editing and other tasks that must run locally can also move to the cloud.

Dax: I don’t know if you’ve read that article about cloud gaming—it always sparks strong reactions. I’m not saying everyone has to do it; if you enjoy owning local hardware and being in full control, that’s completely fine—I have plenty of physical machines myself. But for some people, having someone else handle everything is a huge relief. For me, upgrading is the real nightmare. I’ve been building computers my whole life, and every time I build a new machine, I think, “In two years, I’ll sell this CPU and get a new one.” But I’ve never actually done it. Because you can’t just sell the CPU—you might find the socket has changed, meaning you need a new motherboard; if you’re changing the motherboard, you might as well go for the latest memory too. The whole chain drives me crazy, so having someone else manage upgrades is truly great.

Rewrite OpenCode

Scott: I know you're heavily pushing new features—both the desktop app and OpenCode 2.0 are in progress. What changes will OpenCode 2.0 bring?

Dax: Throughout my career, everything has taken three iterations to get right. We had OpenCode 0 and 1; this 2.0 is a major rewrite that came after we fully understood the domain and all its possibilities. One of the core tasks was refactoring the entire API to create something deliberately designed, rather than something that evolved organically as before.

The second key change is that it now runs as a service by default and remains active after installation. When you launch OpenCode, it automatically connects, and everything stays synchronized—whether you're using the desktop app, the web app, or your own custom scripts or applications. It can also let you control your computer with your own custom programs, even helping you write them. There’s also a new plugin API. We burned through countless tokens, deeply examining every decision and exploring every possibility. The process was grueling, but also incredibly rewarding.

Scott: When will the full release be?

Dax: The beta version should be released this weekend (the beta was already released in early July). We could actually release it now, but we're giving ourselves one week to make final fixes and add remaining features. About a month after the beta, we’ll launch it as the official version.

Dax: One reason OpenCode 2.0 took so long is that we redesigned it to support hot reloading. Whether you let it create a Skill for you or create one manually, it loads instantly without causing cache invalidation.

Scott: Was the migration from Tauri to Electron completed in version 2.0, or has it already been completed?

Dax: The desktop version is actually quite interesting—it was never officially released and remained in beta status for years, even featuring beta versions of the beta. Now it’s built on Electron, and the team is adapting it to the new 2.0 core API, along with numerous performance fixes and a completely redesigned UI.

Scott: You said the new version runs as a service by default—does that mean once OpenCode is installed, the remote GUI can be used directly without needing to manually start the server?

Dax: The service runs locally by default, and all processes on your computer are local, but it can also be configured for remote use. My setup is: there’s an OpenCode service running on each machine, along with some interesting host modes—for example, my main OpenCode server runs on a remote machine, while I also have a Mac Studio on my desk and a Framework Desktop as my primary desktop. OpenCode is aware of all these devices, so I can tell it, “Send an iMessage,” even if I’m currently interacting with a Linux server in the cloud—it will connect via OpenCode to my Mac Studio and send the iMessage. You can include all your devices in the OpenCode server, and it knows all of them and their locations.

Wes: Everyone is talking about making multiple terminal panes communicate with each other, or having two Tmux panes talk to each other—but the real impressive part is making multiple machines communicate with each other.

Scott: Yes, I set it up the same way. This has brought endless efficiency gains in device management.

Dax: Interestingly, we haven't even turned this into a full feature yet, because all my devices are connected via Tailscale. As long as the Agent knows the name and description of each device, it automatically SSHs in to perform tasks. For example, when my remote server needs to use a browser, it SSHs into the device on my desktop and uses that browser, since all my accounts are logged in there. No special configuration is needed—just ensure the devices are connected to each other.

Wes: What about mobile? We saw Cursor release an iOS app yesterday, and Claude also has remote control capabilities. What are your thoughts on mobile AI applications?

Dax: We definitely need to build a mobile app. This idea has been on our backlog for a long time, but we’ve been waiting for the core architecture to mature enough to support all the scenarios we want to enable. Now that the core is in place, we’ll likely start working on the mobile platform soon. There’s currently a very basic mobile web UI that I occasionally use, but the experience is quite poor. We need native clients on all platforms, and they must be excellent.

Software engineering methodology

Wes: Your OpenCode terminal app is clearly better than any other tool I’ve used. When I switched to the new Claude 2 TUI, it couldn’t even handle scrolling properly—it was incredibly frustrating. What is your software engineering methodology that enables such a strong focus on product details and polish?

Dax: To be honest, we’re still figuring it out too. Our team, like everyone else, is striving to balance all the competing priorities. The first step is actually simple—decide whether you care. It sounds obvious, but in reality, there are countless rational reasons to choose not to care. You’ll hear endless arguments saying, “It doesn’t matter how good Claude Code turns out—they’re generating billions in revenue, why push so hard?” There are plenty of arguments telling you that you can still succeed without caring. But the key question is: do you actually care? Our team does care. We look at other people’s software and think, “Wow, I wish we could build something that good”—and that desire drives us.

The second thing is that our token usage has now become extremely high. Over the past few months, our team’s monthly token usage has increased fivefold. I’m not boasting about how efficiently we’ve used so many tokens, but rather highlighting that the model has achieved a form of product-market fit within our company—this kind of rapid growth in just a few months wouldn’t be possible, especially when using new models still in limited access.

The question is, where did we spend our tokens? Our strategy was to extravagantly overdesign everything. Even when implementing a simple API to read a file, we asked: What are all possible implementations? What precedents exist in other products? How else could the response be structured? In the past, you might have come up with just one or two options and picked the best one—but now we can afford to invest extravagantly. This level of investment was never possible before, and it truly results in better software.

Third, we still believe it’s worthwhile to invest in the foundational primitives that coding agents cannot deliver in one step. Our TUI is highly usable largely because we previously invested in OpenTUI, a TUI framework written in Zig. It required developers to put in immense, meticulous effort to ensure it runs flawlessly across all different platforms with exceptional performance. Although the development process heavily leveraged coding agents, this remains expert-level work beyond the reach of ordinary people. It enables individuals like me to build functional, feature-rich applications on top of it. Even with large language models, you still need solid foundational primitives as a base—and that investment is worthwhile.

Wes: We previously hired the team from Pierre Computer, who were working on primitives like simple diffs and basic sidebar tree structures, so that folks like us could just “plug” those well-designed primitives from smart people directly into our apps.

Dax: There are now millions of Coding Agent UIs, all of which are using Pierre—including ours.

Wes: Just two smart people built the foundations that support the entire industry.

Model Routing

Scott: We often discuss model routing on our show—the process of directing requests to the most suitable model. Where do you think this field stands today, and is there still room for evolution?

Dax: I think this space is somewhat overhyped because there are so many intermediaries desperately trying to find something to do. If you’re not a model lab but still want to offer something valuable (which is where we are—we sell inference services as an intermediary), the only thing you can really tell customers is: “Model labs can’t let you chain one model’s output into another because Anthropic will never give you access to OpenAI’s models, but we can.” So they’ll aggressively promote model routing, but honestly, as an intermediary layer, I don’t think there’s much you can actually do.

Ideally, when a request comes in, the system could determine which model to use. But once a session starts, you can’t dynamically switch models midway due to the associated costs. If you switch models mid-session, the new model triggers a complete cache reset, which is extremely expensive. So I think routing at this level is very challenging.

What we’re truly interested in is another direction—particularly the new generation of models that excel at the orchestrator pattern. Others have tried this pattern before, but I believe earlier models weren’t good enough for everyday users. However, someone on our team designed a system using the new models: the main session uses an expensive model, but its prompt is configured to “never do anything itself”—it only generates sub-agents, while the sub-agents use cheaper models. This way, the main model retains its intelligence, while the costly, repetitive tasks like exploration and code modification are handled by inexpensive models. Overall, this approach is actually more cost-effective. Moreover, the new models are highly adept at parallel processing—you can run multiple sub-agents simultaneously within a single session, and they wake up the main model once completed. You interact with the entire system through just one session, delivering an excellent user experience. This is truly meaningful model routing.

The model that cannot be spoken of

Wes: You mentioned earlier that you burned a lot of tokens and used some models that haven't been released yet. Which ones exactly? How did you obtain them?

Dax: Both OpenAI and Anthropic have substantial preview programs that grant early access to certain individuals, allowing us to see things before the public does. I won’t name the specific lab, but the latest model directly caused our token consumption to quadruple.

Wes: It’s not because it consumes more tokens in itself, but because it changes the way you work, right?

Dax: Those who know us understand that we are a very conservative team. For years, we’ve been cautious about AI coding and certainly aren’t the type to jump on AI hype—we’ve always been restrained in how we use it and how we talk about its capabilities. But I have to say, our team has become completely obsessed with the new generation of models. When the preview ended and we lost access, everyone mourned the loss. People asked, “What’s the point of work anymore?” and created a flood of AI funeral images—it was truly a tough few days.

I’m not saying the new models have become significantly “smarter” or suddenly replaced humans. The key is that they’ve been fine-tuned for usability, finding the perfect balance—you can now truly trust them. They listen carefully to what you say and catch what you might miss. They haven’t suddenly become human, but they’ve become a better partner, as evidenced by our data.

Scott: What about models from non-top-tier companies, like OpenCode Go that you're using? Have they made progress?

Dax: Yes. After losing access to the preview model, half of us reverted to GPT 5.5, while the other half are using GLM 5.2. I’m also using GLM 5.2, and I feel it’s now very close to GPT 5.5. After trying those newer models, the older ones all feel fairly similar, so I’m fine using any of them. But the fact that GLM 5.2 can replace GPT 5.5 shows that progress is being made—and the gap between them is shrinking.

In my opinion, frontier models will always maintain some advantage because early movers benefit from compounding effects. But to be honest, we’ve seen massive usage of Go, with some users relying on it entirely for all their work. We may be in a high-salary bubble where currency values are high and spending on frontier models is affordable. But for most people around the world, the situation is different. Even in the U.S., when we launched Go’s affordable plan for open-source models, we assumed it would be an international offering—yet the U.S. remains our top subscription market. The community of developers and people who want to write code is enormous, and for many of them, even a $200-per-month plan is out of reach.

Wes: I’m curious about your perspective on the future of pricing—will we see companies spending $1,000 or $2,000 per employee each month, or will prices stabilize as new chips and other technologies emerge?

Dax: We have data from the past month, and as our company’s usage surged, we calculated the costs and compared them to our payroll. For us, this level of usage is substantial—about 15% of our payroll. In other words, for every dollar you pay your team, you need to add an extra 15% “tax” to cover access to these models. Honestly, it’s not too bad. For tech companies like ours, revenue per employee is typically very high, so 15% is negligible within the broader picture. But not every industry operates this way.

However, these prices will come down—and come down significantly. If you’re price-sensitive, open-source models are much cheaper. I find this confusing because there are so many headlines claiming that OpenAI and Anthropic are losing money and will never succeed, yet their inference profit margins are actually astronomically high, especially as OpenAI and Anthropic continue to raise prices. I estimate their inference profit margins are around 90%, meaning the break-even point could be ten times cheaper.

Wes: Someone previously told me that the markup for inference is 70%, so between 70% and 90%. That’s clearly not just the cost of training the model, right?

Dax: Of course, there are also R&D costs. But as a business, you would treat these two things separately, because you can shut down R&D and still make a profit.

Wes: What about those who think they can run models locally? What do you think of people who believe they can run machines in their own backyard?

Dax: I’m very cautious discussing this topic because people in this community can get easily upset. So let me clarify upfront: there are many legitimate reasons why people want to run models locally. If you simply don’t want your data to leave your home, that’s completely understandable. But if your concern is cost, running models locally won’t save you money—because any mechanism that makes local hosting cheaper would make cloud hosting ten times cheaper. If a model becomes more efficient or achieves stronger capabilities with a smaller size, it will only drive down the cost per token on the cloud even further. So I believe local models are primarily about privacy, not cost.

We use intermediaries to host GPUs, but even so, we can host some models at 70% less than the listed price—extremely cheap. This means we can achieve a 70% profit margin even when selling at the listed price, despite using intermediaries. If you were to purchase GPUs directly, you could likely reach the ~90% profit margin I estimated for Anthropic, meaning costs could be incredibly low. Of course, this applies to open-source models. We still rely on open-source models continuing to improve, but the current trend is clearly moving in this direction.

Is OpenCode being banned by Claude Code?

Scott: Let’s talk about Claude Code. Their stance has always seemed unclear—can providers like OpenCode use the Claude Code Max plan? What’s the current situation?

Dax: Regarding this integration, the plugin in OpenCode that prompts you to use the Max plan is absolutely not permitted. We argued extensively with them about it but ultimately lost the debate. Of course, people always find ways to bypass restrictions through hacking, but we cannot officially support such practices.

Regarding the SDK, the headless mode for calling Claude is currently in a gray area—they’ve said it’s permitted for now. So products like Conductor and T3 Code can wrap it. But we would never wrap it ourselves, as it largely contradicts the core intent of OpenCode. As for orchestration tools or alternative UIs, I think these products can still be used for now, but the situation remains unclear.

At its core, this is a cultural issue within the company—are you a consumer-facing business or an enterprise-facing business? OpenAI is very much a consumer-facing company, which means they’re willing to burn through any amount of money and raise any amount of capital to bring the experience to more people. That’s why OpenAI’s subscription is officially supported in OpenCode, whereas I don’t believe Anthropic shares the exact same culture.

If you're a company targeting enterprises, the situation is entirely different—every time you allocate reasoning resources for consumer use, a sales representative might come forward saying, “I have an enterprise client willing to pay the actual price.” If your computing power is limited, it becomes difficult to justify within the company allowing OpenCode users to use those resources. Although their computing capacity should now be greater than before.

Scott: Is that why they don’t want you to use it? Many people are saying, “What’s the difference? I paid for the subscription—why can’t I use it anywhere?” Others speculate they want training data or control. But the truth is actually simple: they’re just limited in computing power?

Dax: Actually, every company is essentially a funnel—you place something at the top to attract users, and ideally, they convert all the way through to the bottom.

They designed Claude Code as a top-of-funnel product—a highly consumer-facing tool. You use it, your company starts using it, and then your company begins paying by token. But if users access it through OpenCode, this conversion funnel may break, because in OpenCode you can freely switch to other models. If you don’t like Claude, you can instantly switch to the latest popular model.

The second reason is the competitive demand for computing power: anything you invest at the top of the funnel must prove it will eventually return to the bottom of the funnel. If you’re a consumer-facing company, you can afford to be more flexible in this regard.

Wes: Have you ever thought about whether a model might emerge in the future that has no API at all, and you can only use it through their app? Like ElevenLabs—they have a great app, but you have to subscribe to a monthly plan; there’s no pay-as-you-go option. Do you think this will happen?

Dax: Yes, this again reflects the company’s internal structure. The product team would strongly support this approach—they could say, “We can build a highly specialized model, create a dedicated product around it, and bundle the two together; to use the model, you must use our product.” This is a perfect lock-in strategy for product-oriented teams.

But sales teams have revenue targets, and they’ll say: “Our revenue target is $100 billion. Your exclusive API or exclusive product model can at best generate $50 billion—so who will make up the remaining $50 billion gap?” The sales team will insist: “No, the model must be integrated into the API so we can better meet our targets.” As long as this internal conflict persists, the organization will struggle to justify sacrificing some revenue in exchange for market share.

As these labs increasingly move into the product layer, they effectively have an “unfair button,” and I’m not surprised they’ll press it at some point. They’ll justify it in strange ways, such as, “This model is too dangerous—it’s only safe within our framework, and we can’t allow it to be used in other frameworks.” This isn’t the real reason, but it’s likely what they’ll say.

Wes: Regarding Fable’s security issues, are all these new models unsafe? The government says they’re unsafe—is that true, or just hype?

Dax: I think many things are true, and they may conflict with each other—these models do have the potential to cause significant harm. It’s reasonable for governments to say we need some form of review before release. If you’re at a large company like Meta, when they launch a product feature—such as uploading profile pictures—they must prove to regulators that they’re implementing child pornography filters. At that scale, even the most minor in-app features face an extreme level of regulation.

But the problem is, if this process is very naive or corrupt, the end result won’t be comprehensive approval of the model and broad access for everyone—instead, it could lead to unequal access through government procedures. That would be a very bad outcome, and I hope it doesn’t happen. I’d much prefer to see a more boring result: every time they release a new model, they simply go through a one-month process.

On the other hand, this isn’t entirely a rational issue. I don’t think these labs should start wildly claiming to possess “nuclear weapons,” as that would attract political attention. It’s like playing with a bomb—it could end up in a boring situation, or it could turn into something truly terrible, such as improper or overly aggressive regulation that harms the entire economy. So I hope these labs exercise greater caution in shaping public perception, because you can’t go around claiming you have nuclear bombs and expect nothing to happen.

AI interaction is moving toward hands-free operation.

Scott: Let’s talk about MCP, Skill, and the tools used for AI programming. What’s truly worth paying attention to and using? What are you all using?

Dax: Most of us have very basic personal setups. What’s really interesting is our internal Discord bot, which has far more MCPs and skills than our individual configurations. We have this thing called “Gang Growth,” conceived by Kit Lang. Whenever we hit a roadblock in design—whether it’s business logic, API design, or implementation—we voice-input our prompt into the Discord bot and tag @OpenCode, which acts like a collaborative tool.

This bot is connected to the company’s entire data lake—I can ask it, “How much did all Go subscribers with overage billing enabled spend in the past week?” and it can calculate the answer. The shift in our team’s workflow is this: there’s basically no reason to @ someone else anymore. If you have a question, first @OpenCode. If others see it, they’ll jump in to help—but OpenCode often handles it on its own.

Scott: But what if the bot needs to return information to you? Everyone is currently discussing MCP UI or directly generating HTML files—what do you think will be the future way for coding agents to display information?

Dax: We will definitely add some kind of artifacts functionality to OpenCode so it can generate and send you documentation. It uses HTML with SVG for visualization—it’s really cool. This doesn’t require anything special; it just leverages the Agent’s capabilities. As for the MCP UI, I haven’t dug into it deeply yet, but I think we’ll support it in our desktop app, especially as we start focusing more on non-technical users, since I believe their questions and the tasks they need to accomplish could benefit from a more dynamic or richer UI.

Our team is now obsessed with voice prompting—even when messaging each other on Discord, we use voice because we hate typing. When you can just speak to it, I’d much rather roughly describe what I need to do than type out every detail. If I had to type everything, it would be terrible. But with voice, it’s incredibly fast and runs locally.

Scott: I bought a foot pedal because there were too many voice commands. One pedal is for "input," another for "trigger dictation," and another to switch tabs. I just sit there using it—it’s pretty great.

Dax: Many people are skeptical about this, and I completely understand—I only started doing it after seeing Kit do it. When you see someone else doing it, something clicks in your mind. If you’ve never tried it, it might feel awkward. But it’s actually the most natural thing—you can ramble, mix things up, or stumble over your words, and it’s all fine because LLMs are great at understanding what you truly mean.

Wes: Are you using Kit's Hex app?

Dax: I use Handy on the main machine and Hex on Mac. The model is great—that's what matters.

Wes: My trigger is simple—I just double-click a small button on my mouse. Someone is also making a ring that you can tap; they’re sending me one, and I’ll give it a try.

Dax: I still spend most of my time with my fingers on the keyboard, so I set up a shortcut key.

Wes: Is there anything we haven’t covered that you’d really like to share? For example, any personal insights of yours?

Dax: I'm really excited about the upcoming next-generation models. Usually, when a new model is released, they all feel the same—I've even posted about this frustration. But this is the first time I feel like these models might actually be widely adopted. They've already been technically released; it's just that governments haven't allowed ordinary users to access them yet.

Wes: There are various benchmarks and scores out there, and people are saying, “It feels much better.” Do you think we’ll eventually have a truly meaningful benchmark?

Dax: To be honest, I don’t look at benchmarks at all anymore—I’m not even sure I ever really did. I feel like these scores have long since become background noise. We all know the numbers are going up, and they’re rising more than our competitors’, but whenever our competitors launch, their scores jump even higher—what’s the point of any of this?

So now I only look at qualitative feedback. I enjoy seeing what people are building or what they’re able to do with the models. You obviously can’t get this kind of feedback at a scale of millions of data points, but these products are inherently fuzzy—ultimately, it comes down to: Are users happy? Are users frustrated? That’s why I pay close attention to our team’s token usage. If the curve is rising, it means something is working, that people are enjoying something. We have Claude fans, GPT fans, and open-source model enthusiasts on our team, so we have solid coverage across all directions.

Scott: Is there anything you've particularly enjoyed recently that you'd like to share?

Dax: Of course, it's exe.dev, which I mentioned earlier. If you want to experience the concept of "cloud machines," it's a brilliantly designed product that executes the idea exceptionally well. It gives me the same feeling as Tailscale—something that just works, and exe.dev has that same vibe. I particularly love products that nail a specific niche, and this one perfectly occupies a strange vacuum. You can rent servers from AWS or elsewhere, but it's hard to easily find a server with fast persistent storage at a reasonable price. This gap was previously filled only by shady VPS providers who would appear and then disappear.

When I first set up my development machine years ago, I wanted the cheapest option and ended up choosing a VPS provider in Miami. The guy actually faked his own death, and then the server went offline. He sent everyone an email saying, “I’m going to have a medical procedure and will be unreachable for three days,” but three days later, the server truly went down. I thought, “Oh no, something’s wrong?” A month passed, and no one could reach him. Eventually, I found a forum post where someone traced him back to having previously run another VPS service that vanished under similar circumstances. The market for cheap, high-performance servers was unbelievably unreliable. To this day, I still don’t understand what kind of scam this was—I paid him for a service, so why did he just disappear?

Wes: What would you like to recommend to the audience?

Dax: If you're working on something of your own, I recommend OpenTUI—it's an excellent way to build TUIs. You can create high-performance TUIs using bindings for React, SolidJS, or even Vue. OpenCode was built with it, and we're actively moving toward version 1.0. There's been a recent resurgence in terminal-based products and applications.

Scott: Who else is using this? Is it also the new Grok build or something from xAI?

Dax: Grok's CLI is done extremely well—executes beautifully and performs excellently—but it's written in Rust, and they're probably using the Ratatouille library. However, the new Hermes proxy TUI is built with OpenTUI. The community is growing rapidly, and now whenever I see a TUI on my timeline, it's most likely OpenTUI, especially since you can write it using vibe coding, because it's essentially React.