I tried some existing tools like ccusage and claude-agent-ledger, but they weren’t able to give me the sort of breakdown into specifics I needed to optimise my usage. Thus, I shamelessly had Claude Code whip up a tool that gives me a better view of its token usage. This is vibecoded in the true sense of the word – I have barely looked at the code – but I’m okay with that becuase it is not critical infrastructure and it does what I need it to.

If you want to know how to get more out of your Claude Code sessions without paying more for it, here’s how you can find out.

First, open the context cost explorer in your browser. Everything happens locally on your machine, so none of your transcript data leaves your computer. If you’re the paranoid kind, you can verify by opening the network tab in your browser and reading in a non-sensitive session and seeing that nothing funny happens. Then follow the steps below, or use your own analytical ability.

(Continue reading the full article on the web.)

The community predicted a mean of just under 70 runs, with a spread of 60–80. My prediction was 60 runs, with a spread of 42–80. The actual number ended up being 59 runs – nearly exactly what I predicted. Let’s see how that was done.

First, there’s a sloppy way of making a quick guess. It’s not very interesting, but it’s a good baseline. Once we have that, we’ll dig into modeling counts on a more granular level, and that’s when it gets interesting. Those techniques can be used for all sorts of counts, not just sports prediction!

I don’t know anything about baseball. I don’t even know what a run is, so I had my research assistant count how many runs were in a few of the previous WBCs.

(Continue reading the full article on the web.)

Some notes:

• The PDP-1 was created mostly as an experiment. At the time, industrial control systems used either humans or complicated contraptions of logic boards to make decisions. Some engineers at DEC wanted to see if there was a customer base willing to use general-purpose computers instead.
• The PDP-4 was a variant of PDP-1 that was a little slower and much cheaper. It was not compatible with the PDP-1. The PDP-4 was upgraded with new chip technology and became the PDP-7, which was then optimised further for cost and speed and became the PDP-9.
• The PDP-5 was created when they realised the PDP-1 and PDP-4 machines were overkill for industrial control systems. By being smaller, it could be much cheaper, at the cost of compatibility with PDP-1 and PDP-4. It was still intended for roughly the same market. The chip upgrade turned it into the PDP-8.
• The PDP-6 was a completely different beast, aimed at a different market. It supported having tonnes of directly-addressable memory, as well as memory protection, so it could be used as a time-sharing system. The amount of memory made it run Lisp well. With the chip upgrade, it became the PDP-10.
• The PDP-11 was a new architecture again, intended to subsume all the previous models, to avoid running three incompatible lines in parallel. There were many variants of the PDP-11, with various performance characteristics and corresponding price points. However, even its most powerful configuration wasn’t powerful enough to attract many PDP-10 users.
• The VAX came much later, but it’s included in the table anyway because it is what eventually subsumed the PDP-10. The VAX was somewhat compatible with the PDP-11, but they served different markets.

(Continue reading the full article on the web.)

The idea is that we first find a set of operations that our circuit simulator needs to support. Drawing this boundary well requires some experience and taste. Then we encode that limited set of operations into a type class. Here’s one way to do it.

class CircuitOperations m where
 make_wire :: m Wire
 get_signal :: Wire -> m Signal
 set_signal :: Wire -> Signal -> m ()
 add_action :: Wire -> m () -> m ()
 after_delay :: Int -> m () -> m ()
 get_time :: m Int
 probe_output :: String -> m ()
 propagate :: m ()

Having read the previous article, these operations should sound familiar. I’m sure it’s possible to create a better set of operations, but this will suffice to illustrate the point.

(Continue reading the full article on the web.)

This way of using Nix is for everyone, not just those willing to try NixOS. We’ll look at it first for a Python script, and then see how it can be adapted to any other language.

I wanted to create a script that would read the verbatim content of my articles out loud to me with a synthesised voice. One of the more convenient ways to do this is with Python, where I’ve heard good things about Trafilatura for extracting the contents out of a web page, filtering on types of content, etc.

But Trafilatura is a third-party Python dependency. Those suck because they break your scripts when you so much as glance sideways at pip. The code also ended up depending on aplay, which is a system dependency, making it two different sources of future breakage. A couple of years ago, I would probably have judged that to be too much maintenance, so I wouldn’t have created the script. Fortunately, now I know about Nix.

(Continue reading the full article on the web.)

