• Survey Methodology: Pew Research Center conducted two surveys in 2025: NPORS with 5,022 U.S. adults using multimode sampling, and ATP with 5,123 adults focusing on frequency of use for select platforms.
• Top Platforms: 84% of U.S. adults use YouTube, 71% use Facebook, and 50% use Instagram, with smaller shares for TikTok (37%) and WhatsApp (32%).
• Emerging Platforms: About 10% or fewer use Threads, Bluesky, and Truth Social, as reported in the 2025 survey.
• Growth Trends: TikTok usage rose to 37% from 21% in 2021; Instagram to 50% from 40%; WhatsApp to 33% from 23%; Reddit to 26% from 18%.
• Age Differences: Adults under 30 show higher usage of Instagram (80%), Snapchat, TikTok, and Reddit compared to those 65 and older (e.g., 19% for Instagram).
• Demographic Variations: Women exceed men in Facebook, Instagram, and TikTok use; Black and Hispanic adults lead in Instagram and TikTok; college-educated more likely for Reddit and WhatsApp.
• Partisan Differences: Democrats more likely to use WhatsApp, Reddit, TikTok, Bluesky, and Threads; Republicans lead in X (24% vs. 19%) and Truth Social.
• Daily Usage: 50% visit Facebook and YouTube daily; 24% use TikTok daily; younger adults (18-29) report 50% daily TikTok use versus 5% for those 65 and older.

How we did this

To better understand which social media platforms Americans use, Pew Research Center surveyed 5,022 U.S. adults from Feb. 5 to June 18, 2025. SSRS conducted this National Public Opinion Reference Survey (NPORS) for the Center using address-based sampling and a multimode protocol that included web, mail and phone. This way nearly all U.S. adults have a chance of selection. The survey is weighted to be representative of the U.S. adult population by gender, race and ethnicity, education, and other categories.

Surveys fielded before 2023 were conducted via phone. For more on the mode shift in 2023, read our Q&A.

Here are the questions from this survey used for this report, the topline and the methodology.

We also surveyed 5,123 U.S. adults from Feb. 24 to March 2, 2025, to understand how frequently Americans use four specific platforms: YouTube, Facebook, TikTok and X (formerly known as Twitter). Everyone who took part in this survey is a member of the Center’s American Trends Panel (ATP), a group of people recruited through national, random sampling of residential addresses who have agreed to take surveys regularly. This kind of recruitment gives nearly all U.S. adults a chance of selection. Interviews were conducted either online or by telephone with a live interviewer. The survey is weighted to be representative of the U.S. adult population by gender, race, ethnicity, partisan affiliation, education and other factors. Read more about the ATP’s methodology.

Here are the questions from this survey used for this report, the topline and the methodology.

Even as debates continue about the role of social media in our country, including on censorship and its impact on youth, Americans use a range of online platforms, and many do so daily.

Which online platforms do Americans most commonly use?

YouTube and Facebook remain the most widely used online platforms. The vast majority of U.S. adults (84%) say they ever use YouTube. Most Americans (71%) also report using Facebook. These findings are according to a Pew Research Center survey of 5,022 U.S. adults conducted Feb. 5-June 18, 2025.

Half of adults say they use Instagram, making it the only other platform in our survey used by at least 50% of Americans.

Smaller shares use the other sites and apps we asked about, such as TikTok (37%) and WhatsApp (32%). Somewhat fewer say the same of Reddit, Snapchat and X (formerly Twitter).

This year we also asked about three platforms that are used by about one-in-ten or fewer U.S. adults: Threads, Bluesky, and Truth Social.

Center studies also find that YouTube is the most widely used online platform among U.S. teens, like it is among U.S. adults.

Changes in use of online platforms

The Center has long tracked use of many of these platforms. Over the past few years, four of them have grown in overall use among U.S. adults – TikTok, Instagram, WhatsApp and Reddit.

TikTok: 37% of U.S. adults report using the platform, which is slightly up from last year and up from 21% in 2021.

Instagram: Half of U.S. adults now report using it, which is on par with last year but up from 40% in 2021.

WhatsApp and Reddit: About a third say they use WhatsApp, up from 23% in 2021. And 26% today report using Reddit, compared with 18% four years ago.   

While YouTube and Facebook continue to sit at the top, the shares of Americans who report using them have remained relatively stable in recent years.1

Large age gaps in use of many platforms

Adults under 30 are more likely than older adults to use most of these platforms. Consistent with previous Center data, the survey finds that the youngest adults particularly stand out in their use of Instagram, Snapchat, TikTok and Reddit. 

For instance, eight-in-ten adults ages 18 to 29 say they use Instagram. This is higher than the shares seen among older age groups – especially adults ages 65 and older (19%).

YouTube and Facebook are the only sites asked about that a majority in all age groups use, though for YouTube, the youngest adults are still the most likely to do so. This differs from Facebook, where 30- to 49-year-olds most commonly say they use it (80%).

Differences by gender, race and ethnicity, education, and party

While some of the biggest demographic differences in social media use are across age groups, use also varies by other factors.

By gender

Women stand out in their use of several platforms, including Facebook, Instagram and TikTok. For instance, more than half of women report using Instagram (55%), compared with under half of men (44%). Alternatively, men are more likely to report using platforms such as X and Reddit.

By race and ethnicity

White adults are less likely than Black and Hispanic adults – and sometimes Asian adults – to use online platforms such as Instagram, TikTok and WhatsApp. For instance, 45% of White adults report using Instagram, compared with larger shares among Hispanic (62%), Asian (58%) and Black adults (54%). 

By education

Americans with higher levels of formal education are more likely to report using some sites and apps, including Reddit, WhatsApp and Instagram. With Reddit, for example, about four-in-ten adults with at least a college degree say they use the platform. Smaller shares of those with some college education (28%) or a high school diploma or less education (15%) say this.

By contrast, those with some college or less education are more likely to use TikTok than those with at least a college degree.

By party

Democrats and Democratic-leaning independents are more likely than Republicans and Republican leaners to report using WhatsApp, Reddit, TikTok, Bluesky and Threads.  

By comparison, Republicans are more likely to say they use X and Truth Social. For instance, 24% of Republicans now report using X, compared with 19% of Democrats. However, just two years ago Democrats were more likely to report using the platform than Republicans (26% vs. 20%).

Frequency of social media use

In addition to understanding if people use a particular site or app, we also asked Americans how frequently they do so. These questions were asked in a separate survey of 5,123 U.S. adults conducted from Feb. 24 to March 2, 2025.

Greater shares of Americans visit Facebook and YouTube daily than other sites. About half of U.S. adults say they visit each of these platforms at least once a day. This includes 37% who visit Facebook several times a day, and 33% who say the same of YouTube.

About a quarter (24%) say they are daily users of TikTok. Fewer (10%) report daily use of X.

Daily use of social media, by age

Younger adults are far more likely than older adults to report using YouTube and TikTok daily.

Roughly half of 18- to 29-year-olds say they go on TikTok at least once a day, compared with just 5% of adults ages 65 and older.

There is also an age gap for X, though it’s more modest.

For Facebook, the two middle age groups are most likely to report going on it daily: 58% of 30- to 49-year-olds and 54% of 50- to 64-year-olds say this.

• LLMOps Evolution: Discussion on the shift from MLOps to LLMOps, highlighting changes in infrastructure and pipelines for handling larger, generative models.
• Tool Changes for Engineers: Daily tools for LLMOps focus on cost control, latency, throughput, and dynamic monitoring, differing from traditional MLOps containerization.
• Transition Challenges: MLOps engineers upskill through evaluations and infrastructure, while software engineers adapt easier viewing LLMs as end-to-end systems.
• Agentic Systems Definition: Agents handle intent understanding and execution, workflows manage planning, treating systems as distributed computing problems.
• Reliability in Pipelines: Compounding errors in multi-agent workflows require microservices architecture, consensus mechanisms, and research like MassGen.
• Framework Limitations: Many agentic and evaluation frameworks are unreliable or bloated, leading companies to develop in-house solutions for debugging and optimization.
• Observability Approach: Existing tools suffice with new frameworks for anomaly detection via logging and ML models, emphasizing telemetry over static dashboards.
• Future Priorities: Emphasis on model profiling, dynamic RL environments with curriculum learning, data engineering gains, and learning distributed systems like Ray.

