Quick Takes

If you’re building any kind of dev tool, stop investing in UIs, CLIs, and MCP. Instead, invest in APIs/SDKs and documentation, which make your tool more useful for LLMs. LLMs are becoming extremely adept at using native low-level tools so it doesn’t make sense to build wrappers around these that aren’t in the training data. * Many have observed that LLMs use bash commands in effective yet alien ways learned through RL. Another phenomenon is that LLMs used to use Playwright to manipulate browsers, but now they just run CDP commands directly. LLMs also prefer to run Python snippets directly instead of CLI wrappers around the same library, especially if the CLI is not in the training data / not well documented. * MCP servers are useful for integrations with apps like Claude Desktop, but for devtools in particular, the raw API is more useful for the LLM (for example, the LLM can write API output to a file instead of processing it in-context). * A good SDK can provide helpful guardrails for the agent. For example, implementing client session management can prevent potential issues and also removes boilerplate. * UIs are still useful but become less useful as LLMs build more user-specific interaction layers for viewing and manipulating data. For example, a database provider like Supabase provides a full UI right now but in the future they may just provide raw visual components which software teams use to construct their own bespoke UIs. Documentation (right now mostly via agent skills) is extremely high ROI and will continue to be higher ROI as more work is delegated to agents. Your service is much less useful if an agent can’t one-shot basic actions when given documentation. * My personal opinion is that documentation is much more useful when a human writes it than an LLM. The LLMs that write documentation are usually not opinionated enough, do not understand which user flows to highlight, and make factual errors. * Documentation is especially helpful in descri

AI safety people often worry about their work having capabilities externalities. I feel like the inverse problem is often a much bigger deal: the stuff you do might be done later by the capabilities/product people in the course of their work, meaning your work isn't counterfactual! I think people should try to distinguish these concerns more clearly.

Is it just me, or is Opus 4.7 a lot worse than Opus 4.6 at giving writing feedback? I've had a few drafts where 80–90% of 4.7's critiques make bad counter-arguments or just miss the point. For 4.6 I felt like the number was closer to 30–50%.

The Ten People On The Inside likely should prioritize things that capabilities teams aren't going to do anyway and people considering joining labs with similar motivations should likely think about whether they're sure they're going to be able to do work that wouldn't otherwise be done for capabilities reasons. The thing that's top of mind here is reward hacking, which is increasingly becoming a capabilities problem.[1] To the extent research is done here, it seems pretty important to avoid the failure mode of "repeatedly iterate on environments and observable behavior"[2] which is the kind of thing I would expect by default for capabilities reasons. 1. ^ A good example of research on reward hacking that I don't think would've necessarily gotten done "by default for capabilities reasons" is inoculation prompting and similar investigations 2. ^ This can take the form of specific safety training targeting the observable behavior, post-hoc environment fixes, or having an iteration loop between your pre-deployment automated alignment evals and your alignment training

Various token consumption counts & costs for my own future reference. * 65k tokens (50k input / 15k output) costing $0.705 for a 1-hour coding session with Opus 4.6 in Claude Managed Agents * ?? tokens and $6 cost + 3.5 hours of amortised undergrad time: average cost per manuscript for a replication of Sakana's AI scientist, reported in early 2025. "The total cost for our main experiments, which included generating 10 ideas, running experiments for 7 ideas (from 12 total, including 2 seed ideas, of which 5 failed), and producing 7 manuscripts with reviews, amounted to only $42 USD.". This was lower than Sakana's own $15 cost per idea claim because their experiments were less complex. They estimated 6-11x speedup: "we estimate that an undergraduate student would require at least 20 to 40 hours" * ?? tokens and $2.40-28.50 per API call for OpenAI's Deep Research API as tested by Artificial Analysis * 100-270k tokens (according to GPT-5.5 extended thinking's BOTEC) and $15–35 API-equivalent token spend for GPT-5.4 Pro to solve Erdos problem #1196 and convert the solution to a LaTeX math paper, at $30 / $180 per M token rates. The 80-minute 55-page reasoning chain was the big cost driver; this ratio is inverted for agentic workflows where cache reads etc dominate * 2-60M tokens for analyst-type tasks e.g. "convert excel models into dashboards, create charts for all our notes, build financial models and analyze company earnings, and much more". I shared yesterday SemiAnalysis' table below of their token spend vs labor costs on their workflows; given their true blended price of per M tokens of $0.99 for running Opus 4.7 on agentic tasks, I assume for simplicity the token cost converts straightforwardly to M tokens * 700 million tokens weekly: Ege Erdil's ballpark usage by a single continuously-running full-time agent. Ege himself said he clocks 1-10B tokens weekly * 1 billion tokens consumed, $1,500 Anthropic bill (mix of Max 20x, overages, API direct) and $1,800

Various actual token spend vs labor cost ROIs on 1-20 hour tasks from SemiAnalysis' recent newsletter: [...]

Claude Opus 4.7 can reliably truesight me on any unpublished blog post draft or internal memo (including on topics I've never written publicly before on). It can also reliably know who I am in 3-5 excerpts of online comments (that I think *probably* is after the training cutoff), including from accounts that I don't publicly acknowledge a connection with (though I don't go out of my way to hide either). It can't quite do it on excerpts of short fiction or private DMs yet (at least when I remove obvious clues like links to my substack), though I feel like this can't be long coming.