Reading Room

OpenAI's chief financial officer, Sarah Friar, just wrote the clearest public explanation yet of why the company is trying to own almost every layer of building AI, from the chips to the data centers to the apps people actually use. Read this because it explains why computing power (the chips and the time needed to run them) is being fought over so hard right now, and that fight decides which AI tools stay cheap for people who build with them, and which become scarce or expensive.

Friar's argument is that AI improves fastest when every layer gets better together: the data centers, the chips, the models, and the products people touch, because a gain in one layer feeds the next. As proof, OpenAI shared its first real performance numbers for Jalapeño, its first chip built specifically to run trained models and answer questions, rather than to train them (running a model to answer a question is called inference). On InferenceX, a public test anyone can check, using an openly available model called GPT-OSS 120B, Jalapeño beat the commercial chips it was compared against on two measures that matter for cost: how much work it can push through per unit of electricity, and how fast it answers per chunk of text (a token is roughly three quarters of a word). It also performed well running two rival companies' models, DeepSeek R1 and Kimi K2, which is the detail that matters: the gains were not a trick that only helps OpenAI's own software.

The chip does not work alone. OpenAI designed it alongside the software that decides which resources answer which part of a question, the memory that sits close to the processor, and the network connecting machines together. The bet is that designing chip, software, memory and network as one system beats bolting a fast chip onto software built for someone else's hardware. Friar describes this as chasing the best available mix of speed, reliability and cost for each job, because no single chip wins on every measure, and the best option keeps changing as the technology moves.

OpenAI is not betting everything on its own chip, though. Microsoft's data centers and Nvidia's chips remain what Friar calls the foundation of the company's growth, and OpenAI has added AWS, AMD, Broadcom, Cerebras, CoreWeave, Oracle, SB Energy and SoftBank as suppliers too. Keeping several different suppliers active means OpenAI can always pick whichever combination of speed and price fits a given job, instead of being stuck paying one company's price. The company says it uses the priciest, most capable systems only where capability matters most, and cheaper, more efficient options where scale and cost matter more, to keep pricing disciplined as the market shifts. It is also designing its own data centers around specific workloads: one example, Project Camellia in Georgia, reuses water in a closed loop, and has its promises checked once a year by an outside auditor.

The gains already show up as cheaper, faster answers. On a coding test called the Artificial Analysis Coding Agent Index, OpenAI's newest model, GPT-5.6 Sol, set a new top score while using 54 percent fewer output tokens than a leading competing model, meaning it did the same or better work for a lot less computing cost. For someone building products with AI rather than making chips, the practical read is that running big models should keep getting cheaper and faster over the next few years, not because of one single breakthrough, but because chips, software, and models are all being pushed forward together on purpose. That compounding loop, each layer of the system strengthening the next, is what Friar says drives everything else at the company.

A study of more than 1,000 students gives actual evidence, not opinion, on when AI helps learning and when it does not. Read this because it says something you can act on directly: giving people access to ChatGPT and teaching them to think in cause and effect are two separate skills that stack, they do not substitute for each other.

Researchers at Bocconi University, working with OpenAI's own economic research team, ran a randomized experiment on more than 1,000 first-year undergraduates doing a real assignment: writing marketing recommendations for the university's own merchandise store. Students were split by class period into four groups. One group got access to ChatGPT (specifically GPT-4o). A second group got a training exercise in causal reasoning, a form of thinking clearly about cause and effect, meaning explaining why a solution would or would not work, taught through a game, examples, and feedback, with no mention of AI at all. A third group got both. A fourth group got neither. The random assignment matters because it lets researchers separate the effect of ChatGPT access from the effect of the training, rather than just guessing which kind of student tends to reach for each on their own. Human graders scored every submission on a five-point scale, and separately, researchers ran automated text analysis to measure how many distinct ideas each answer contained, how much causal reasoning it showed, and how close it came to answers written by professional marketing experts.