Generative AI in the Real World

Generative AI in the Real World: The LLMOps Shift with Abi Aryan

00:00 / 32m 16s

RSS Feed

Share

[](https://www.facebook.com/sharer/sharer.php?u=https://www.oreilly.com/radar/podcast/generative-ai-in-the-real-world-the-llmops-shift-with-abi-aryan/&t=Generative AI in the Real World: The LLMOps Shift with Abi Aryan "Share on Facebook")[](https://twitter.com/intent/tweet?text=https://www.oreilly.com/radar/podcast/generative-ai-in-the-real-world-the-llmops-shift-with-abi-aryan/&url=Generative AI in the Real World: The LLMOps Shift with Abi Aryan "Share on Twitter")

Link

Embed

MLOps is dead. Well, not really, but for many the job is evolving into LLMOps. In this episode, Abide AI founder and LLMOps author Abi Aryan joins Ben to discuss what LLMOps is and why it’s needed, particularly for agentic AI systems. Listen in to hear why LLMOps requires a new way of thinking about observability, why we should spend more time understanding human workflows before mimicking them with agents, how to do FinOps in the age of generative AI, and more.

About the Generative AI in the Real World podcast: In 2023, ChatGPT put AI on everyone’s agenda. In 2025, the challenge will be turning those agendas into reality. In Generative AI in the Real World, Ben Lorica interviews leaders who are building with AI. Learn from their experience to help put AI to work in your enterprise.

Check out other episodes of this podcast on the O’Reilly learning platform.

Transcript

This transcript was created with the help of AI and has been lightly edited for clarity.

00.00: All right, so today we have Abi Aryan. She is the author of the O’Reilly book on LLMOps as well as the founder of Abide AI. So, Abi, welcome to the podcast. 

00.19: Thank you so much, Ben. 

00.21: All right. Let’s start with the book, which I confess, I just cracked open: LLMOps. People probably listening to this have heard of MLOps. So at a high level, the models have changed: They’re bigger, they’re generative, and so on and so forth. So since you’ve written this book, have you seen a wider acceptance of the need for LLMOps? 

00.51: I think more recently there are more infrastructure companies. So there was a conference happening recently, and there was this sort of perception or messaging across the conference, which was “MLOps is dead.” Although I don’t agree with that. 

There’s a big difference that companies have started to pick up on more recently, as the infrastructure around the space has sort of started to improve. They’re starting to realize how different the pipelines were that people managed and grew, especially for the older companies like Snorkel that were in this space for years and years before large language models came in. The way they were handling data pipelines—and even the observability platforms that we’re seeing today—have changed tremendously.

01.40: What about, Abi, the general. . .? We don’t have to go into specific tools, but we can if you want. But, you know, if you look at the old MLOps person and then fast-forward, this person is now an LLMOps person. So on a day-to-day basis [has] their suite of tools changed? 

02.01: Massively. I think for an MLOps person, the focus was very much around “This is my model. How do I containerize my model, and how do I put it in production?” That was the entire problem and, you know, most of the work was around “Can I containerize it? What are the best practices around how I arrange my repository? Are we using templates?” 

Drawbacks happened, but not as much because most of the time the stuff was tested and there was not too much indeterministic behavior within the models itself. Now that has changed.

02.38: [For] most of the LLMOps engineers, the biggest job right now is doing FinOps really, which is controlling the cost because the models are massive. The second thing, which has been a big difference, is we have shifted from “How can we build systems?” to “How can we build systems that can perform, and not just perform technically but perform behaviorally as well?”: “What is the cost of the model? But also what is the latency? And see what’s the throughput looking like? How are we managing the memory across different tasks?” 

The problem has really shifted when we talk about it. . . So a lot of focus for MLOps was “Let’s create fantastic dashboards that can do everything.” Right now it’s no matter which dashboard you create, the monitoring is really very dynamic. 

03.32: Yeah, yeah. As you were talking there, you know, I started thinking, yeah, of course, obviously now the inference is essentially a distributed computing problem, right? So that was not the case before. Now you have different phases even of the computation during inference, so you have the prefill phase and the decode phase. And then you might need different setups for those. 

So anecdotally, Abi, did the people who were MLOps people successfully migrate themselves? Were they able to upskill themselves to become LLMOps engineers?

04.14: I know a couple of friends who were MLOps engineers. They were teaching MLOps as well—Databricks folks, MVPs. And they were now transitioning to LLMOps.

But the way they started is they started focusing very much on, “Can you do evals for these models? They weren’t really dealing with the infrastructure side of it yet. And that was their slow transition. And right now they’re very much at that point where they’re thinking, “OK, can we make it easy to just catch these problems within the model—inferencing itself?”

04.49: A lot of other problems still stay unsolved. Then the other side, which was like a lot of software engineers who entered the field and became AI engineers, they have a much easier transition because software. . . The way I look at large language models is not just as another machine learning model but literally like software 3.0 in that way, which is it’s an end-to-end system that will run independently.

Now, the model isn’t just something you plug in. The model is the product tree. So for those people, most software is built around these ideas, which is, you know, we need a strong cohesion. We need low coupling. We need to think about “How are we doing microservices, how the communication happens between different tools that we’re using, how are we calling up our endpoints, how are we securing our endpoints?”

Those questions come easier. So the system design side of things comes easier to people who work in traditional software engineering. So the transition has been a little bit easier for them as compared to people who were traditionally like MLOps engineers. 

05.59: And hopefully your book will help some of these MLOps people upskill themselves into this new world.

Let’s pivot quickly to agents. Obviously it’s a buzzword. Just like anything in the space, it means different things to different teams. So how do you distinguish agentic systems yourself?

06.24: There are two words in the space. One is agents; one is agent workflows. Basically agents are the components really. Or you can call them the model itself, but they’re trying to figure out what you meant, even if you forgot to tell them. That’s the core work of an agent. And the work of a workflow or the workflow of an agentic system, if you want to call it, is to tell these agents what to actually do. So one is responsible for execution; the other is responsible for the planning side of things. 

07.02: I think sometimes when tech journalists write about these things, the general public gets the notion that there’s this monolithic model that does everything. But the reality is, most teams are moving away from that design as you, as you describe.

So they have an agent that acts as an orchestrator or planner and then parcels out the different steps or tasks needed, and then maybe reassembles in the end, right?

07.42: Coming back to your point, it’s now less of a problem of machine learning. It’s, again, more like a distributed systems problem because we have multiple agents. Some of these agents will have more load—they will be the frontend agents, which are communicating to a lot of people. Obviously, on the GPUs, these need more distribution.

08.02: And when it comes to the other agents that may not be used as much, they can be provisioned based on “This is the need, and this is the availability that we have.” So all of that provisioning again is a problem. The communication is a problem. Setting up tests across different tasks itself within an entire workflow, now that becomes a problem, which is where a lot of people are trying to implement context engineering. But it’s a very complicated problem to solve. 

08.31: And then, Abi, there’s also the problem of compounding reliability. Let’s say, for example, you have an agentic workflow where one agent passes off to another agent and yet to another third agent. Each agent may have a certain amount of reliability, but it compounds over time. So it compounds across this pipeline, which makes it more challenging. 

09.02: And that’s where there’s a lot of research work going on in the space. It’s an idea that I’ve talked about in the book as well. At that point when I was writing the book, especially chapter four, in which a lot of these were described, most of the companies right now are [using] monolithic architecture, but it’s not going to be able to sustain as we go towards application.

We have to go towards a microservices architecture. And the moment we go towards microservices architecture, there are a lot of problems. One will be the hardware problem. The other is consensus building, which is. . . 

Let’s say you have three different agents spread across three different nodes, which would be running very differently. Let’s say one is running on an edge one hundred; one is running on something else. How can we achieve consensus if even one of the nodes ends up winning? So that’s open research work [where] people are trying to figure out, “Can we achieve consensus in agents based on whatever answer the majority is giving, or how do we really think about it?” It should be set up at a threshold at which, if it’s beyond this threshold, then you know, this perfectly works.

One of the frameworks that is trying to work in this space is called MassGen—they’re working on the research side of solving this problem itself in terms of the tool itself. 

10.31: By the way, even back in the microservices days in software architecture, obviously people went overboard too. So I think that, as with any of these new things, there’s a bit of trial and error that you have to go through. And the better you can test your systems and have a setup where you can reproduce and try different things, the better off you are, because many times your first stab at designing your system may not be the right one. Right? 

11.08: Yeah. And I’ll give you two examples of this. So AI companies tried to use a lot of agentic frameworks. You know people have used Crew; people have used n8n, they’ve used. . . 

11.25: Oh, I hate those! Not I hate. . . Sorry. Sorry, my friends and crew. 

11.30: And 90% of the people working in this space seriously have already made that transition, which is “We are going to write it ourselves. 

The same happened for evaluation: There were a lot of evaluation tools out there. What they were doing on the surface is literally just tracing, and tracing wasn’t really solving the problem—it was just a beautiful dashboard that doesn’t really serve much purpose. Maybe for the business teams. But at least for the ML engineers who are supposed to debug these problems and, you know, optimize these systems, essentially, it was not giving much other than “What is the error response that we’re getting to everything?”

12.08: So again, for that one as well, most of the companies have developed their own evaluation frameworks in-house, as of now. The people who are just starting out, obviously they’ve done. But most of the companies that started working with large language models in 2023, they’ve tried every tool out there in 2023, 2024. And right now more and more people are staying away from the frameworks and launching and everything.

People have understood that most of the frameworks in this space are not superreliable.

12.41: And [are] also, honestly, a bit bloated. They come with too many things that you don’t need in many ways. . .

12:54: Security loopholes as well. So for example, like I reported one of the security loopholes with LangChain as well, with LangSmith back in 2024. So those things obviously get reported by people [and] get worked on, but the companies aren’t really proactively working on closing those security loopholes. 

13.15: Two open source projects that I like that are not specifically agentic are DSPy and BAML. Wanted to give them a shout out. So this point I’m about to make, there’s no easy, clear-cut answer. But one thing I noticed, Abi, is that people will do the following, right? I’m going to take something we do, and I’m going to build agents to do the same thing. But the way we do things is I have a—I’m just making this up—I have a project manager and then I have a designer, I have role B, role C, and then there’s certain emails being exchanged.

So then the first step is “Let’s replicate not just the roles but kind of the exchange and communication.” And sometimes that actually increases the complexity of the design of your system because maybe you don’t need to do it the way the humans do it. Right? Maybe if you go to automation and agents, you don’t have to over-anthropomorphize your workflow. Right. So what do you think about this observation? 

14.31: A very interesting analogy I’ll give you is people are trying to replicate intelligence without understanding what intelligence is. The same for consciousness. Everybody wants to replicate and create consciousness without understanding consciousness. So the same is happening with this as well, which is we are trying to replicate a human workflow without really understanding how humans work.

14.55: And sometimes humans may not be the most efficient thing. Like they exchange five emails to arrive at something. 

15.04: And humans are never context defined. And in a very limiting sense. Even if somebody’s job is to do editing, they’re not just doing editing. They are looking at the flow. They are looking for a lot of things which you can’t really define. Obviously you can over a period of time, but it needs a lot of observation to understand. And that skill also depends on who the person is. Different people have different skills as well. Most of the agentic systems right now, they’re just glorified Zapier IFTTT routines. That’s the way I look at them right now. The if recipes: If this, then that.

15.48: Yeah, yeah. Robotic process automation I guess is what people call it. The other thing that people I don’t think understand just reading the popular tech press is that agents have levels of autonomy, right? Most teams don’t actually build an agent and unleash it full autonomous from day one.

I mean, I guess the analogy would be in self-driving cars: They have different levels of automation. Most enterprise AI teams realize that with agents, you have to kind of treat them that way too, depending on the complexity and the importance of the workflow. 

So you go first very much a human is involved and then less and less human over time as you develop confidence in the agent.

But I think it’s not good practice to just kind of let an agent run wild. Especially right now. 

16.56: It’s not, because who’s the person answering if the agent goes wrong? And that’s a question that has come up often. So this is the work that we’re doing at Abide really, which is trying to create a decision layer on top of the knowledge retrieval layer.

17.07: Most of the agents which are built using just large language models. . . LLMs—I think people need to understand this part—are fantastic at knowledge retrieval, but they do not know how to make decisions. If you think agents are independent decision makers and they can figure things out, no, they cannot figure things out. They can look at the database and try to do something.

Now, what they do may or may not be what you like, no matter how many rules you define across that. So what we really need to develop is some sort of symbolic language around how these agents are working, which is more like trying to give them a model of the world around “What is the cause and effect, with all of these decisions that you’re making? How do we prioritize one decision where the. . .? What was the reasoning behind that so that entire decision making reasoning here has been the missing part?”

18.02: You brought up the topic of observability. There’s two schools of thought here as far as agentic observability. The first one is we don’t need new tools. We have the tools. We just have to apply [them] to agents. And then the second, of course, is this is a new situation. So now we need to be able to do more. . . The observability tools have to be more capable because we’re dealing with nondeterministic systems.

And so maybe we need to capture more information along the way. Chains of decision, reasoning, traceability, and so on and so forth. Where do you fall in this kind of spectrum of we don’t need new tools or we need new tools? 

18.48: We don’t need new tools, but we certainly need new frameworks, and especially a new way of thinking. Observability in the MLOps world—fantastic; it was just about tools. Now, people have to stop thinking about observability as just visibility into the system and start thinking of it as an anomaly detection problem. And that was something I’d written in the book as well. Now it’s no longer about “Can I see what my token length is?” No, that’s not enough. You have to look for anomalies at every single part of the layer across a lot of metrics. 

19.24: So your position is we can use the existing tools. We may have to log more things. 

19.33: We may have to log more things, and then start building simple ML models to be able to do anomaly detection. 

Think of managing any machine, any LLM model, any agent as really like a fraud detection pipeline. So every single time you’re looking for “What are the simplest signs of fraud?” And that can happen across various factors. But we need more logging. And again you don’t need external tools for that. You can set up your own loggers as well.

Most of the people I know have been setting up their own loggers within their companies. So you can simply use telemetry to be able to a.) define a set and use the general logs, and b.) be able to define your own custom logs as well, depending on your agent pipeline itself. You can define “This is what it’s trying to do” and log more things across those things, and then start building small machine learning models to look for what’s going on over there.

