Airlines are not great business. Margins are not great. Fuel is significant part of their operating costs. And if it goes up too much in too short time the whole model breaks. Less margins you have the more you will be impacted. So if you are operating at edge by default fast move in costs will destroy you.
The business model works fundamentally differently in the US and Europe due to geography. The US is big, meaning that flights are often longer, meaning that fuel is a bigger portion of the operating cost. And fuel is essentially something airlines can’t reduce the cost of compared to other operating costs where it might be possible to optimize for greater efficiency.
Europe has passenger trains that work. What would be a short flight in the US, e.g. London to Paris is done more my train through the chunnel than flying unless you got a connecting flight.
USA average flight length (I could only find old data, 2005): 1,110km [1] (even if we index this up based on upward trends, maybe another 150km, that doesn't seem a huge difference to me?)
> The US is big
And Europe is big too. It's actually a bit bigger than the USA by land size.
Btw, IAG is a global airline group. Only ~32% of IAGs revenue is intra-Europe and domestic. Another data point: Turkish Airlines (very long-haul focused airline) 2025 net income margin was 12.1% in 2025.
I'm not sure your explanation is sufficient. I don't see the exception in the USA? I am certainly willing to accept there are other differences and challenges in the USA, but I don't think it's been presented yet in this discussion.
And remember the original claim was "Airlines are not great business. Margins are not great"
--
EDIT: I found https://www.airportroutes.com/airlines/NKS/ which does highlight that Spirit flew lengths longer compared to Europe's average, at 1,577 km - but then using the same source for Ryanair https://www.airportroutes.com/airlines/RYR/ it's 1,456km, so again, not a huge difference. So comparing 2 seemingly very similar airlines, the European one has both managed to be profitable and not go bankrupt...
How are you counting average distances? Simply as the distance between two points in the carrier’s network, or are you looking at the lengths of each individual flight?
The source for the point I made is a Wendover video - Why Budget Airlines are Suddenly Failing
You need to look at things like average distance and median distance, do some filtering for most common destinations (example: NYC to LA, San Francisco to Miami, Denver to DC, etc), fuel costs, but also operating costs. Salaries and everything cost much more in the US than they do in Europe.
Cost Per Seat Mile is $0.07 for RyanAir and $0.12 for Spirit, not counting fuel. Spirit hovers around 80% capacity while RyanAir is around 94%.
RyanAir's niche is secondary airports while Spirit was compeating with larger airlines at places like LAX where gate costs are higher.
In 2024 to 2025 there was an engine problem that required Spirit to ground 40% of the fleet to deal with it. Meanwhile they still had to pay for those aircraft with no revenue. This caused a major hit to the financials for a carrier that already runs on thin margins.
I'm sure there's more to it, but these are the larger things I've found.
Definitely a good point about CASM. Thanks for highlighting. I do see it's one of the lowest in the industry though
Fuel obviously plays a big part. Guess they also got unlucky with the engines (though could they have made better choices? Perhaps a Franco-American engine company like Ryanair ? ;)
> Salaries and everything cost much more in the US than they do in Europe.
Doesn't that mean they can charge more? We're regularly told the USA is rich and Europe is poor, so the customers must be able to pay more.
> Spirit hovers around 80% capacity while RyanAir is around 94%.
Spirit could have gotten better at filling seats. Perhaps learning from Ryanair. Or is there some thing in the USA that prevents exceeding 80% capacity? US customers not liking planes beyond 80% capacity?
It makes me think their business surviving was highly dependant on low fuel prices? So the collapse was a shock to nobody in the industry?
> It makes me think their business surviving was highly dependant on low fuel prices?
Basically.
The entire modern economy depends on the price of gas/diesel/jet fuel being between $X and $Y. If it goes outside of those parameters for too long, everything shuts down. Oil gets too expensive or too cheap to extract and refined and transport, then the money goes other places.
The immediate cause was rising fuel prices. The other issue sounds like it was poorly ran.
More generally, it is also a low cost carrier at a time when, after years of competing on price, airlines are seeing people willing to pay more for a better experience. All other carriers are expanding their premium options, catering to the affluent part of the K economy (for the first time ever the majority of Delta revenue came from premium cabins over main). Meanwhile, Spirit was dealing on the other side of the K who is also most impacted by increasing inflation, etc... giving Spirit zero ability to raise prices.
> Meanwhile, Spirit was dealing on the other side of the K who is also most impacted by increasing inflation, etc... giving Spirit zero ability to raise prices.
Ryanair (Europe's biggest and most profitable airline) is managing it OK [0]
What's difference about that side of the K in the USA vs Europe?
Thanks for sharing. Interesting how fuel isn't mentioned once (other comments here have suggested it's mostly to do with fuel). Only possibly indirectly via cost per air seat mile (CASM), but AIUI airlines frequently exclude fuel from that
IMO Spirit's bad business decisions should be acknowledged.
This story is about a particular airline failing (out of all the others that aren't). Do you think Spirit airline's situation is something serious I should have been keeping up with? I do drive a car and get gas, and the price increase has been modest but not alarming, in the context of the last decade.
The war in Iran was the final nail in the coffin. But they were running out of cash for the past few years. If the Iran situation was so bad by itself, we would surely see other airlines failing now.
Spirit could simply be the first of several; the effects may also be delayed. WGA isn't looking good either, for a number of reasons.
Just because it's the first doesn't mean it will be the only one. It goes without saying but apparently you need to be told that there has to a first here, after all. The war is only 2 months in. Full clarity won't come for 2-3 years. It's likely several airlines will take hits on their balance sheets from this that they won't be able to recover from, but they'll fight or go into hardcore refinance mode or get bailed out before actually going bankrupt, but this will remain the ultimate cause.
You asked if this was caused by or related to bad customer service. This was 100% caused by the increase in jet fuel prices due to the war in Iran. Obviously huge swings in jet fuel prices affect budget carriers more than, say, United or American or Lufthansa or Singapore Airlines, which have many (many) more options when jet fuel prices rise.
Many countries, including many third world countries, have regional airlines. It has nothing to do with America in particular, and the usage of that term is not an American-ism. A good non-American example is Qantas and QantasLink, the latter being a regional airline, and the Aussies refer to it as such.
That really sounds line the US is the only country in the world. Considering the world is bigger, I would call Spirit maybe regional, but not small. Ask some europeans, basically no one will know Spirit - as US people may not know e.g. Wizz.
This is a tough moment. Claude is simultaneously becoming substantially more expensive, substantially less reliable (single 9 of reliability), and substantially less performant. It's really hard to justify the cost of a subscription over there right now.
There was another thread where some people pointed out, Amazon will give you access to Claude with better uptime for the same price (per million tokens up / down), downside is, it does not have the native ability to browse the web, but maybe that's a hidden blessing, since it's less likely to read some random website that has prompt injection embedded into it.
For coding its fine, I havent experimented too much with Amazon Bedrock myself, but I just might soon to check for any limitations.
Maybe the best play is to set up a routing system locally so that when claude.ai is down it automatically switches to Amazon billing and switches back when it comes back up
Correct, but in the case that they brought it up, their employer was on a enterprise license, which is still pay per token. The subscription will eventually go away in some way, or cost way more than it does.
From an economics perspective, it makes sense to make it more expensive if you're having trouble keeping up with demand for a service. It'll be tough getting used to because it was so nice and cheap
On the other hand, it was somewhat expected that we would have a correction for the prices. Hopefully after this correction things will be more stable and we won't have to worry too much about future price increases
YMMV. I would still be very happy with Claude if it hard failed on 20% of tasks. You can always come back to it.
I say this as someone working for a tech company who does not have to foot the bill (in the >$1k per month bracket)
I also experienced and accept the 1990s levels of unreliability, which is my “internet generation”. My first access was lifting a handset and placing on a speaker/mic cradle.
Programmers these days are fucking spoiled. If it’s $220 worth of value for $200 - I get it. But I’m getting $100k of value for $10k and so I’ll put up with some shit.
Not to mention substantially less open. I've been using an OpenAI subscription in Pi Agent for a couple weeks now and it's great. And from what I can tell, 5.5 is a heck of a model.
Interestingly, yeah, I can see that this would really cut into your subscription usage with the 5 hour rate limit windows...
I am an API user, and while it being down is super annoying, it isn't really as big of a hit to my overall usage as I can just prepare a bunch of stuff to run in parallel when it does come back up.
Plus, they've dumbed down their models to the point where the value just isn't there like it was. If I have to go in and clean up after it, or constantly wrestle with it through prompts, what's the point? Just spending $200 a month to be frustrated at a machine.
It's lazy, does not take ownership and responsibility, wants to defer work, and I have to force it to check reality. It likes to guess and assume it's correct and I am wrong. Agents.md is not helping at all. It's in full enshittification phase, yay!
Single nine has good vibes bro. It means when the service is up the results are better. I read about it in a blog. The model hallucinates way less. Even less than grok
I wonder how this kind of response from Anthropic is actually being read by the community at large. If you consider the rough sentiment of the r/ClaudeCode subreddit against the r/Codex subreddit, you can see that there is a definite loudness among the folks departing ClaudeCode for Codex. Something big is shifting on the ground, I think.
I'm not really sure what to do here. I refuse to give Altman money, but Anthropic keeps disappointing me over and over with crap like this. Gemini seems behind? Not touching Grok.
Meanwhile I've integrated CC into my workflow enough that I'd feel frustrated cutting out all LLM agent use.
I don't have the hardware to run models locally, and I'm not excited about the idea of spending that money. I could use a different harness with one of the services that runs open-weight models for me, but I feel like the cost would be prohibitive. I'm paying $100/mo right now and that's all I'm willing to spend.
Personally tried GLM subscription. Bought it during new years discount: 36$ for a YEAR.
Cannot burn tokens through with personal project use. From what I can see in stats they allow 25-100M tokens in 5h period (for cheapest plan), depending on the model. GLM5.1 could be a bit slower and likes to (over)think, but I don't see practical differences from Sonnet 4.6 or Opus 4.6.
> I refuse to give Altman money, but Anthropic keeps disappointing me over and over with crap like this. Gemini seems behind? Not touching Grok.
My thought process is totally the same. And even there's slight concern about ethics using GLM, at least in my conciousness, openai is worse and grok is the worst of them all by far, no competition.
I'm not sure if the context limit on the $25/m, and model-size limit on the $100/m would make it not work well enough for OpenCode, but Featherless AI seems a bit unique in terms of how they handle their inference plans.
It’s an agreement between a public company and a highly scrutinized private company. Several of the provisions will change what happens in the marketplace, which everyone will see.
I imagine the thinking was that it’s better to just post it clearly than to have rumors and leaks and speculations that could hurt both companies (“should I risk using GCP for OpenAI models when it’s obviously against the MS / OpenAI agreement?”).
Strix halo has 256 GB/s bandwidth for $2500.
The Flash model has 13 GB activations.
256 / 13 = 19.6 tokens per second
Except you cannot fit it into the maximum RAM of 128 GB Strix Halo supports. So move on.
Another option is Threadripper. That's 8 memory channels. Using older DDR4-3200 you get roughly 200 GB/s. For $2000.
200 / 13 = 15.4 tokens per second
But, a chunk of per-token weights is actually always the same and not MoE, so you would offload that to a GPU and get a decent speedup. Say 25 tokens per second total.
Then likely some expensive Mac. No idea.
Eventually you arrive at a mining rig chassis with a beefy board and multiple GPUs. That has the benefit of pipelining. You run part of the model on one GPU and move on, so another batch can start on the first one. Low (say 30-100) tps individually, but a lot more in parallel. Best get it with other people.
For flash? 4 bit quant, 2x 96GB gpu (fast and expensive) or 1x 96GB gpu + 128GB ram (still expensive but probably usable, if you’re patient).
A mac with 256 GB memory would run it but be very slow, and so would be a 256GB ram + cheapo GPU desktop, unless you leave it running overnight.
The big model? Forget it, not this decade. You can theoretically load from SSD but waiting for the reply will be a religious experience.
Realistically the biggest models you can run on local-as-in-worth-buying-as-a-person hardware are between 120B and 200B, depending on how far you’re willing to go on quantization. Even this is fairly expensive, and that’s before RAM went to the moon.
There is no BF16. There is no FP8 for the instruct model. The instruct model at full precision is 160 GB (mixed FP4 and FP8). The base model at full precision is 284 GB (FP8). Almost everyone is going to use instruct. But I do love to see base models released.
Run on an old HEDT platform with a lot of parallel attached storage (probably PCIe 4) and fetch weights from SSD. You'd ultimately be limited by the latency of these per-layer fetches, since MoE weights are small. You could reduce the latencies further by buying cheap Optane memory on the second-hand market.
The low end could be something like an eBay-sourced server with a truckload of DDR3 ram doing all-cpu inference - secondhand server models with a terabyte of ram can be had for about 1.5K. The TPS will be absolute garbage and it will sound like a jet engine, but it will nominally run.
The flash version here is 284B A13B, so it might perform OK with a fairly small amount of VRAM for the active params and all regular ram for the other params, but I’d have to see benchmarks. If it turns out that works alright, an eBay server plus a 3090 might be the bang-for-buck champ for about $2.5K (assuming you’re starting from zero).
Mythos is only real when it's actually available. If you're using Opus 4.7 right now, you know how incredibly nerfed the Opus autonomy is in service of perceived safety. I'm not so confident this will be as great as Anthropic wants us to believe..
I've found myself so deeply embedded in the Claude Max subscription that I'm worried about potentially makign a switch. How are people making sure they stay nimble enough not to get trarpped by one company's ecosystem over another? For what it's worth, Opus 4.7 has not been a step up and it's come with an enormously higher usage of the subscription Anthropic offers making the entire offering double worse.
Start building your own liteweight "harness" that does things you need. Ignore all functionality of clients like CC or Codex and just implement whatever you start missing in your harness.
You can replace pretty much everything - skills system, subagents, etc with just tmux and a simple cli tool that the official clients can call.
Oh and definitely disable any form of "memory" system.
Essentially, treat all tooling that wraps the models as dumb gateways to inference. Then provider switch is basically a one line config change.
> You can replace pretty much everything - skills system, subagents, etc with just tmux and a simple cli tool that the official clients can call.
I'm very interest by this. Can you go a bit more into details?
ATM for example I'm running Claude Code CLI in a VM on a server and I use SSH to access it. I don't depend on anything specific to Anthropic. But it's still a bit of a pain to "switch" to, say, Codex.
How would that simple CLI tool work? And would CC / Codex call it?
Check out github.com/ralabarge/beigebox -- OSS AI Harness, started as a way to save all of my data but has agentic features, MCP server, point it at any endpoint (or use any front end with it as well, transparent middleware)
So far what I am finding is that you just get the basics working and then use the tool and inference to improve the tool.
Initially I read it because just it was interesting but it has ended up being the harness I have stuck with - pi is well designed, nicely extensible and supports many model provider APIs. Though sadly gemini and claude's subscriptions can't really be used with it anymore thanks to openclaw.
I wish I had lower standards towards sharing absolute AI slop, then I could just drop a link to my implementation. But since I don't, let me just describe it. I essentially had claude build the initial version in a single session which I've been extending as I noticed any gaps in my process.
First, you need an entrypoint that kicks things off. You never run `claude` or `codex`, you always start by running `mycli-entrypoint` that:
1. Creates tmux session
2. Creates pane
3. Spawns claude/codex/gemini - whichever your default configured backend is
4. Automatically delivers a prompt (essentially a 'system message') to that process via tmux paste telling it what `mycli` is, how to use it, what commands are available and how it should never use built-in tools that this cli provides as alternatives.
After that, you build commands in `mycli` that CC/Codex are prompted to call when appropriate.
For example, if you want a "subagent", you have a `mycli spawn` command that takes a role (just preconfigured markdown file living in the same project), backend (claude/codex/...) and a model. Then whenever CC wants to spawn a subagent, it will call that command instead, which will create a pane, spawn a process and return agent ID to CC. Agent ID is auto generated by your cli and tmux pane is renamed to that so you can easily match later.
Then you also need a way for these agents to talk to each other. So your cli also has a `send` command that takes agent ID and a message and delivers it to the appropriate pane using automatically tracked mapping of pane_id<>agent_id.
Claude and codex automatically store everything that happens in the process as jsonl files in their config dirs. Your cli should have adapters for each backend and parse them into common format.
At this point, your possibilities are pretty much endless. You can have a sidecar process per agent that say, detects when model is reaching context window limit (it's in jsonl) and automatically send a message to it asking it to wrap up and report to a supervisor agent that will spawn a replacement.
I also don't use "skills" because skills are a loaded term that each of the harnesses interprets and loads/uses differently. So I call them "crafts" which are again, just markdown files in my project with an ID and supporting command `read-craft <craft-id>`. List of the available "crafts" are delivered using the same initialization message that each agent gets. If I like any third party skill, I just copy it to my "crafts" dir manually.
My implementation is an absolute junk, just Python + markdown files, and I have never looked at the actual code, but it works and I can adapt it to my process very easily without being dependent on any third party tool.
I have a directory of skills that I symlink to Codex/Claude/pi. I make scripts that correspond with them to do any heavy lifting, I avoid platform specific features like Claude's hooks. I also symlink/share a user AGENTS.md/CLAUDE.md
MCPs aren't as smooth, but I just set them up in each environment.
It's surprisingly simple to switch. I mean both products offer basically identical coding CLI experiences. Personally I've been paying for Claude max $100, and ChatGPT $20, and then just using ChatGPT to fill in the gaps. Specifically I like it for code review and when Claude is down.
I bumped from $20 -> $100 today but the Codex CLI lacking code rewind and "you can change files but ask me every time" mode from Claude Code is quite annoying. Sometimes I want to code, not vibe code lol.
I use Open Code as my harness. It's open source, bring your own API Key or OAuth token or self-hosted model. I've jumped from Opus 4.6 to Opus 4.7 to GPT 5.5 in the last 7 days. No big deal, intelligence is just a commodity in 2026.
The actual harness is great, very hackable, very extendable.
Yeah, for direct to Claude you need an API key. You can use other subscriptions like GitHub Copilot that expose Claude, but that path has been blocked.
As a rule I've been symlinking or referencing generic "agents" versions of claude workflow files instead of placing those files directly in claude's purview
This might be the opposite of staying nimble as my workflows are quite tied to Claude Code specifically, however I've been experimenting with using OpenAI models in CC and it works surprisingly well.
Except for history, I don’t find much that stops you from switching back and forth on the CLI. They both use tools, each has a different voice, but they both work. Have it summarize your existing history into a markdown file, and read it in with any engine.
The APIs are pretty interchangeable too. Just ask to convert from one to the other if you need to.
Coding models are effectively free. They are capable of making money and supporting themselves given access to the right set of things. That is what I do
I switched a couple of weeks ago just to see how it went. Codex is no better or worse. They’re both noticeably better at different things. I burn through my tokens much much faster on Codex though. For what it’s worth I’m sticking with Codex for now. It seems to be significantly better at UI work although has some really frustrating bad habits (like loading your UI with annoying copywriting no sane person would ever do).
reply