donavanm

The normal term would be “velocity” of money, btw. Its a key consideration in addition to total supply whenever you need to evaluate inflation or manias.

Your understanding of monetary theory is somewhere between 110 and 5,000 years off. Furness had a pretty cogent explanation of a monetary system without central authority or functional currency about 100 years ago with the Yap. They even managed to have bouts of inflation without the concept of a bank or state.

Hahahaha, oh my. You think the world was some idyll halcyon pre bretton woods? My man Enmentrna is going to come back and declare a jubilee for your great revelation. When has any historic monetary system been “stable” for an appreciable amount of time. Debasement is a very literal ancient word and problem.

Even your straw man 20th century cut off is hilarious where you just kind of forget about 1873? Or maybe that decade is your shining example of the benefits of deflation. So much joy and global prosperity the peasants just forgot how to eat. Its cool, Bismarks destruction of the bimetallic system really helped usher in that age of stabikity from the international gold standards.

> The amount of data S3 stores "automatically replicating" to other geographical locations would make things prohibitively expensive

It did work like this! And it was! My recollection is that the first S3 was out of SEA and had no user concept of region. Then “VDC” was added in virginia. That provided API endpoints in what became us-east-1. A bucket could be accessed from either location, and the original intent was for object store to replicate between them. By the time dub/eu-west-1 came along that was obviously not tenable; itd take 10s of gbs to replicate.

So S3 became regional. But the original sea/vdc deployments still had shared APIs and data in both regions. Your object would be stored in the region of the API you geolocated to via DNS, but read from either. _eventually_ all the data migrated to IAD, but those API endpoints were transparently proxying across the continent until 2013 or so.

And of course glacier had much more interesting takes on this with cross dc/az/region erasure encoding. But i dont think any of the wacky multi dimensional cross region stuff ever materialised in practice.

PS: hi!

> why should you continue getting money off me and my customers?

Welcome to the concept of fair market value. Less snarkily you're conflating the concepts of price and cost; theyre not the same thing and theyre not the same for you or the seller.

Thats the “what it costs” section? Im a bit impressed if they are down to ~3ms per handshake. When I last looked at TPM signing (many years ago) it was more like single digit transactions per second.

That said, even 3ms TPM signatures are going to be for special cases or novelty. Plain old CPU tls will do about 1ms cpu time per request which will scale by cpu core count. One or two orders of magnitude more throughput per host.

yes, and you can do it entirely in developer instructions (AGENTS.md/SKILLS.md). No hooks or other executables needed. Check out `codex-subagent-router` for an example. Its overly complicated, and has a few things wrong, but it mostly works. In short:

  - Write ~1 paragraph of developer instructions (AGENTS.md): Use subagents for tasks that can be decomposed, worked on in parallel, or delegated. Describe common examples. I put a reference to a "how to use subagents" skill for more details. The "skill" isnt' always read (as subagents arent always useful) which saves some tokens. But you pay the once-per-session read-skill cost when its relevant.
  - Describe how to use subagents in ~1 page or less (SKILLS.md): use them for sub tasks. select model size/quality based on task ambiguity, scope, unbounded work, or conflicting requirements. Use reasoning effort for complexity, interdependence, or ambiguous success criteria. How to evaluate complexity & common subtask examples across the spectrum. give tasks a relevant name like "model-family_version_reasoning-effort_task-description" so you can actually understand what theyre doing by name.
  - in dev instructions (SKILLS.md) provide a table of agent names (low complexity summarizer, bounded implementation, complex implementation), model+effort (gpt-5.6-luna medium, gpt-5.6-luna high, gpt-5.6-sol medium), and short description of 2-3 task "types" for each.
  - Explain they can use "default" or specify their own custom model settings if needed.
  - Define your list of subagent profiles in ~/.codex/agents/ which matches names (low_complexity_summarizer.toml) from previous. In each you'll need to set model, reasoning, and `developer_instructions` that describe *how* to do a task, *not what* to do.

