Astra planner/designer with Sol+Luna subagents has worked well for me to improve context continuity. Luna generates code, Sol reviews code and runs/monitors integration/E2E tests. It's about 20% more usage efficient and 20% faster to finish tasks. I've been very subagent-skeptic for a while but the economics of codegen with Luna have made it click. This just works in Codex with a single-line AGENTS.md instruction.

Do you mind sharing? I would love to give it a try and see if I can stretch the x5 plan further.

How do you do this?

Tell the model, spawn a <model_n> to do <task_n> and it will do it

Assuming you are doing coding, I'm curious how would you characterize tne majority of your work (language, domain, frontend/backend, etc)?

iOS development mostly. I'm using the Pro plans as it's work on personal projects outside my day job and I'm able to get just enough usage from those plans to get me through each day.

This is why wait-free and lock-free are separate concepts. Author is not claiming wait-free.

Obstruction-free, lock-free, and wait-free are increasingly strong guarantees for non-blocking synchronization mechanisms. A sequence lock is a blocking synchronization mechanism and therefore provides none of the aforementioned guarantees.

No, it's neither wait-free nor lock-free. Wait-free guarantees all threads make progress, lock free guarantees at least one thread makes progress even if another thread is suspended or dead.

Note that GPT-5.6-Sol is ~2x as token efficient as Opus/Fable, so a 258K max is equivalent to ~516K on Claude models. You also may just be fooling yourself, as context rot is still a problem[1][2] and there's evidence compaction can be equivalent or better than longer context windows for agentic tasks[3]. Obviously it would be best if the models could reason over 1M context like they do over 256K context, but they can't yet.

[1] https://arxiv.org/abs/2605.12366 [2] see F1 of GraphWalks 256K vs 1M in Opus 4.8 System Card: https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f... [3] https://context-folding.github.io/

The improved token efficiency would only account for the output and reasoning tokens occupying context, right? What about the user messages and other context like file contents? I’m not sure how these measure up in a long conversation

For agentic use it impacts input tokens because the output is fed back into the model as input on subsequent turns.

it does not require training a model from scratch for it to be updated. the entire LLM training process is iterative. essentially each step (there are hundreds/thousands for a training run) yields a complete, usable model. tokens with updated data can be added on top essentially at any time in the future.

That's good to know, but I think maybe the bulk of the original point is still concentrated in the "we always need new models to stay relevant" piece.

You are correct. As a point of comparison: almost ten years ago at Segment we had a single Aurora PostgreSQL instance with ~50T of data, it was used to index potential identity data in a much larger corpus of files stored in S3.

I think it's more that the requested information is prominently featured in the article, and indeed is the content of the only graphic in the article below the intro banner.

He’s talking about AI scanning tools collectively, not specifically Mythos.

If you read his own top comment on that LinkedIn post he clarifies:

“The simple reason is: the (AI powered) tools are this good now. And people use these tools against curl source code.They find lots of new problems no one detected before. And none of these new ones used Mythos. Focusing on Mythos is a distraction - there are plenty of good models, and people who can figure out how to get those models and tools to find things.”

Sure. But Mythos or not, the developments since that post was written, legitimate 11 more vulnerabilities have been found by AI tools.

Wait, 11 vulnerabilities were discovered entirely in the timeframe after Mythos found 1? That seems like it would effectively debunk the theory that curl was so uniquely hardened that only 1 vulnerability even existed for Mythos to find, which I read numerous times back on the HN thread for the curl/Mythos blog post.

As one of those commenters on the previous post - yep, that theory appears to have been comprehensively trounced. Unless anything comes to light that mythos was applied poorly to curl, the evidence suggests that it’s not uniquely effective vs other AI-assisted approaches. I’ll be interested to see what’s reported in the next curl release.

Biggest thing to watch out with this approach is that you will inevitably have some failure or bug that will 10x, 100x, or 1000x the rate of dead messages and that will overload your DLQ database. You need a circuit breaker or rate limit on it.

I worked on an app that sent an internal email with stack trace whenever an unhandled exception occurred. Worked great until the day when there was an OOM in a tight loop on a box in Asia that sent a few hundred emails per second and saturated the company WAN backbone and mailboxes of the whole team. Good times.

This is the same risk with any DLQ.

The idea behind a DLQ is it will retry (with some backoff) eventually, and if it fails enough, it will stay there. You need monitoring to observe the messages that can't escape DLQ. Ideally, nothing should ever stay in DLQ, and if it does, it's something that should be fixed.

What do you use for the monitoring of DLQs?

At my last workplace, we used pure AWS Cloudwatch. At my new workplace, we use Grafana+Sentry

This! Only thing worse than your main queue backing off is you dropping items from going into the DLQ because it can’t stay up.

If you can’t deliver to the DLQ, then what? Then you’re missing messages either way. Who cares if it’s down this way or the other?

