Summary

llamafile is a single-file executable format that packages an open LLM’s runtime and weights so the model can run locally with no installation. By combining llama.cpp with Cosmopolitan Libc, a llamafile contains everything needed to execute a model on a user’s machine and aims to make open LLMs more accessible to developers and end users.

Technically, llamafiles add runtime dispatching for multiple CPU microarchitectures and concatenate AMD64 and ARM64 builds so the appropriate binary runs on each system. The format targets six OSes (macOS, Windows, Linux, FreeBSD, OpenBSD, NetBSD) and supports embedding weights via PKZIP in the GGML library for memory-mapped, self-contained distribution. The project provides tooling to create and distribute llamafiles, is an Apache 2.0-licensed project with MIT-licensed changes to llama.cpp, and has recently been adopted by Mozilla.ai, which is soliciting community feedback on modernization plans.

Because it’s a LLM, this is akin to having Wikipedia offline, but you can ask it questions.

Also powered by Cosmopolitan libc, the explanation of which is an amazing work in itself.

Source: TIL: Single-executable local LLM

Simon Willison on PR (anti-) patterns in the world of agentic AI

There are some behaviors that are anti-patterns in our weird new world of agentic engineering.

It’s so easy to create AI PR slop in this new world, even on private teams.

If you open a PR with hundreds (or thousands) of lines of code that an agent produced for you, and you haven’t done the work to ensure that code is functional yourself, you are delegating the actual work to other people.

These are good rules for event human-created PRs and these stood out:

The change is small enough to be reviewed efficiently without inflicting too much additional cognitive load on the reviewer. Several small PRs beats one big one […]

The PR includes additional context to help explain the change. What’s the higher level goal that the change serves? […]

Agents write convincing looking pull request descriptions. You need to review these too! It’s rude to expect someone else to read text that you haven’t read and validated yourself.

**Key points** * SSDs wear out differently from hard disks. * Expect modern Mac internal SSDs to wear out after at least 3,000 erase-write cycles. * To monitor wear, measure the total data written to the SSD. * Expect an internal SSD to wear out when that total reaches 3,000 times the total capacity of the SSD. * For a given amount of data written to an SSD, the larger the total capacity of the SSD, the slower it will wear out. * Keep at least 10% of the SSD free at all times, with 15-25% even better. * Ensure your Mac has sufficient memory to never use VM swap space.

hoakley in How long will my Mac’s SSD last?

How to find out where I am in that cycle?

Version 1: use iostat and some math.

$ iostat -Id disk0
              disk0
    KB/t xfrs   MB
   19.02 36987892 686874.89

The MB column is “total number of megabytes transferred” (since the disk was installed).

So 686.87 GB, in my case. My disc is 1TB and that means I’m not even fully through one of those 3k cycles.
This seems low and hurts my developer pride, so let’s try another approach.

Version 2: using smartmontools

smartmontools is an open source project and can be installed using brew install smartmontools.

It installs multiple utilities and the one that’s of interest is smartctl:

$ smartctl -a disk0
...
Available Spare:                    100%
Available Spare Threshold:          99%
Percentage Used:                    1%
Data Units Read:                    217,642,465 [111 TB]
Data Units Written:                 70,672,272 [36.1 TB]
...

Much more “respectable” numbers. The 36.1 TB is about 1% of those 3000 x 1 TB, and it’s also conveniently displayed in the “Percentage Used” column.

“Available Spare” is the percentage of the remaining spare capacity available for use. As the SSD wears down this could see a decrease, although the Disk Utility might continue to report the same size for the disk.

(Thanks MacWorld for the instructions and descriptions.)

LLM Pricing Calculator allows you to compare models and there it includes nice explanations like “1.33x input vs Gemini 2.0 Flash Lite, 1.33x output”.

Can also calculate operation pricing if the number of input and output (and cached) tokens are known.

The post has a really strong opener:

[…] the first week isn’t about reading the code. It’s about reading the signals.

The client already has opinions about what’s wrong. They’re usually partially right and almost always wrong about why. Your job in week one is to separate what looks bad from what’s actually dangerous.

Summary

This guide outlines a practical, week-one playbook for auditing legacy Ruby on Rails applications. Rather than starting in the code, begin by reading the signals: run stakeholder interviews to surface risky areas (deploy frequency, fear zones, blocked features), then form a working thesis by skimming three files—Gemfile, db/schema.rb, and config/routes.rb—to spot dependency duplication, god tables, missing indexes, integer primary-key risks, and architectural routing issues.

After the initial read, prioritize security and dependency scans (bundle audit, Brakeman, bundle outdated) before other tooling. Use SimpleCov zero-coverage files as a “fear map,” measure SLOC and complexity (cloc, RubyCritic), inspect model structure manually and run active_record_doctor and Bullet for DB and N+1 problems, and time the test suite to gauge developer feedback loops. Deliver a concise, single-page triage with prioritized risks and next steps rather than an exhaustive report; AI tools can accelerate repetitive parts of the audit but should complement, not replace, human judgment.

I think the lessons here are well structured and easy to “port” to other frameworks and languages, with appropriate file and tool modifications.

Source: How to Audit a Rails Codebase: Legacy App Playbook