Details to know:

  - IMO subgent profiles are "task centric" because `developer_instructions` are required. You can't just specify model & reasoning, you also have to give valid developer_instructions that will be merged in to every session/prompt. I address this by defining a few different agents for tasks that are commonly encounted like summarization, synthesis, planning, implementation, etc. The different agent profiles (~2-5 per category) will "scale" the model + reasoning based on the complexity and ambiguity. This work pretty well in practice. And you don't need to over due it, the harness/agent can still launch a "custom" profile that uses the parent sessions developer instructions.
  - You need to use agent profiles with codex because "v2" models (terra & sol) can't launch "v1" models (luna). There are a couple of code paths to avoid this, the agent profile is the simplest. 

Anyways, write you skill & subagent profiles and it basically "just works".

Maybe cloudflares workload is substantially different, but i think youre missing just how long that tail was. A “lot”, maybe half, of unique objects werent requested a second time in any meaningful period time. Like days. And edge nodes have nowhere near the iops or cycles to spend doing _any_ extra work. So yes it is a waste of resources to cache or process in any way.

When I worked on a large CDN the content popularity distribution was heavily skewed. Think 20-40% of throughput from top 1% if content, and 80-90% from the top 10%. Anything outside of that had a very low probability if ever being read again in the effective cache lifetime.

Then the effective cost of scaling CPU > RAM > storage > network due to power & space limitations. Spending extra processing time on 50% of your content would be wasted effort as its never read again.

And yes, increasing effective storage might increase cache width/lifetime, but its not by that much to dramatically inprove access rates. Especially when most content by unique bytes is compressed audio/video in the first place.

NPUs, at least for apple, are built for relatively small scale efficient background processing. Theyre taking care of extracting structured metadata from freetext, recognizing people & text in photos, indexing file contents, etc. they do this really well with crazy low power draw. Theyre generally not even a target for current inference frameworks ala ollama, pytorch, etc.

I did see one prototype someone built using private ios APIs a few months back. They were able to run a reasonable SLM about an order of magnitude slower than GPU but with a tiny power draw.

There are, internally, and theyre pretty good. I always tried to use the AWS Docs style guide when writing internally, for example. Theyre specific on how to refer to products vs services vs features, which nouns to use, tone, grammar, etc.

PS: you might get tripped up on 0x00, 0x2F, or similar control characters? As i recall any valid octet can be included in a label. We definitely saw literal ‘*’ and ‘.’ inside labels. And I wouldnt be surprised to find a bell in there either.

This is just the era of AWS (and amazon APIs). A lot of them look like SOAPy xml rpc because thats how they started, based on internal service frameworks. Check out SQS or S3 for similar examples.

Around 2010-11 there was a shift towards RESTish structures and json for serialization. A lot of methods and payloads still feel SOAPy, but look like json. I think it was DynamoDB which had the most unfortunate API with a literal xml-json transform live in the API service.

And then somewhere around 2015 you started seeing more well defined RESTish APIs with better tooling and adoption for smithy (and some openapi, iirc).

The damage estimate they use will be hypothetical total replacement cost, including multiple employees time, truck use, permits etc. its very trivial for any sort of repair to have a nominal cost in the thousands.

Same again here in AU. Pretty sure i paid about $800 for the labor of installation (inc in the $2500) on top of material. Im more than comfortable with construction/electrical/plumbing. But at that price I stay off the roof, off a ladder, dont have to muck with extending a 240v circuit, and save a solid day if my time. Worth the price.

Yeah, vaguely aware that you could diy the entire setup with refrigerant etc. But its not relevant at local prices here in AU.

One of the interesting things I noticed here is that manufacturers are providing exchangers and head units that can reuse existing pipes. Makes sense for retrofit/upgrades where running pipes through utility spaces and bulkheads is a significant labor cost.