Not necessarily. If you can't deliver the message somewhere you don't ACK it, and the sender can choose what to do (retry, backoff, etc.)

Sure, it's unavailability of course, but it's not data loss.

If you are reading from Kafka (for example) and you can't do anything with a message (broken json as an example) and you can't put it into a DLQ - you have not other option but to skip it or stop on it, no?

Your place of last resort with kafka is simply to replay the message back to the same kafka topic since you know it's up. In a simple single consumer setup just throw a retry count on the message and increment it to get monitoring/alerting/etc. Multi consumer? Put an enqueue source tag on it and only process the messages tagged for you. This won't scale to infinity but it scales really really far for really really cheap

Generally yes, but if you use e.g. the parallel consumer, you can potentially keep processing in that partition to avoid head-of-line blocking. There are some downsides to having a very old unprocessed record since it won't advance the consumer group's offset past that record, and it instead keeps track of the individual offsets it has completed beyond it, so you don't want to be in that state indefinitely, but you hope your DLQ eventually succeeds.

But if your DLQ is overloaded, you probably want to slow down or stop since sending a large fraction of your traffic to DLQ is counter productive. E.g. if you are sending 100% of messages to DLQ due to a bug, you should stop processing, fix the bug, and then resume from your normal queue.

Sorry, but what's stopping the DLQ being a different topic on that Kafka - I get that the consumer(s) might be dead, preventing them from moving the message to the DLQ topic, but if that's the case then no messages are being consumed at all.

If the problem is that the consumers themselves cannot write to the DLQ, then that feels like either Kafka is dying (no more writes allowed) or the consumers have been misconfigured.

Edit: In fact there seems to be a self inflicted problem being created here - having the DLQ on a different system, whether it be another instance of Kafka, or Postgres, or what have you, is really just creating another point of failure.

> Edit: In fact there seems to be a self inflicted problem being created here - having the DLQ on a different system, whether it be another instance of Kafka, or Postgres, or what have you, is really just creating another point of failure.

