Was this newsletter forwarded to you? Sign up to get it in your inbox.
I keep running out of access to the most capable AI models before the workweek is finished. Lately, I’ve come to realize that may be useful. Anthropic’s limits on both my work and personal Claude subscriptions reset at the start of the week. When they do, I gorge on the newly available capacity, running Fable on its highest effort levels and watching agents orchestrate subagents and dynamic workflows on multiple projects.
It used to be that I exhausted my weekly allocation within a day or so. I would go back to daily tasks with speedier, still-capable models like Sonnet and Sol, saving my biggest questions and one-shot builds and thorniest bugs until my limits reset.
The wait gives those questions time to develop. I’ve come to call my weekly sessions with the most powerful models “consulting the oracle”—a nod to the oracle at Delphi, where the ancient Greeks sought guidance from Apollo through the priestess Pythia (OK, also to The Matrix).
But as frontier models like Fable 5.1 become more token-efficient, faster, and easier to talk to at lower effort levels, I’ve started running them as daily drivers, too. The same limits now stretch to three or four days instead of one.
I’m not always better off for it. I get a feature idea for Kestrel, my personal model harness, and immediately send Fable to work on it, confident that it’ll turn around a result quickly. I stop less than I used to to consider whether the feature deserves to be there—or whether I should even be sinking time into a personal harness when there are whole teams building great ones at frontier labs.
I engage in what software engineering leader Will Larson calls “snacking”—choosing easy, low-impact work over difficult, high-impact work. When I had to wait, I had more time to notice the difference.
The uneven frontier
Waiting for access to a powerful computer is not a new experience. Before the internet, programmers had to wait their turn to run computations on large mainframes. Annie J. Easley, a programmer at NASA’s Glenn Research Center, physically toted punch cards to a separate building where the computers were. Mathematician and computer programmer Mary Berners-Lee recalls a queue of people waiting behind her at Ferranti, an early British computer manufacturer, a sign posted above the machine reading: “Think—but not here!”
In the early 1960s, time-sharing allowed users at universities and government institutions to dial into central computers through remote terminals. Programmers could change and rerun a program at the terminal, observing and correcting errors immediately. Instead of waiting between runs, they could follow an idea through several experiments in one sitting. “There’s a certain kind of experimentation you can do when you don’t have to worry about turnaround, but there’s also a certain amount of sloppiness you get into,” said UC Berkeley computer scientist Susan Graham in 2002.
Access, however, remained constrained by quotas, connection charges, and limited terminal availability. Xerox PARC scientist and graphical user interface pioneer Alan Kay called time-sharing “a very institutional way of thinking about computing,” akin to a railroad with someone else deciding the schedule.
Experimentation had become more immediate, but access to the computer was still on someone else’s terms. Kay and his colleague Adele Goldberg envisioned a more personal relationship with computing: a “dynamic medium,” akin to a musical instrument, through which ideas could be expressed and altered as they arose. The personal computer would be an “object to think with” rather than a receptacle for already-finished thinking.
But a medium that responded without delay also put the onus on the user to choose to step away. Sherry Turkle, a sociologist at MIT who studies people’s relationships to computers, saw the other side of this immediacy as early as 1984. In The Second Self, she writes: “It is hard to walk away from a computer program with an undiscovered ‘bug,’ it is hard to walk away from an unproofread text on the screen of a word processor. Any computer promises you that if you do it right, it will do it right and right away.”
I hear echoes of these historic accounts in my own work with AI. But Kay’s “object to think with” sometimes becomes an “object to think for”: coming up with ideas for work to give the machine, without always stopping to consider the value of that work. My personal experience has been that without hard constraints, stepping away becomes even more difficult.
The journey to Delphi
Lately I’ve been thinking more about the journey to my “oracle.” Greek pilgrims arriving by sea at Delphi rested at the port of Kirrha before continuing 11 kilometers uphill to the sanctuary. Seeking an answer about their personal or communal affairs required time away from ordinary life. I wonder whether the Oracle of myth simply served as a reason to undertake a journey—a journey which itself clarified questions and revealed the answers.
While I won’t go as far as downgrading my Claude plan just yet, I would like to make room for a smaller version of that journey in my ordinary work. Let a new feature idea sit overnight. Before bringing a difficult question to a model, first write down why it matters and what I think the answer might be. Maybe I’ll even ask my daily conversation agent to suggest these pauses.
Some ideas will still deserve to be built in the morning. Others, I suspect, will lose their appeal once the immediate gratification of being able to build them has worn off.
Jack Cheng is a senior editor at Every. To read more essays like this, subscribe to Every, and follow us on X at @every and on LinkedIn.
Everyone’s a builder now. Every All Access gets you the full membership plus the Builder Pack—$9,000+ in credits for the tools we build with.