For the past few years, my RSS feeds have lived locally on my phone only. There was a good idea behind that, but it never quite worked in practice. For one, many things are easier to read on a larger screen. But it was also brittle to trust a phone app to manage the read/unread status of thousands of articles across a hundred feeds. What I really wanted was a server-side feed aggregator. This is software that runs on a server, manages RSS feeds, and then I can read the RSS feeds either through a web interface, or through client applications. I’ve wanted that for a while, but I’ve never taken the step, because it would be yet another side project to maintain the deployment of.

But now, with some NixOS experience, adding a working FreshRSS configuration (including backups) took 9 lines of Nix code. That installation has just hands-off worked for the past few months. If or when that server breaks, I can spin up a new one running the exact same configuration, probably in something like 15 minutes. When we can do something like that, there is literally no reason to not just try the new software.

Contrast this against how FreshRSS is installed outside of NixOS. Then we’d

(Continue reading the full article on the web.)

If it could be shown to be true, that’d be useful. The argument Shore is making about the effects of robot-generated code does not depend on the specific numbers, so Shore’s numbers come from a hypothetical wisdom-of-the-crowds aggregation rather than concrete data. But no hypotheticals are necessary here. We have a thing called git.

Let’s say we have a way of labeling each commit as either “new development” or “maintenance”. Then we can count how many commits of each type there are in a month. Possibly better, we can count how much complexity has been handled in a month.

The following plot shows the cumulative effort that has gone into the development of tmux since its beginning to the day I start writing this article.

(Continue reading the full article on the web.)

If you’re struggling to find the difference against normal Colemak, look at the cluster of five keys next to the return key.

This layout makes room for the three Swedish letters Å, Ä, and Ö, by only changing five keys in total, and they have changed very thoughtfully:

(Continue reading the full article on the web.)

• Will there be a cease-fire in Ukraine in 2026?
• Will there be a cease-fire in Sudan in 2026?

When I entered my forecast for these questions, I did it based on Laplace’s rule of succession, i.e. as a function of their duration only. This is sort of justified if war durations are heavy-tailed, which would mean that the longer they go on for, the less likely it is that peace comes soon. But I don’t know if that is true.

Either way, this first, roughest forecast is

(Continue reading the full article on the web.)

• Magit
• Perl 5 Core Maintenance Fund
• XMonad

These are important to me, they need more money, and I believe they can use donations well. If you disagree, I’d genuinely like to hear what mistakes I’ve made in the analysis below. I hope it shows that this is important to me.

(Which is also why it is so heart-warming when people reach out to tell me this article prompted them to donate some of their own money. Thank you for being so kind.)

(Continue reading the full article on the web.)

This has worked surprisingly well, but that’s only because my expectations were low to begin with. The VM can barely access the hardware of the underlying machine: it can’t use the GPU, it can’t use the front-facing camera, Linux starts thrashing weirdly when the VM runs out of memory, among other quirks I’ve learned to work around. Thus, I’ve wanted to re-install on bare metal for a while, but! problem!

Come on a journey with me. It’s got a hero with hubris, mistakes, tension, and a cliffhanger.

During a transition period, I want to have two copies of the Fedora installation, and I couldn’t figure out how to fit it in:

(Continue reading the full article on the web.)

If we have Simon Willison’s llm CLI tool installed (and you should – it’s great!), we can call it in a pipe from Perl, and read its response. My script had a loop that retried the request a few times, but without that bookkeeping, the code for this is simple enough.

sub classify {
    my ($msg) = @_;
    my $pid = open2(
        my $output,
        my $prompt,
        'llm -m openrouter/openai/gpt-5.6-luna'
    );
    print $prompt prompt_template($msg);
    close $prompt;

    # Slurp the entire response and chomp off the
    # trailing newline.
    chomp(my $result = do { local $/; <$output> });
    waitpid($pid, 0);

    return $result;
}

The drawback of this approach is that I wanted to label some 21,000 commits, and this shells out to the LLM for every single commit. Since the prompt is designed to contain mainly input tokens and not many output tokens (see Appendix C for details), these calls are cheap in money, but the latency is no fun, at around 1.5 seconds per call.

(Continue reading the full article on the web.)

The most recent issue was the stack limit being blown by a helper function involved in generating the tag index. I had written it to be explicitly recursive, which worked fine with a small-ish number of published articles, but not anymore. The tag index creation follows a similar pattern to the RSS feed generation detailed in the previous article.