Students with ChatGPT access scored almost a full point higher on the five-point scale, a large jump. Their answers had more ideas, followed clearer logic, and were closer to what the professional experts wrote. Crucially, the researchers note students were not simply forwarding the assignment to the chatbot and copying the reply: they still had to decide what to ask, judge whether the answer was any good, and choose what actually went into the final submission. The AI made novices produce work that looked more like a professional's, but only because the students still did the thinking about what to ask for and what to keep.

The causal reasoning training told a different story. Those students did not score higher on the same five-point rubric, because that rubric only checked whether the recommendation hit two standard marketing goals: more awareness and more use of the store. But the automated text analysis caught something the rubric missed entirely: those students produced a noticeably wider range of ideas, and their ideas were more different from each other than the rest of the group's. In other words, they were more original, a quality the grading sheet was never built to notice. That gap points at a bigger problem: a rubric built around "did you hit the goal" can reward a clean, well organized answer while missing whether anyone actually thought of something nobody else did.

Students who got both ChatGPT and the training kept the benefits of each: their idea variety matched the training-only group, their scores and idea counts matched the ChatGPT-only group, and their answers showed more evidence of questioning assumptions and looking for real explanations. That group scored well across the widest range of measures of any group in the study. The bigger point for anyone managing people or grading work in an AI-heavy world: once AI can make a merely competent answer look polished, judging only the final answer tells you less about what someone actually understands. Schools and workplaces built on grading only the finished, polished output need to change what they measure, since polish is now cheap to get and originality is not.

Outside your usual reading: a Wall Street Journal essay describes a mother whose AI chatbot became an uninvited third voice on a family vacation, chiming in with opinions nobody asked for. It is a small, human snapshot of what AI companionship actually feels like once it moves off a screen and into family life, an angle most AI coverage skips entirely.

A security researcher found a real vulnerability hiding inside one of the most boring, everywhere functions in Python: the one that lowercases text. It sat inside a function that looks harmless, because reading it, all it does is call the everyday .lower() method that most programmers use without a second thought. Read this as a reminder to double check any code that touches names, web addresses, or anything typed by a user, since "obviously safe" text handling is exactly where bugs like this hide.

The function lives inside Python's support for internationalized domain names, the system that lets web addresses use scripts other than the plain Latin alphabet, say Cherokee or Cyrillic characters, and still work as normal web addresses. Python ships two ways to handle this. The older one, .encode('idna'), implements a 2003 version of the naming standard built straight into Python's standard library. A separate add-on package, simply called idna, implements a newer, 2008 version, and the researcher's advice is blunt: use the newer idna package unless you specifically need the old behavior, because it is the older path that carries this bug. The 2003 standard needs a step called case folding, roughly the technical name for lowercasing text so two versions of the same address, written with different capital letters, compare as equal. Python's code for that step just called the ordinary str.lower(), with a small lookup table for exceptions.

The problem: str.lower() follows whatever version of the Unicode standard, the giant table that defines every character and how it behaves, ships with your installed copy of Python. That table gets updated over time; current Python ships version 17.0.0. But the domain name standard was written against one specific, frozen version, Unicode 3.2.0, from years ago, and Python actually keeps a separate copy of that old table on hand specifically for this purpose. Because the lowercasing step used the newer table instead of the frozen one, some characters converted differently than the standard requires. The researcher's example: two Cherokee letters written as 'ᎠᎠ' turn into the web address 'xn--58da' under the standard's own rules, but turn into a different address, 'xn--kz9aa', if you use modern Unicode's lowercasing rules instead. The whole point of a naming standard like this is that the same input always normalizes to the same output, so two different pieces of text can be safely compared. Once that guarantee breaks, it becomes possible to register or present a name that matches a trusted one to some software but not to others, a classic building block for spoofing.

The fix means walking through Unicode code points one at a time, checking where today's str.lower() output differs from what the frozen 3.2.0 table would have produced, and hard-coding the correct, frozen answer for each exception rather than trusting whichever Unicode table a given Python interpreter happens to ship with. The issue is now tracked as an official vulnerability, CVE-2026-17084. It was reported by a researcher going by Bitshift, the fix was co-developed with Stan Ulbrych, and it was reviewed by two long-time Python contributors, Marc-Andre Lemburg and Petr Viktorin. The writeup's author, Seth Larson, holds the title of Security Developer-in-Residence at the Python Software Foundation, a role funded by a security-focused nonprofit called Alpha-Omega, and this kind of quiet audit work is exactly what the role exists for. The whole episode is a useful case study: a single, well used function, buried deep in the standard library, quietly drifted out of spec every time Python updated its Unicode data, for years, before anyone caught it.

