If we want to be like everyone else then yes it's true. However that business may or may not survive when token costs go up (or is fashionable to say now, "rug pull"). If you can be token efficient now, the path to profitability is much clearer.

There's already many things that can be done now to bring down token use. Better planning, tests, Language severs, MCP compression. Don't use claw, teams, swarms, Ralph loop, scheduled tasks unless there is a clear use case.

If token cost goes up, then the efficiency gains come from using fewer tokens... which is likely possible.

The point is that efficiency comes after, not before.

seems like what you're suggesting to token efficiency is to simply use less of it?

Less or be more productive with same amount?

Good analysis. if I was the author I would have just borrowed 20k in a personal loan and paid it off in three years. Of course he may be exaggerating that he gets 9K in Ad revenue per year or he knows that it's going to decline

It's all true but the cafeteria is generally outsourced. Those employees are not on the books of the real enterprise and the software shared between all of the outsourcers customers. Same goes for many non-core functions.

I can confirm for a certain very large enterprise that this is not the case. The employees ARE on the books of the company and considered full time employees with full benefits, and the software is custom built for this enterprise, by this enterprise, and not shared with any other enterprises

I feel better working at a company when the support staff are also working for the same company.

Good, they want you not asking a single question, your paycheck obviously requires it.

I don't see how this follows

Apple being Apple

Yeah, like I don't think ARA could build a mobile app for ordering at a cafeteria, period.

Exactly

I would not have wasted my time and yours if Bon Appetit was running it.

It's not limited though there are alternative providers even now, much less when the price goes up. Chinese providers, European ones, local models.

> It's not limited though

Inference is not free, so all providers have a financial limit, and all providers have limited GPU/memory, so there's a physical material limit.

I suggest looking at the profits of these companies (while they scramble to stay competitive).

Anyone can be a student though. Senior discount is definitely legal positive discrimination.

SF has tall buildings downtown, so that can't be it. A better question is, why are they only downtown and not so much west of there.

It's possible, just expensive. Just like everything else about SF.

how come japan has crazy tall buildings despite getting an earthquake few times every year?

Only 2.8k non OLED display?

Genuinely surprised MSN still exists

correct

it's explained in README:

> Category: River, Que, and pg-boss (and Oban, graphile-worker, solid_queue, good_job) are job queue frameworks. PgQue is an event/message queue optimized for high-throughput streaming with fan-out.

This fan out approach plus something like Kafka consumer groups is often a better approach to getting workers to take from the same pool anyways, because you can do key based partitioning and therefore have semi stateful consumers (cache, partitioned inserts etc) that are fed similar work.

If your company is making $1 mil per employee per year, then 10% is 100k. Even at 500k employee or lesseer numbers it's almost always better to buy the $1000/month tool (break even is a measly $108k revenue per employee per year)

It's not just about cost, it's about having the control, stability, and autonomy of on-prem. Plus you can probably repurpose that compute when employees are out of the office.

Anyways, I'm just saying it's not so simple ;)