> 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".
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.
You are making an argument against caching it at all which is clearly not what they want. So the comparison must be uncompressed storage vs compressed storage.
The compression cost is always the same. The storage cost depends on how long you keep something in cache. The decode cost is proportional to number of total hits.
So compression makes the most sense for something you want to keep a long time that will be accessed very rarely. And the least sense for something you will drop very soon and will have many people requesting it.
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.
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.
Hypothetical damages only make sense if he was charged with a lesser crime of "attempted" X... however I don't see that modifier in the news reporting. My concern is that the prosecution is trying to mix-and-match the severity of factual crimes with theoretical outcomes in a way which is illogical and unjust.
IANAL, but for example the article says they're charging him with real (not attempted) criminal mischief over $1,000. Looking it up [0] that reads as requiring a threshold of actual damage in dollars.
It's as if someone was charged with real (not attempted) first-degree murder despite the "murdered" person walking around totally unharmed. That'd be nonsense, right? We'd at least be asking what kind of brain-damage caused the prosecutor to do that instead of lowering it to "attempted murder".
There's different section [1] about attempts in a very general sense, but even then it's not clear how the math works when it was a setup and real assets were never in danger.
Same in Australia/East Asia generally. Had a mid range daiken 3kw unit installed upstairs last summer; $2500 AUD and ~5 man hours to install including roof access and exterior wall mounting. A bigger 7kw multi head unit would have been about $6-7k AUD but required awkward attic and wall access.
Installed prices in the US are pretty silly. Theres a bourgeoning set of DIY units that come precharged. But even those are pricey compared to the rest of the world.
Just FYI, there's no reason at all to buy the DIY kits over just a regular mini split. The difference is DIY kits come with the lines pre-vacuumed and with seals on the end of them. So when you finally connect everything, the lines don't need a vacuum drawn on them prior to allowing the refrigerant into them.
A vacuum pump costs about $100. Just get a regular cheap mini split and vacuum the lines yourself, and save $1,000 or more.
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.
Well it does absolutely affect the price if you are willing to do it yourself. You don't need to actually touch any refrigerants. They are all preloaded in all the mini splits for sale. You just need to get the air out of the lines so it doesn't mix with the refrigerant.
If I were to have it installed, just about any "professional" will totally overcharge here in the US too.
Here in Norway you must use a certified installer. That said, it wasn't horribly expensive, unless you have some weird constraint. I paid $600 for installing the last minisplit, which included some electrical work and a slightly more expensive spring-dampened mount, as well as 25% VAT. And Norway ain't exactly know for cheap labor.
Interesting, what happens if you just don't, and do it yourself?
However, if I could have them installed for $600, I wouldn't bother doing it myself. We have a little bit of a cartel behavior with AC installers at least in my area of the US. Even though the job has gotten much easier with mini splits being requested more, they're unwilling to give up the amount they were making per job with Central units.
> Interesting, what happens if you just don't, and do it yourself?
A fine I presume, if someone figures out. You'd have to get the unit second hand or similar, all stores are required to ensure you've ordered an installation from a certified company when they sell it AFAIK. Last ones I bought, a few years apart, had it all integrated in the web shops. Just selected installation company from a dropdown, fixed price for basic install.
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.
> Would be great if companies only had to report once a year.
Why and how would it be in the public or shareholder interest?
Im unaware if any public market where similar reductions in reporting led to significant, positive, outcomes. FTSE is the common example. They had a similar “reform” circa ‘14 and FTSE companies continue to generally under perform while the LSE continues to lose listings.
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.
reply