20.36: So what is the state of “Where we are? How many teams are doing this?” 

20.42: Very few. Very, very few. Maybe just the top bits. The ones who are doing reinforcement learning training and using RL environments, because that’s where they’re getting their data to do RL. But people who are not using RL to be able to retrain their model, they’re not really doing much of this part; they’re still depending very much on external accounts.

21.12: I’ll get back to RL in a second. But one topic you raised when you pointed out the transition from MLOps to LLMOps was the importance of FinOps, which is, for our listeners, basically managing your cloud computing costs—or in this case, increasingly mastering token economics. Because basically, it’s one of these things that I think can bite you.

For example, the first time you use Claude Code, you go, “Oh, man, this tool is powerful.” And then boom, you get an email with a bill. I see, that’s why it’s powerful. And you multiply that across the board to teams who are starting to maybe deploy some of these things. And you see the importance of FinOps.

So where are we, Abi, as far as tooling for FinOps in the age of generative AI and also the practice of FinOps in the age of generative AI? 

22.19: Less than 5%, maybe even 2% of the way there. 

22:24: Really? But obviously everyone’s aware of it, right? Because at some point, when you deploy, you become aware. 

22.33: Not enough people. A lot of people just think about FinOps as cloud, basically the cloud cost. And there are different kinds of costs in the cloud. One of the things people are not doing enough is not profiling their models properly, which is [determining] “Where are the costs really coming from? Our models’ compute power? Are they taking too much RAM? 

22.58: Or are we using reasoning when we don’t need it?

23.00: Exactly. Now that’s a problem we solve very differently. That’s where yes, you can do kernel fusion. Define your own custom kernels. Right now there’s a massive number of people who think we need to rewrite kernels for everything. It’s only going to solve one problem, which is the compute-bound problem. But it’s not going to solve the memory-bound problem. Your data engineering pipelines aren’t what’s going to solve your memory-bound problems.

And that’s where most of the focus is missing. I’ve mentioned it in the book as well: Data engineering is the foundation of first being able to solve the problems. And then we moved to the compute-bound problems. Do not start optimizing the kernels over there. And then the third part would be the communication-bound problem, which is “How do we make these GPUs talk smarter with each other? How do we figure out the agent consensus and all of those problems?”