(defun tw-tag-index (project)
  "Generate a tag index page for PROJECT."
  (let* ((filename (concat (project-dir "src" "org") "tags.org"))
         ;; Get all publically listed files in this project.
         (files (seq-filter (lambda (entry) (plist-get entry :indexed))
                            (tw-get-all-files project)))
         ;; Convert to sorted alist of tag×article pairs.
         (all-tags (sort (tw-get-all-file-tags files)
                         (lambda (a b) (string< (car a) (car b))))))
    (with-temp-file filename
      (insert (concat
               "#+TITLE: Tags\n"
               ;; Don't show author and publish date.
               "#+AUTHOR: \n"
               ;; Don't list in public indices.
               "#+FILETAGS: :page:\n\n"
               ;; Include table of contents.
               "#+TOC: headlines:1\n\n"
               ;; Then produce headings for each tag.
               (org-element-interpret-data
                   (tw-article-entry-headlines all-tags)))))
    ;; Return the filename of the created file. I don't
    ;; remember why. Maybe it's not necessary.
    filename))

First we filter out the articles that should be indexed from a list of all files in the project. We pass this through the tw-get-all-file-tags function, which produces an association list, which is like a dictionary in Emacs Lisp. Each entry in the association list is a tag paired with a list of articles that have that tag. That list is sorted alphabetically on the tag name, and then it gets converted into an Org document that can be exported.

(Continue reading the full article on the web.)

First off, you might want to try it out. Nothing you paste into that web page leaves your browser, so you can safely try it with whatever you like. I have invited some testers to try out an earlier version of it, and they had mainly positive feedback to give.

We won’t break down robot-isms the way we broke down Claude-isms in the previous article, because in the UI of the new classifier you can just click any part of the text being classified to see which features activate on that portion of the text, and how they contribute to the overall judgement. Here’s an example of the expanded feature activation view.

(Continue reading the full article on the web.)

Walk the entire collection to locate flagged clusters. Skip it altogether when the cached, dirty-tracked flag count says there are none (the usual case): nothing needs marking, so the walk is pure waste. When the count is stale (e.g. right after an edit) or non-zero, we fall through to the real lookup, so stale marks never show. Same eventually-consistent signal the “Flags” badge relies on.

One thing in this comment caught my mind: the small parenthetical that says “the usual case”. If that were true, it would be important information! However, this comment is generated by the LLM model Claude, which has no sense of what counts as the usual case in this domain. But by generating that comment, it tricks every future reader (both human and robot) into believing in a property of the system that does not exist.

Since I knew, in this case, that the comment was generated by a robot and that the property it contained was hallucinated, I could fix the comment. But that’s not always so easy. Here’s another comment.

(Continue reading the full article on the web.)

I’m envious of what Lisp programmers do. Lisp development typically happens by typing code directly into the REPL to add, remove, and replace parts of the live, running system.

• A Lisp programmer does not need to “switch over” to something else because they are already inside their program process.
• They never “compile and execute” the code because the code is already running and they edit it by hot-swapping code.
• They never restart in a debugger because they are already inside their program process and can inspect anything they want.
• They don’t have to restart the program on exceptions, because the condition system allows resuming the crashing code from anywhere in the stack after the system has been patched with a fix.

A consequence of this way of working is that early in a Lisp project, there may not even be any source code to speak of. Instead, the evolving definition of the system exists only in the memory image of the running process and nowhere else. This is so unlike how we normally do development that people have expressed trouble understanding what that even means. A comparison that might help is to think of how people treat relational databases in the beginning of a project. Often, people don’t start out with a version-controlled schema definition; rather, the evolving schema exists only in the running database. Sure, at some point when the project matures, the database schema is dumped out to a file, put under version control, and from that point forward, schema changes are made through explicit migrations. Similarly, a Common Lisp project that matures will be dumped from memory image to source code eventually, and then that source code will go under version control, with patches applied more carefully to the live system.

(Continue reading the full article on the web.)

The theme is typically related to whatever the promoter wants to promote, but styled for children. I get the appeal – for children. They can probably imagine they’re really travelling along the path! In the variant pictured below, there’s forest and water and tunnels and dogs and everything!