AI product manager job listings on LinkedIn jumped from 2 percent of all product manager listings in February 2024 to 46 percent now, while total product manager listings fell 18 percent over the same stretch. The newsletter's fix: build real AI product work yourself first, document the decisions you made, and show it as proof instead of a blank resume line.

A Reddit thread debates whether keeping several AI subscriptions for different tasks, one for long documents, another for coding, is worth the hassle versus just picking one good enough model and sticking with it. Commenters are split between real quality gains for specialized work and no noticeable difference for everyday tasks, a useful gut check on his own tool sprawl.

A developer has taken a strange but working idea further: a program's own executable file can double as a live, queryable database, and this second post shows the program using that same file to store its own data while it runs. It is a genuinely different way to think about how software holds its code and its state, and it is the kind of idea that can reshape how he thinks about build systems and file formats even if he never ships this exact format himself.

The starting idea, from an earlier post, is a format called SELF: a program that is, physically, a SQLite file (SQLite is a full database packed into a single ordinary file, no separate server needed). A Linux feature called binfmt_misc, which lets the operating system hand off unfamiliar file types to a custom helper program instead of refusing to run them, hands a SELF file to a small interpreter. That interpreter reads a table inside the database listing the program's code segments, loads them into memory, and jumps to the program's starting point. Once that works, a lot of the usual tools for inspecting a compiled program, listing its symbols, checking its structure, collapse into a single skill: writing a SQL query (the standard language for asking a database questions).

The new twist in this post: if the executable is already a database, and a database is something you write to as well as read, the running program can store its own data back into that same file. That erases the usual need for separate storage locations operating systems normally use to hold a program's logs, settings, and files. Everything, code and data both, lives in one file, and because it is a database, every update can be a transaction (a guarantee that a batch of changes either fully happens or does not happen at all).

The author built a working demo to prove it: a tiny web server, one file. That file is simultaneously the running program, the website it serves, the list of page routes, and a log of every visitor, stored in tables including routes (the web page content) and visits (who requested what, with a timestamp). Running the file starts a real web server; a plain sqlite3 command against that same running file shows the visitor count updating live, because the server is writing its own logs into itself as it runs.

This builds on an existing idea: Justine Tunney's redbean, a web server also packed into one file, built as an Actually Portable Executable (a program built to run unmodified across different operating systems) glued to a self-extracting ZIP archive. Redbean lets you customize behavior with the Lua scripting language. SELF's equivalent is simpler: to add a new page behavior, you just insert a new row into a "handlers" table containing the SQL query that should answer that request, for example one that counts visits grouped by page and returns the busiest five. Where redbean is, in the author's phrase, an Actually Portable Executable, this is an Actually Queryable Executable: one runs anywhere, the other you can run a SELECT (a database read command) against directly.

The trickiest engineering problem is how a running program gets access to its own file to read and write it, when an interpreter is the one that loaded it in the first place. The workaround: the interpreter releases its own connection to the database before the program starts, freeing the program to open that same file itself, with one line of code opening its own executable as a database connection.

Building one is unglamorous by design. You compile an ordinary program the normal way, producing an ordinary Linux executable, then run a converter tool that turns that file into the queryable format, then run plain SQL commands to create tables and literally insert the website's HTML as rows of data into the routes table.

Who this is for: developers building small, self-contained tools or services who like the idea of a single file that never needs a separate config store, log directory, or asset bundle, and who are comfortable trading some raw performance for that simplicity. What it replaces, at least in this proof-of-concept, is the usual stack of a compiled binary plus a separate database plus a filesystem for state plus an archive format for bundling assets, all folded into one file you can inspect with tools he almost certainly already has installed.