Now that’s a communication problem. And that’s what happens when there are different levels of bandwidth. Everybody’s dealing with the internet bandwidth as well, the kind of serving speed as well, different kinds of cost and every kind of transitioning from one node to another. If we’re not really hosting our own infrastructure, then that’s a different problem, because it depends on “Which server do you get assigned your GPUs on again?”

24.20: Yeah, yeah, yeah. I want to give a shout out to Ray—I’m an advisor to Anyscale—because Ray basically is built for these sorts of pipelines because it can do fine-grained utilization and help you decide between CPU and GPU. And just generally, you don’t think that the teams are taking token economics seriously?

I guess not. How many people have I heard talking about caching, for example? Because if it’s a prompt that [has been] answered before, why do you have to go through it again? 

25.07: I think plenty of people have started implementing KV caching, but they don’t really know. . . Again, one of the questions people don’t understand is “How much do we need to store in the memory itself, and how much do we need to store in the cache?” which is the big memory question. So that’s the one I don’t think people are able to solve. A lot of people are storing too much stuff in the cache that should actually be stored in the RAM itself, in the memory.

And there are generalist applications that don’t really understand that this agent doesn’t really need access to the memory. There’s no point. It’s just lost in the throughput really. So I think the problem isn’t really caching. The problem is that differentiation of understanding for people. 

25.55: Yeah, yeah, I just threw that out as one element. Because obviously there’s many, many things to mastering token economics. So you, you brought up reinforcement learning. A few years ago, obviously people got really into “Let’s do fine-tuning.” But then they quickly realized. . . And actually fine-tuning became easy because basically there became so many services where you can just focus on labeled data. You upload your labeled data, boom, come back from lunch, you have a fine-tuned model.

But then people realize that “I fine-tuned, but the model that results isn’t really as good as my fine-tuning data.” And then obviously RAG and context engineering came into the picture. Now it seems like more people are again talking about reinforcement learning, but in the context of LLMs. And there’s a lot of libraries, many of them built on Ray, for example. But it seems like what’s missing, Abi, is that fine-tuning got to the point where I can sit down a domain expert and say, “Produce labeled data.” And basically the domain expert is a first-class participant in fine-tuning.

As best I can tell, for reinforcement learning, the tools aren’t there yet. The UX hasn’t been figured out in order to bring in the domain experts as the first-class citizen in the reinforcement learning process—which they need to be because a lot of the stuff really resides in their brain. 

27.45: The big problem here, and very, very much to the point of what you pointed out, is the tools aren’t really there. And one very specific thing I can tell you is most of the reinforcement learning environments that you’re seeing are static environments. Agents are not learning statically. They are learning dynamically. If your RL environment cannot adapt dynamically, which basically in 2018, 2019, emerged as the OpenAI Gym and a lot of reinforcement learning libraries were coming out.

28.18: There is a line of work called curriculum learning, which is basically adapting your model’s difficulty to the results itself. So basically now that can be used in reinforcement learning, but I’ve not seen any practical implementation of using curriculum learning for reinforcement learning environments. So people create these environments—fantastic. They work well for a little bit of time, and then they become useless.

So that’s where even OpenAI, Anthropic, those companies are struggling as well. They’ve paid heavily in contracts, which are yearlong contracts to say, “Can you build this vertical environment? Can you build that vertical environment?” and that works fantastically But once the model learns on it, then there’s nothing else to learn. And then you go back into the question of, “Is this data fresh? Is this adaptive with the world?” And it becomes the same RAG problem over again. 

29.18: So maybe the problem is with RL itself. Maybe maybe we need a different paradigm. It’s just too hard. 

Let me close by looking to the future. The first thing is—the space is moving so hard, this might be an impossible question to ask, but if you look at, let’s say, 6 to 18 months, what are some things in the research domain that you think are not being talked enough about that might produce enough practical utility that we will start hearing about them in 6 to 12, 6 to 18 months?

29.55: One is how to profile your machine learning models, like the entire systems end-to-end. A lot of people do not understand them as systems, but only as models. So that’s one thing which will make a massive amount of difference. There are a lot of AI engineers today, but we don’t have enough system design engineers.

30.16: This is something that Ion Stoica at Sky Computing Lab has been giving keynotes about. Yeah. Interesting. 

30.23: The second part is. . . I’m optimistic about seeing curriculum learning applied to reinforcement learning as well, where our RL environments can adapt in real time so when we train agents on them, they are dynamically adapting as well. That’s also [some] of the work being done by labs like Circana, which are working in artificial labs, artificial light frame, all of that stuff—evolution of any kind of machine learning model accuracy. 

30.57: The third thing where I feel like the communities are falling behind massively is on the data engineering side. That’s where we have massive gains to get. 

31.09: So on the data engineering side, I’m happy to say that I advise several companies in the space that are completely focused on tools for these new workloads and these new data types. 

Last question for our listeners: What mindset shift or what skill do they need to pick up in order to position themselves in their career for the next 18 to 24 months?

31.40: For anybody who’s an AI engineer, a machine learning engineer, an LLMOps engineer, or an MLOps engineer, first learn how to profile your models. Start picking up Ray very quickly as a tool to just get started on, to see how distributed systems work. You can pick the LLM if you want, but start understanding distributed systems first. And once you start understanding those systems, then start looking back into the models itself. 

32.11: And with that, thank you, Abi.

• Churchill quote: Applied to reported US-Russia draft framework as end of beginning in Ukraine peace process.
• Negotiators: US envoy Steve Witkoff, Russian envoy Kirill Dmitriev, possibly JD Vance, Marco Rubio, Jared Kushner.
• Deal status: Trump administration sees imminent agreement; Russia stresses none reached; uncertainties on concessions and Ukrainian acceptance.
• Donbas terms: Ukraine withdraws from 14% held area, to be demilitarized under neutral peacekeepers.
• Other regions: Ceasefire along front lines in Zaporizhia and Kherson; Russia abandons full provincial claims.
• Sovereignty concessions: US recognizes Russian control over Donbas and Crimea, implying sanctions relief; Ukraine not required to.
• Military and security: No long-range missiles for Ukraine, force size limits, US guarantees, Russian okay for EU but not NATO membership.
• Additional elements: Russian as second official language in Ukraine; proposals for UN/BRICS ratification, suspended sanctions, stockpiled arms.

When it comes to the reported draft framework agreement between the U.S. and Russia, and its place in the Ukraine peace process, a quote by Winston Churchill (on the British victory at El Alamein) may be appropriate: “Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.” This is because at long last, this document engages with the concrete, detailed issues that will have to be resolved if peace is to be achieved.