But as a game, it sucks. For everyone. My children hate losing, and these games have n−1 losers for every n players. There are also literally zero decisions for the players to make, so I cannot make it through even a few turns without zoning out.

(Continue reading the full article on the web.)

The following is three seconds of a single 5 Hz sine wave, recorded at a sample rate of 100 Hz.

(Continue reading the full article on the web.)

Since last week, are in the process of simulating a digital circuit. The reason this is interesting is the solution in SICP uses hidden mutable state and message-passing to make the code object-oriented. It even uses a mutable global variable for scheduling! We managed to replicate all of that in Haskell, but now we want to refactor the solution to be easier to work with.

If we are going to manage the simulation in a pure functional manner, we still have to contend with the fact that during simulation, wires are objects with a fixed identity. A wire does not become a different wire just because its signal changes – the same wire is still hooked up to the same gates. Wires need to maintain their identity somehow.

In addition to the Signal type from before, we’ll define a Wire to be a string. This is its identity. We’ll also make a convenience function for creating a wire whose name is based on another wire name. This will be useful for creating unique wire names when we build circuits.

(Continue reading the full article on the web.)

In the previous two installations of this series, we looked at ways of implementing generic functions. In the first one, by tagging values and dispatching operations on tags. In the second case, by filling a mutable table of operation–tag pairs. We saw how these are roughly equivalent to the existing Haskell features of sum types and type classes.

Now we’ll simulate a digital circuit. The reason this is interesting is that the solution in SICP uses hidden mutable state and message-passing to make the code object-oriented. It even uses a mutable global variable for scheduling! I wasn’t sure if it would be possible to replicate that in Haskell, but as we’ll see, it can get incredibly close.

There are many ways to implement mutable state in Haskell, but to begin with, we’ll use the way that’s most similar to the SICP solution: IORefs. An IORef is a mutable variable, like in any other programming language.

(Continue reading the full article on the web.)

However, we couldn’t tell if this difference was large enough to be a useful guide for making decisions. It could just be an artifact of the small sample size.

(Continue reading the full article on the web.)

Since the curve does not start at the origin but a few percent up on the y axis, we can conclude that a few percent of the population have a score of zero. That doesn’t mean they are bad or miserable people – there may be factors that make zero the best score for them – but on average, a score of zero is worse than a higher score.

(Continue reading the full article on the web.)

• … earns you a high-risk pregnancy
• … earns you an ascent of Matterhorn
• … earns you 10,000 km on a motorcycle
• … earns you two BASE jumps
• … earns you a day on the frontline in Ukraine

These are all about equivalent to the risk of one year of smoking.

I’m skeptical of submitting asymptomatic people to medical tests. Almost any time I look into the evidentiary power of medical tests, I’m struck by how much work is performed by the base rate. The tests only work because we perform them on people who appear sick, i.e. have a higher probability of actually being sick in the first place. If we would perform them on seemingly-healthy people we would get nonsensical results.

(Continue reading the full article on the web.)

Complex numbers can be stored in their rectangular form, with a real and an imaginary part. They can also be stored in polar form, where there’s a magnitude and an angle. Whichever way a complex number is stored, we would like to be able to query it for all of these four quantities:

• The real coordinate in the rectangular form of the complex number.
• The imaginary coordinate in the rectangular form.
• The magnitude in the polar form.
• The angle in the polar form.

Last time we implemented these on top of a tagged value. To return one of the four coordinates above, a function would introspect the tag to figure out how to satisfy the caller for the representation involved. This works, but any time we want to add a new representation, we have to change all four existing operations.

(Continue reading the full article on the web.)

This article is written in Haskell throughout, but at the start it will look a lot like the Lisp code in SICP. I have intentionally tried to recreate the SICP solution as closely as possible, including dynamic typing and all. See the appendix if you’re curious how it works.

Complex numbers can be stored in their rectangular form, where there’s a real and an imaginary part. They can also be stored in polar form, where there’s a magnitude and an angle. The authors ask us to imagine that two people have been working on a library for mathematics, but ended up choosing different ways to store complex numbers. How can they write their code so that they don’t have to agree on one way to store the data?

Abelson and Sussman propose a tagged representation, where the data of the complex numbers are paired with a tag, which indicates to the implementation what representation is being used. They suggest the following functions to attach a tag, as well as inspect tagged data.

(Continue reading the full article on the web.)