There's a balance. Do you want to have your Kafka cluster provisioned for double your normal event intake rate just in case you have the worst-case failure to produce elsewhere that causes 100% of events to get DLQ'd (since now you've doubled your writes to the shared cluster, which could cause failures to produce to the original topic).

In that sort of system, failing to produce to the original topic is probably what you want to avoid most. If your retention period isn't shorter than your time to recover from an incident like that, then priority 1 is often "make sure the events are recorded so they can be processed later."

IMO a good architecture here cleanly separates transient failures (don't DLQ; retry with backoff, don't advance consumer group) from "permanently cannot process" (DLQ only these), unlike in the linked article. That greatly reduces the odds of "everything is being DLQ'd!" causing cascading failures from overloading seldom-stressed parts of the system. Makes it much easier to keep your DLQ in one place, and you can solve some of the visibility problems from the article from a consumer that puts summary info elsewhere or such. There's still a chance for a bug that results in everything being wrongly rejected, but it makes you potentially much more robust against transient downstream deps having a high blast radius. (One nasty case here is if different messages have wildly different sets of downstream deps, do you want some blocking all the others then? IMO they should then be partitioned in a way so that you can still move forward on the others.)

I think that you're right to mention that if the DLQ is over used that that potentially cripples the whole event broker, but I don't think that having a second system that could fall over for the same reason AND a host of other reasons is a good plan. FTR I think doubling kafka provisioned capacity is simpler, easier, cheaper, and more reliable approach.

BUT, you are 100% right to point to what i think is the proper solution, and that is to treat the DLQ with some respect, not a bit bucket where things get dumped because the wind isn't blowing in the right direction.

I am the author of th is article.Thank you for reading and important the insight and I second your opinion about DLQ flooding. We have the following strategy configured in our consumers to avoid DLQ flooding

ExponentialBackOffWithMaxRetries backOff = new ExponentialBackOffWithMaxRetries(3);

backOff.setInitialInterval(2000L); // 2 seconds initial delay

backOff.setMultiplier(2.0); // Exponential backoff

backOff.setMaxInterval(30000L); // Max delay 30 seconds

backOff.setMaxAttempts(3); // Retry 3 times before DLQ

Updated this in my blog.

The point is to not take the whole server down with it. Keeps the other applications working.

Sure, but you still need to design around this problem. It’s going to be a happy accident that everything turns out fine if you don’t.

Could one put the DLQ messages on a queue and have a consumer ingest into pg?

(The queue probably isnt down if you've just pulled a message off it)

It will happen eventually in any system.

No need to look down on PG because it makes it more approachable and is more longer a specialized skill.

This is explicitly called out in the blog post in the trade-offs section.

I was one of the engineers who helped make the decisions around this migration. There is no one size fits all. We believed in that thinking originally, but after observing how things played out, decided to make different trade-offs.

To me it sounds like so: "We realized that we were not running microservice architecture, but rather a distributed monolith, so it made sense to make it a regular monolith". It's a decision I would wholeheartedly agree with.

I don't think you read the post carefully enough: they were not running a distributed monolith, and every service was using different dependencies (versions of them).

This meant that it was costly to maintain and caused a lot of confusion, especially with internal dependencies (shared libraries): this is the trade-off they did not like and wanted to move away from.

They moved away from this in multiple steps, first one of those being making it a "distributed monolith" (as per your implied definition) by putting services in a monorepo and then making them use the same dependency versions (before finally making them a single service too).

I think the blog post is confusing in this regard. For example, it explicitly states:

> We no longer had to deploy 140+ services for a change to one of the shared libraries.

Taken in isolation, that is a strong indicator that they were indeed running a distributed monolith.

However, the blog post earlier on said that different microservices were using different versions of the library. If that was actually true, then they would never have to deploy all 140+ of their services in response to a single change in their shared library.

Shared telemetry library, you realize that you are missing an important metric to operationalize your services. You now need to deploy all 140 to get the benefit.

Your runtime version is out of date / end of life. You now need to update and deploy all 140 (or at least all the ones that use the same tech stack).

No matter how you slice it, there are always dependencies across all services because there are standards in the environment in which they operate, and there are always going to be situations where you have to redeploy everything or large swaths of things.

Microservices aren’t a panacea. They just let you delay the inevitable but there is gonna be a point where you’re forced to comply with a standard somewhere that changes in a way that services must be updated. A lot of teams use shared libraries for this functionality.

Why do all services need to understand all these objects though? A service should as far as possible care about its own things and treat other services' objects as opaque.

... otherwise you'd have to do something silly like update every service every time that library changed.

Because of organizational standards.

I don't understand your answer I'm afraid

As you mention, it said early on that they were using different versions for each service:

  > Eventually, all of them were using different versions of these shared libraries.

I believe the need to deploy 140+ services came out of wanting to fix this by using the latest version of the deps everywhere, and to then stay on top of it so it does not deteriorate in the same way (and possibly when they had things like a security fix).

Except if it's a security fix?

If a change requires cascading changes in almost every other service then yes, you're running a distributed monolith and have achieved zero separation of services. Doesn't matter if each "service" has a different stack if they are so tightly coupled that a change in one necessitates a change in all. This is literally the entire point of micro-services. To reduce the amount of communication and coordination needed among teams. When your team releases "micro-services" which break everything else, it's a failure and hint of a distributed monolith pretending to be micro-services.

As I said, they mention having a problem where each service depended on different versions of internal shared libraries. That indicates they did not need to update all at once:

  > When pressed for time, engineers would only include the updated versions of these libraries on a single destination’s codebase.
  > Over time, the versions of these shared libraries began to diverge across the different destination codebases.
  > ...
  > Eventually, all of them were using different versions of these shared libraries.

The blog post says that they had a microservice architecture, then introduced some common libraries which broke the assumptions of compatibility across versions, forcing mass updates if a common dependency was updated. This is when they realized that they were no longer running a microservice architecture, and fused everything into a proper monolith. I see no contradiction.

See my response to a sibling comment: they did not have "forced" updates and they really ended up with:

  > Eventually, all of them were using different versions of these shared libraries.

Which is sort of fine, in my book. Update to the latest version of dependencies opportunistically, when you introduce other changes and roll your nodes anyway. Because you have well-defined, robust interfaces between the microservices, such they don't break when a dependency far down the stack changes, right?

> There is no one size fits all.

Totally agree. For what it's worth, based on the limited information in the article, I actually do think it was the right decision to pull all of the per-destination services back into one. The shared library problem can go both ways, after all: maybe the solution is to remove the library so your microservices are fully independent, or maybe they really should have never been independent in the first place and the solution is to put them back together.

I don't think either extreme of "every line of code in the company is deployed as one service" or "every function is an independent FaaS" really works in practice, it's all about finding the right balance, which is domain-specific every time.

FWIW, I think it was a great write up. It's clear to me what the rationale was and had good justification. Based on the people responding to all of my comments, it is clear people didn't actually read it and are opining without appropriate context.

Having seen similar patterns play out at other companies, I'm curious about the organizational dynamics involved. Was there a larger dev team at the time you adopted microservices? Was there thinking involved like "we have 10 teams, each of which will have strong, ongoing ownership of ~14 services"?

Because from my perspective that's where microservices can especially break down: attrition or layoffs resulting in service ownership needing to be consolidated between fewer teams, which now spend an unforeseen amount of their time on per-service maintenance overhead. (For example, updating your runtime across all services becomes a massive chore, one that is doable when each team owns a certain number of services, but a morale-killer as soon as some threshold is crossed.)

Bricken isn’t just making this up. He’s one of the leading researchers in model interpretability. See: https://arxiv.org/abs/2411.14257