The plan has apparently been worked out between U.S. envoy Steve Witkoff and Russian envoy Kirill Dmitriev (together reportedly with Vice President JD Vance, Secretary of State Marco Rubio and the president's son-in-law Jared Kushner) but a great deal about it is highly unclear. The Trump administration reportedly believes that a deal is imminent, but the Russian government has been at pains to stress that no agreement has yet been reached. We do not know if Moscow will try to exact further concessions; the details of several key points have not been revealed; and above all, it may be impossible to get the Ukrainian government to agree to essential elements, unless the Trump administration is prepared to bring extremely heavy pressure to bear on both Ukraine and America’s European allies.

It has already been reported that President Zelensky has rejected the plan and is working with European governments to propose an alternative — though so far, nothing that the Europeans have proposed stands the remotest chance of being accepted by Moscow.

Among the most difficult points for Ukraine will be the reported draft agreement that Ukraine should withdraw from the approximately 14% of the Donbas that it still holds, and that it has sacrificed tens of thousands of lives to retain. But with the key Ukrainian town of Pokrovsk seemingly close to falling, the Trump administration apparently believes that the rest of the Donbas is sooner or later bound to fall too, and there is no point in losing more Ukrainian lives in a vain attempt to keep it, and also risk Ukrainian military collapse and losing more territory beyond the Donbas.

The draft agreement also reportedly softens the blow for Ukraine by stating that the area handed over will be demilitarized and controlled by neutral peacekeepers. In the other two provinces claimed (but only partially occupied) by Russia, Zaporizhia and Kherson, the ceasefire line will run along the existing front line, and Russia will abandon its demand for the whole of these provinces.

In a huge concession to Russia however, the Trump administration — and possibly other countries like Turkey and Qatar, that helped mediate this proposed deal — is willing to recognize Russian legal sovereignty over the Donbas and Crimea (which would also imply the lifting of many U.S. sanctions on Russia) though it does not expect Ukraine to do so.

The draft agreement apparently excludes long-range missiles for Ukraine and would impose limits on the size of the Ukrainian armed forces, though we do not know how great these limits will be. The Ukrainian government agreed to the principle of arms limitations at the Istanbul talks in March 2022, but has since categorically rejected the idea.

The draft agreement also reportedly includes unspecified U.S. security guarantees to Ukraine, and a formal Russian acknowledgment (already stated by President Putin and Foreign Minister Lavrov) of Ukraine’s right to join the European Union, in return for the exclusion of NATO membership for Ukraine. It has not been revealed however whether this would require a change to the Ukrainian constitution to restore the previous commitment to neutrality, something that could be hard to pass through the Ukrainian parliament.

This is also true of another key element of the reported plan — the establishment of Russian as a second official language in Ukraine. This is a neuralgic issue for Ukrainian ethnic nationalists, but they should recognize and respond with gratitude to the fact that in the face of the Russian invasion the great majority of Russians and Russian speakers have remained loyal to Ukraine.

Predictably, the leaked plan has drawn immediate denunciation from both Ukrainian and Western sources, with it being described as a demand for Ukraine’s “capitulation.” This is mistaken. As the Quincy Institute has long pointed out, an agreement that leaves three quarters of Ukraine independent and with a path to EU membership would in fact be a Ukrainian victory, albeit a qualified one.

This should be obvious if you look at the Russian government’s goal at the start of the war of turning the whole of Ukraine into a client state, or alternatively of seizing the whole of eastern and southern Ukraine. It would also be a Ukrainian victory in terms of the 500-year-long history of Russian, Polish and Turkish rule over Ukraine. And by way of additional evidence, you would only have to listen to the howls of protest that an agreement along these lines will evoke from Russian hardliners, who still dream of achieving Russian maximalist aims. European comments that this draft agreement concedes Russia’s “maximalist demands” are therefore nonsense.

When it comes to the Western security guarantees to Ukraine promised (but not specified) in the draft agreement, it is crucial to recognize that in international affairs and in history there is no such thing as an absolute guarantee, let alone a permanent one. There are however a whole set of commitments that can be included in order to deter future Russian aggression: the peace agreement should be ratified by the U.N. Security Council and endorsed by the BRICS; Western economic sanctions should be not ended but suspended, with a snap-back clause stating that they will automatically resume if Russia resumes aggression; designated long-range missiles and other arms can be stockpiled with a legally binding guarantee that they will be provided to Ukraine if Russia restarts the war.

Above all, Ukraine should retain the complete and guaranteed right to receive and develop the defensive weapons that throughout this war have played a key part in slowing the Russian advance to a crawl and inflicting immense casualties on the Russian army. Because in the end, the greatest deterrent by far against Russia starting a new war is how badly its armed forces have suffered and performed in this war. If Russia has achieved its basic stated goals in Ukraine, would any future Russian government really want to go through this again?

Certain Western officials, politicians, and commentators believe, and have stated openly, that keeping the Ukraine War going is “money well spent” because it weakens Russia without sacrificing U.S. lives. But apart from the deep immorality of sacrificing Ukrainian lives for this goal, the longer the war goes on the greater the risk that Ukraine will suffer a far greater defeat, Russia a far greater victory, and the U.S. a far greater humiliation.

Given the growing evidence of Ukrainian military weakness and Russian ability to press forward with its offensives, simple prudence dictates the search for an early peace on reasonable terms. That is what the present plan promises, and everyone who truly has Ukraine’s and Europe’s interests at heart should support it.

• Frankfurt reference: Quotes "On Bullshit" to describe empty speech during Plaskett's House floor defense.
• WaPo revelations: Reports text messages showing Epstein coached Plaskett on questioning Cohen in 2019 hearing.
• Censure resolution: Failed after targeting Plaskett for Epstein involvement.
• Constituent claim: Plaskett describes Epstein as a constituent sending texts amid others after viral moment.
• RONA exchange: Epstein explains "RONA" as Trump's assistant Rhona Graff; Plaskett asks Cohen about her.
• Advice denial: Plaskett asserts no need for advice on questioning, cites prosecutor experience.
• Additional texts: Epstein compliments outfit, notes chewing; exchanges span seven hours from morning.
• WaPo critique: Plaskett waves transcript, accuses selective 30-second clip ignoring full five-minute questioning.

[

](https://substackcdn.com/image/fetch/$s_!jfoi!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F65a19e89-2d54-486e-8b19-f02f7c76cba2_1024x528.jpeg)

Late Tuesday night, I recalled the late Harry G. Frankfurt’s increasingly relevant, “On Bullshit.”

When we characterize talk as hot air, we mean that what comes out of the speaker’s mouth is only that. It is mere vapor. His speech is empty, without substance or content. His use of language, accordingly, does not contribute to the purpose it purports to serve. No more information is communicated than if the speaker had merely exhaled.

I thought of that book as I was watching Democratic Delegate Stacey Plaskett’s performance on the House floor as she defended herself on a censure resolution inspired by revelations in the Washington Post that she received coaching from world-renowned scumbag Jeffrey Epstein during a 2019 hearing, as she prepared to question former Trump lawyer and fixer Michael Cohen.

The Post story and accompanying video are damning. Of course, the revelations are a bigger story because they involve Epstein. He was still a few months out from being charged with a slew of sex trafficking offenses, but he was still a registered sex offender, as she effectively said, “Jeffrey, take the wheel.” However, this is bad no matter who was driving her questioning in real time. She was nothing more than a ventriloquist dummy, and if you haven’t seen the video, judge for yourself:

Epstein was only a constituent

The censure resolution failed, but make no mistake that her performance was “Mission Accomplished”-level bull. Plaskett starts by heaping praise on herself for a “moment that went viral” earlier in the hearing during an interaction with Republican Congressman Jim Jordan. That, she claims, prompted “innumerable texts” from friends, foes, and constituents.

And I got a text from Jeffrey Epstein, who at the time was my constituent, who was not public knowledge at that time that he was under federal investigation and, who was sharing information with me.

So of all those supposed “innumerable texts,” Epstein just happened to stand out as if he were any other constituent. It was just a coincidence, then, that a few months earlier she landed $30,000 from him for the Democratic Congressional Campaign Committee and that he had already given maximum amounts to her own campaigns. Yes, he was a constituent, but so what? Bob Menendez also had “constituents.”

“I don’t need to get advice…”

Now I heard recently from someone that I was taking advice from him. Let me tell you something: I don’t need to get advice on how to question anybody from any individual.”

This one is my personal favorite because the video from 2019 clearly shows she did need advice!

Epstein pointed out to Plaskett that “Cohen brought up RONA - keeper of the secrets.”

“RONA” is Rhona Graff, a former executive assistant to Trump. Plaskett was thrown for a loop.

“RONA ??” she texted back.

Forty-one seconds went by. She still couldn’t figure it out.

Plaskett: “Quick I’m up next is that an acronym?”Epstein: “Thats his assistant.”

Just in time. She proceeded to ask Cohen three questions about Graff, twice referring to her as “Ms. Rona.” Plaskett grew up in Brooklyn, so I doubt she was exhibiting Southern pleasantries.

In any case, Epstein was pleased. “Good work,” he texted.

Plaskett also mentioned her experience as a narcotics prosecutor in New York and her appointment to the Justice Department after 9/11. “I know how to question individuals,” she said.

The Washington Post

Plaskett takes aim at the Post, saying she questioned Cohen for five minutes. In case there’s any doubt, she waves a transcript as if to say, Proof! Plaskett then complains, “The Washington Post only shows you 30 seconds and takes from it one individual’s name that I got from Jeffrey Epstein, and didn’t know who the individual was.”

This 30 seconds claim is more nonsense. While the video shows Plaskett questioning Cohen for roughly 30 seconds, most of it shows her and the text exchanges just before her questioning begins. The text exchange concerning “Ms. Rona” spanned about 10 minutes, although not continuously. The first text exchange, however, occurred several hours earlier, before the hearing began.

In fact, there were many more texts throughout the day that were reported in the Post’s story but weren’t shown in the video, which of course Plaskett conveniently ignored. The exchanges, after all, indicated they were buddies.

At 10:02 a.m., Epstein texted Plaskett: “Great outfit”

“You look great,” he added at 10:22 a.m. “Thanks!” she replied shortly afterward.

At around 10:40 a.m., a broadcast feed cut to Plaskett, showing her moving her mouth as if she were chewing something.

At 10:41 a.m., Epstein sent this message to Plaskett: “Are you chewing”

“Not any more,” she replied. “Chewing interior of my mouth. Bad habit from middle school”

At 12:50 p.m., Epstein asks: “How much longer for you”

“Hours. Go to other mtgs,” she replied.

The intermittent exchanges spanned nearly seven hours, from 7:55 a.m. to at least 2:34 p.m. There is no substance to this twisted version of the record, just a deeper pile of bull.

“Weaponized it for Political Theater”

Plaskett now presented herself as a victim of government weaponization:

“They’ve taken a text exchange, which show no participation, no assistance, no involvement in any illegal activity, and weaponized it for political theater, because that’s what this is.

This is another trait of a good bullshitter: Imply your critics are doing something they’re not. No one accused Plaskett of doing something illegal by texting Epstein. It was just a way to deflect from her actions.

Fortunately, she’s not a voting member of Congress since she represents the Virgin Islands. Obviously, though, she still has a large platform. Who’s coaching her now?

• 60% User Experiments with Planck: Spent three weeks using 40% ortholinear Planck to master QMK and advanced keyboard features despite preferring 60% layouts.
• Rejects Dedicated Arrow Keys: Advocates home row navigation via layers instead of reaching for arrows, inspired by WASD and chording like Ctrl shortcuts.
• Thumb Keys Excellence: Praises multiple thumb keys for space, backspace, delete, enabling corrections without disrupting home row position.
• QMK Mastery Achieved: Learned advanced QMK features like leader sequences, macros, tap-hold timing, and custom modules through constraint-driven design.
• Home Row Mods Revelation: Implemented modifiers on home row keys for ergonomic shortcuts, fine-tuning timings for reliable tap-hold behavior.
• Typing Challenges: Faced steep ortholinear learning curve, typos, reduced speed with symbols/numbers, and constant mental overhead for layers.
• Build Quality Assessment: Found Planck's construction meh with hollow sound improved by foams and switches, prone to switch removal issues, suitable for budget use.
• Lessons Applied to 60%: Returned to 60% boards enhanced with QMK skills, home row mods, and thumb backspace nostalgia.

tl;dr: As a die-hard 60% user, I spent three weeks with a 40% ortholinear Planck as a self-imposed "internship" to master the advanced features of QMK and other skills that I refer to as the "keyboard dark arts". The good: thumb keys are a revelation, Home Row Mods ftw, and QMK is awesome. The bad: the learning curve is brutal, the mental overhead for coding is exhausting, and the build quality is aggressively just okay. While I'm happily returning to my 60% boards, the Planck was an invaluable, if occasionally infuriating, teacher that gave me the skills I was after.

An overlit and poorly taken photo of the green Planck rev7 keyboard with Drop Jasmin MT3 keycaps and BSUN Maple Sugar switches

Why would you do this to yourself? What's the point?

I got these questions a lot in various forms. And they are fair, to be honest. I frequently looked down at the Planck and asked myself the very same questions.

Some of you are already deep into this hobby and already use keyboards that most people would consider unusable abominations. You already get it. Those who aren't/don't... this review is for you.

There are reasons, but to understand them, we first need to start thinking about keyboards a bit differently. Let's begin by stepping down to 60% and slaying a sacred cow: the arrow keys.

Fuck Arrow Keys

That's right, I said it. Go ahead: gasp, boo, hiss, clutch your fucking pearls.

To be clear, this isn't about not having or using navigation features: we all need to move the cursor around somehow. What you don't need are dedicated arrow keys.

Many of you are sitting in front of a standard full-size or TKL keyboard right now. These are very straightforward: if you want F5, you reach up and press the F5 key; if you want Print Screen, you reach over and press the Print Screen key. If you want the cursor to move up a line, you reach over and press the ↑ key. Easy peasy.

Here's a new way of thinking about this, though: all that reaching around the keyboard for different keys isn't just inefficient, it's poor ergonomics. What if the most critical functions were always right under your fingers on the home row?

Stop reaching and start chording.

This isn't groundbreaking: cut, copy, and paste are indispensable features that have never had dedicated keys on any standardized modern layout. You don't reach across the keyboard for a key, you chord Ctrl (or Cmd) + X, C, or V. Your fingers never leave the 40% portion of the keyboard. We're just applying that same logic to the arrow keys.

This principle isn't even new. Gamers discovered this decades ago with the rise of first-person shooters and keyboard-mouse controls: you need your right hand on the mouse for aiming, but the arrow keys are also on the right. The solution was WASD as arrows. By moving navigation to the left hand's home position, they freed up the right hand for the mouse. While our goal isn't landing headshots, the core lesson is the same: putting essential navigation in a comfortable position under your fingers instead of chasing dedicated keys across the board is a massive win for efficiency. We're just applying that battle-tested wisdom to everyday typing.

Next, take a look at your Caps Lock key: it's a useless little bitch taking up prime home row real estate. With the magic of programmable mechanical keyboards, we can transform it into a key that opens up a layer with things like Enter, Backspace, Delete, and yes, even arrow keys, all right on the home row. You don't even need to buy a new keyboard to experiment with this: all you need is access to VIA or Vial.

This advice isn't for everyone, of course. Some people don't want any challenge at all from their keyboard, just something nice to type on. That's fine. For those of us willing to experiment, yes, it takes a little elbow grease to get there. Yes, it takes some retraining of your muscle memory... but for serious typists, the payoff can be significant. And fun to configure!

The Keyboard Dark Arts

I'm a 60% user at heart. That's my sweet spot. The thought of using anything smaller as a daily driver is extremely unappealing, to put it nicely: I write a fair amount of code, and I need easy access to numbers and symbols. At the same time, I don't need anything larger. I appreciate the more compact form factor and the extra desk space, and (as you can probably tell) I vastly prefer home row navigation to dedicated arrow keys. A 60% keyboard has all the keys I need and none that I don't.

So why did I buy a 40% keyboard? An ortholinear one, no less? No, seriously, why the fuck would someone who writes code buy a keyboard that doesn't have dedicated keys for numbers or critical symbols like \, -, =, [, ], `?

To the wider world, where to find the "missing" keys on a 60% layout is a solved problem with several freely available solutions. Take the HHKB-style arrow keys [;'/, accessed via a Function key made from splitting right Shift. This "solution" always felt hacky to me (see what I did there?). It forces an awkward reach for the pinky to anchor on the Fn key, then requires you to pivot your hand to hit the arrows. Need Page Up? That's an even deeper, more strained reach, all while your pinky is held hostage.

If your goal is saving desk space or achieving a certain aesthetic, that may be a workable solution; but if the goal is maximizing speed and ergonomics, this ain't it.

I (and many others) figured that a better solution was hiding in plain sight on the other side of the board: the prime, underutilized real estate of the dumbfuck Caps Lock key. By turning it into a layer key instead, I could get true home-row navigation with IJKL with no pinky strain. That simple idea quickly snowballed. I pulled in other essentials like Backspace, Delete, Enter, and modifiers to where I could reach with my left hand, building an entire layer that was not just a workaround for missing keys, but a genuine ergonomic upgrade over the standard positions of many keys I did have. I almost never, for example, use my Backspace key anymore: Caps Lock + d for Backspace is faster and more ergonomic.

My setup was good, but I was stuck in a rut. I knew it could be better. I wanted my home row to do more, but I had also reached the limits of my knowledge and capacity with the Vial software.

To get to the next level, I needed to go back to school. I saw the Planck as a ticket out of my comfort zone: a masterclass in constraint-driven design. By stripping away so many keys and adding thumb keys to (somewhat) compensate, the Planck forces you to fundamentally reconsider core aspects of the layout. Where does Enter go? Backspace? Where's the fucking right Shift? How do you remember where all the symbols are‽‽

There are no easy answers, no one-size-fits-all solution. Not even close. The only way is a descent into the keyboard dark arts: the world of QMK, aka Quantum Mechanical Keyboard. This isn't just remapping keys and adding layers, it's an entire programming language for your keyboard. We're talking tap-hold and double/triple-tap timing intricacies, leader sequences that turn your keyboard into a command line, dynamic on-the-fly custom macros, and layering schemes so complex they'd make an Inception architect's head spin. The result is a layout that is custom-fitted like leather to each typist.

I call these skills the "keyboard dark arts" because they are the kinds of things no sane person using a standard layout would ever want or need... but it's that knowledge and those skills that I was after. The Planck wasn't just another keyboard to add to my collection: it was an internship, a trial by fire in these dark arts. A vision quest.

And this, my friends, is the crux of my reasoning for buying the Planck: sometimes you have to break something down to understand how to build it back up better and stronger. I knew going in that this would be painful. I knew I'd hate it. But to truly maximize the potential of the 60%, I needed to step completely outside my comfort zone—I needed a keyboard that would force me to question assumptions and teach me the art of QMK.

And that's exactly what the Planck did.

The Review Part of the Review

Look, I'm not going to reinvent the wheel here talking about the Planck's build quality—plenty of people have already beaten that horse to death. But since you're here, you get my takes anyway.

The build quality is aggressively meh... but so is the price, so I wasn't expecting much to begin with. The sound profile out of the box is, to put it politely, quite bad: hollow, metallic, and clangy. The foams helped considerably, but we're still a far cry from "good" as some hollowness and clanginess lingers.

One gripe I will bring up is that the board has "eaten" a fair number of switches, meaning they never came off the plate in one piece. They were in so tight that the switch housings came apart rather than just come loose. At one point, attempting to remove a single switch resulted in the plate and PCB separating entirely, with every other switch being yanked out of their hotswap sockets and pulled up with the plate in the process. What the honest to god fuck?? Two thumbs down there. Get your shit together, Drop.

I tried both the POM and steel plates before settling on BSUN Maple Sugar switches on the steel plate. I used Drop's Jasmin MT3 Ortho keycaps with a green case. The result is decently attractive and a reasonably good typing experience—and that's coming from someone who's already quite picky. It's not going to blow anyone's mind, but even if you're a bit of a snob like me, it (barely) passes muster.

Now, let's dive into the meat of this review: what I loved and hated about living with the Planck.

The Good Stuff

Let's cover what I really liked about the Planck. It wasn't all frustrations and typos.

Thumb Keys Are the Light and the Way

Seriously, having so many keys for my thumbs instead of one giant spacebar is fucking brilliant. I love it. Hands down my single favorite feature of the Planck.

I put a 2U spacebar on the right, since I almost exclusively hit Space with my right thumb. It was the perfect size—no more, no less than I needed. (My brief, disastrous experiment with a single-wide spacebar proved that.)

Think about it: your thumbs are incredibly agile and dexterous, yet on a standard keyboard one of them hits a single giant spacebar, usually in the same general spot, while the other floats around doing absolutely nothing. What a waste of real estate and talent!

Anticipating (correctly) a steep learning curve with a ton of errors, I put Backspace and Delete as left-handed thumb keys. And it was fucking glorious!

With a traditional Backspace, when you make a mistake, you have to lift your right hand off the home row, reach over to the Backspace key, fix the error, then return to home. It's a constant, if minor, interruption to your flow if you have fat fingers. But with Backspace under my left thumb? I could correct errors instantly without ever breaking stride. My right hand stayed planted on the home row while my left thumb handled all the cleanup. I could even hold Raise with my right thumb, right next to the Spacebar, to turn those keys into "delete next/previous word."

The ergonomics are night and day better. No stretching, no reaching, no breaking your wrist position. It's one of those features that sounds minor on paper but transforms the entire typing experience once you've lived with it.

Fuck a giant spacebar, why isn't this standard?

Manufacturers, take note: give us more split spacebars, you cowards!

It's Fun to Configure

While using the Planck does feel sometimes like solving a damn Rubik's cube, the actual process of iterating over the layers and configuration is surprisingly fun. Type 2 fun, maybe, but fun nonetheless.

Here's the thing: I'm the type of person who gets genuinely excited about optimizing systems. I'll spend hours refactoring code just to make it more elegant. The Planck tapped into that same part of my brain in a way my 60% boards never could.

With standard layouts, customization feels like rearranging furniture in a house someone else designed. You're mostly just remapping a few existing keys—maybe swapping Caps Lock for Control, swapping modifier positions to accommodate macOS vs Windows, or putting media controls under a function layer. It's useful, but it's not creative. There's no real need to rethink where Backspace goes because its default location, while arguably suboptimal, is okay.

The Planck, on the other hand, is a blank canvas with insane constraints.

Every key placement becomes a deliberate choice. Where do you put Enter when there's no dedicated place for it? Do you give up easy access to '" to put it on the home row, or do you move it down to share a key with Shift? What are the timing settings that allow Shift and Enter to share a key seamlessly for how I personally type so I'm not constantly sending incomplete messages? Or maybe we should leave Shift alone and Enter could be a thumb key? Each decision cascades into others, creating this intricate web of interdependent choices.

Every iteration felt like solving a design problem. I'd identify a pain point—say, I couldn't find underscore reliably, or I was having trouble accessing Cmd+[ to un-indent code—then experiment with different solutions. Each solution would work for a while, then reveal new problems that needed solving.

It's the same dopamine hit I get from debugging a particularly gnarly piece of code or finally cracking a math problem that's been stumping me. The difference is that this puzzle was mine—every solution was tailored to my specific typing and workflow quirks.

That iterative process of problem-solving and refinement? That's where the real magic happened.

Which leads me into my next point...

QMK Is the Shiiiiiiiiit

Vial is good, but getting my hands dirty with QMK was a revelation in what's possible with a simple keyboard. This is the heart of the "dark keyboard arts" I was chasing.

If Vial is a moped that gets you around town, then QMK is a stripped-down Formula 1 car: insanely powerful, infinitely customizable, but demanding serious skill to master. If Vial is a Swiss Army knife, QMK is a fully-equipped machine shop where you can forge any tool you need... assuming you know how to operate a lathe.

I was resistant at first, sticking to the online QMK Configurator and avoiding the C code... but that was a mistake. Once I dove in, I was hooked. The result is my QMK userspace repository, containing all my code, keymaps, and even a few community module contributions. For a detailed breakdown of the layout that resulted from this experiment, see the layout README.

This experience cemented a new rule for me: no more non-QMK keyboards. I was seriously considering a Neo60 Cu until I realized I couldn't load it with QMK. That's a dealbreaker now. Having tasted the raw power of what a keyboard can be, I can't go back.

Comically Small

Finally, this thing is hilariously small. I have a fairly large desk with ample space for a full-sized board, so this thing just looks completely absurd in my setup. It makes my 60% boards feel like battleships. It's only twice the size of my damn mouse. My watch's strap is longer than this thing is wide. It's ridiculous!

This translates to awesome portability. Tossing it in a bag would be an afterthought, and while I never took it anywhere, it would be the perfect coffee shop or travel board. You can have a decent typing experience on the go without lugging around a 15-pound block of aluminum and copper.

But for a die-hard ortho user, that portability is more than just convenience. While your brain can store multiple keyboard layouts, it can only have one proficiently loaded into your RAM at a time. You cannot simply switch back-and-forth from ortho to staggered—it takes time and a storm of frustrating typos to readjust your muscle memory. For anyone fully committed to the ortho lifestyle, being able to bring your board with you on-the-go is a necessity.

The Bad Stuff

Alright, let's get into the bullshit. It wasn't all fun and games, and some parts of this experiment were genuinely infuriating.

The Humbling Experience of Typing Like an Idiot

There's no way to sugarcoat this: learning an ortholinear layout from scratch is a deeply humbling experience. You have to commit to being a shitty typist for a while, and it fucking sucks.

Your muscle memory is actively working against you, turning every word into a battle. The bottom row is by far the worst offender because all of the keys are a half-unit off from where your fingers expect them. Every time I went to type a c, I'd hit v or x at the same time. The result was a constant stream of typos like I really fuxcking sucvk at this.

Even after three weeks, I was pretty good, but never fully got comfortable. On Monkeytype, with just lowercase words, I clawed my way back to a respectable 110 WPM. But the moment I had to introduce punctuation—and note the lack of dedicated dash or parenthesis keys—you can take another 30 WPM off. Numbers? Cut the speed in half and double the errors. Outside of that, there were endlessly frustrating series of cascading mistakes: Oops, that's a typo, where's th... oh, fuck, did I just hit tab? Undo that too. Oh my god, did I just escape out? Ok, restore foc... argh... there, focus restored. And now ba.. NO, NOT FORWARD DELETE, BACKSPACE. FUCKING FUCK.

Could I have given it more time and gotten back to full proficiency? Probably. But after three weeks, I felt I'd learned what I needed to and was ready to go back home to my 60s.

Those of you who main these kinds of keyboards? Kudos, seriously. You have more patience, grit, and skill than I do. My 'internship' was difficult enough; I simply cannot imagine using something like this as a daily driver.

The Constant Mental Overhead is Exhausting

Beyond the physical clumsiness, the mental load of using the Planck for any real work was significant. A standard keyboard is transparent; you don't think about where the keys are, you just type. The Planck was the opposite: a constant puzzle I had to solve just to get my thoughts onto the screen.

It may sound minor, but the constant cognitive friction of going, "Okay, there's the dash, tap tap tap, and now there's the open parenthesis, and... no, backspace, now here's the... fuck, that's not it either, THERE's the open parenthesis... tap, tap, tap... now we need an underscore... ope, wrong layer, here's the underscore" takes its toll. All those little micro-interruptions are murder on your flow state. When you're deep in a coding problem or trying to articulate a complex idea, the last thing you want is to be derailed by figuring out where the fuck you put F7.

While by the end I was quite fast with a few symbols—mostly -, _, !, =—the rest presented a constant mental load with frequent misfires. It wasn't until I switched back to my 60%s that I realized just how draining that was: the feeling of simply hitting number and symbol keys without a second thought was remarkably freeing.

It's Cheap (and That's Okay)

Let's be clear: the Planck is an entry-level board, and at $99 for the base kit, the price is fair. It wouldn't have made any sense for me to drop $500 on a keyboard intended as an educational detour. I needed a tool for a temporary job, and for that, the Planck was a great choice. It delivered a decent typing experience for my "internship" without breaking the bank.

That being said, coming from a premium board like the Luminkey LX60 Copper Edition—whose kit cost three times the Planck's—or even the KBDfans Tofu60 2.0, the difference is stark. These are admittedly unfair comparisons, but it's what I have, and it highlights what you give up at this price point.

The main thing is the feel. I'm used to keyboards that could double as bludgeoning tools. My Tofu60 2.0 is also a budget board, but it's a dense block of aluminum and brass that feels like a serious instrument. The Planck, by contrast, feels like a toy.

While its weight, or lack thereof, is a huge plus for portability, it feels flimsy and insubstantial at a proper workstation. It slides around and sounds like complete ass without foams (and still not great with). For someone who appreciates the tactile and aesthetic presence of a well-built keyboard, it was a constant, if mild, disappointment.

So, What Did I Learn?

This whole experiment was about pushing my boundaries and seeing what was on the other side. The Planck was a difficult, frustrating, and ultimately successful teacher. Here's what I'm taking with me:

The Power of QMK

QMK is not just about remapping keys and layers. It's not just having your keyboard arrange the modifiers properly based on what operating system it's connected to. It's a fundamental reimagining of what a keyboard can do. It's about transforming a static input device into a dynamic partner that you can teach to handle your most common and tedious tasks. It's about outsourcing the boring parts of typing to your keyboard's firmware so your brain can focus on what matters.

Take the Leader key. I've taught my keyboard my personal and work email addresses. Now, instead of typing them out, I just hit Leader (P/W) E M, and the keyboard does it for me. I've even taught it how to tOgGle aUToMated spONGEBOB mOckiNg TExt mOdE (Leader S M), because why the fuck not?

This extends to automating common formatting. With my implementation of xcase, I can tell my keyboard to turn spaces into underscores, hyphens, or any other character on the fly. Need to type an obnoxiously long file path? Leader X C /, and suddenly all/of/my/spaces/turn/into/slashes.

And finally, there's user-defined automatic typo correction. With autocorrect running at the firmware level, my keyboard knows I'm a dumbass who types 'teh' a dozen times a day and just fixes it for me, everywhere. You know what's even better than a thumb Backspace? Not needing to hit Backspace at all.

That's the real power of QMK. It’s a toolkit for building a keyboard that becomes a true extension of your own mind—one that anticipates your needs and handles the grunt work for you.

Mastering Dual-Key Timing is a Superpower

This was the holy grail for me. I'd struggled in Vial to get a dual-function Caps Lock key that worked reliably—one that could serve as a lightning-fast layer key on hold but still function as a normal Caps Lock on tap. It just wasn't possible; there was too much overlap between tapping and holding. I eventually settled for turning Caps Lock into a dedicated layer key, with the literal Caps Lock feature accessed via holding Caps Lock and hitting the spacebar. It was functional, but not great.

As it turns out, solving this problem required the full arsenal of QMK's advanced timing features. Nailing the precise combination of TAPPING_TERM, HOLD_ON_OTHER_KEY_PRESS, and RETRO_TAPPING felt like cracking a code. The result is flawless: I can trigger the layer in tens of milliseconds for rapid-fire Backspace from the home row and reliably activate Caps Lock on a tap. No misfires, ever.

This single victory made the entire painful experiment worth it.

Home Row Mods FTW

This is a genuine revelation and one of those 'out of the box' ideas that I may never have been exposed to had I not picked up the Planck. Having modifiers on the home row keys is a massive ergonomic and efficiency boost, and I'm never going back.

For those who are unfamiliar, here's the gist. Each of your eight home keys (ASDF and JKL;) has two jobs: when you tap it, it prints the character; when you hold it, it acts as a modifier. For my keyboards, A and ; are Ctrl, S and L are Opt, D and K are Cmd, and F and J are Shift.

If this sounds like a horrific idea that would interrupt your typing flow constantly... you're not wrong. Getting the timing right requires some finesse—your keyboard needs to reliably distinguish between a tap and a hold. For Ctrl, Opt, and Cmd (or Alt and Win, if you will), this is relatively straightforward. Shift, however, is a different beast and entirely dependent on how you type. Since Shift is used so frequently mid-typing flow, the timing requirements become incredibly precise. Unless you're willing to invest significant time fine-tuning the settings to match your exact typing rhythm and speed, I'd recommend avoiding Shift as a Home Row Mod except for consistency with chording.

Even ignoring Shift, think about how often you use modifiers. Every copy, paste, and shortcut requires you to contort your fingers into an unnatural position to reach Ctrl or Cmd. Home Row Mods eliminate that entirely. The modifiers are already right under your fingers at all times. Instead of reaching down for Command with one hand and tapping C with the other, I just hold K and tap C. It's faster, more comfortable, and dramatically reduces hand strain. It's one of those changes that feels so right, you'll wonder how you ever tolerated the old way.

The Nuance of ABS in MT3

I do not like shined keycaps—the 'stickiness' bothers me, I prefer my fingers to glide over the keycaps—so I've always stayed away from ABS. Give me a fresh, rough-ish batch of PBT any day.

For this board, I broke that rule and went with Drop's Jasmin MT3 keycaps in ABS. I was mostly curious about the MT3 profile, and I figured I wouldn't use the board enough to fully shine the caps by the time my "internship" was over.

The keycaps are starting to smooth out, but are still in good shape.

And I'm a big fan of MT3. The scooping is super comfy. And honestly? The profile makes the shine less of an issue for me. I think it's the fact that the scooping gives the key some texture regardless of shining. I could see myself running a set of MT3 ABS until I could see my own reflection in them. I'd still prefer to see Drop offer more MT3 in PBT, but I'm no longer an absolutist.

60% is My Home

This experiment solidified it for me. The Planck was a fun, educational, and occasionally infuriating detour, but 60% is where I belong. I need my number keys, and I need a layout that doesn't make me feel like I'm solving a fucking puzzle to type a backslash.

The Planck, again, was a vision quest. It forced me to learn, adapt, and master new skills. It taught me the true power of QMK and revealed the ergonomic benefits of Home Row Mods, as well as how to master tap-hold timing for the Caps Lock key. I'm returning to my 60% boards not because the Planck was bad, but because it succeeded in giving me the knowledge I needed to break out of my rut and make my preferred layout even better (the current state of which can be found here). I'm glad to be back, but I'm also grateful for the journey.

And I'm really going to miss having Backspace under my thumb.