I opened an issue some time ago about them monkey patching urllib3, it was fixed than but I now see the issue has been outright deleted. Oh and now I see there is a URLLIB3_NO_OVERRIDE thing... I would not recommend this project.

I personally use fzf and I'm pretty happy with it, this seems to do a lot more but it's not clear what exactly ?

Debugging in python is already so easy with `print(f"{myvar=}")` and `breakpoint()`...

This is the correct answer. `ic(foo(123))` can be written as `print(f'{foo(123)=}')` without depending on yet another third-party library which is not pulling its weight.

The benchmarks aren't great, they're super specific to sem's output: why would I ask Claude how many "entities" were modified by a commit and do I need a tool specifically for this request ? Note that an "entity" is a sem-specific concept...

Thanks for pointing it out. I agree with you here, my testing process was quite specific to sem's output but also would love any suggestion from you of how you would design the whole testing process for this kind of tool?

I can also give my thought process, because I was more interested in figuring out the model's inherent search results and understanding without sem.

Use podman then, or rootless docker if you can make it work

You didn't quote the interesting part:

> our implementation is it only prunes calls from > 3 user messages ago, if context is > 40K, and only if there's at least 20K tokens to be removed

Seems reasonable to me and explains why I can have long sessions (way longer than with zed agents) while still hitting cache. Opencode is just missing per-provider TTL.

I found that keeping current context utilization at 18% of total context length was best for minimizing spend, across all models with 400k context length or more

And your containers need to have specific capabilities enabled, which aren't by default on kubernetes and podman.

Directly emitting metrics using OTLP instead of having the OTel receiver scrape the metrics endpoint is interesting. I never made that move because the Prometheus metrics endpoint works and is so simple, and it's what most projects (eg kubernetes) use.

A long time ago, I introduced dogstatsd at Airbnb. We had already been using vanilla statsd (with no tag support -- cardinality lived in the metric name!) and this was a low cost migration. More than a decade later, I'm assuming it was difficult to track down and refactor all the places that statsd calls were emitted and using OTLP was an easier route. This is a great example of how technical decisions compound over time.

Tubleweed has snapshots and rollbacks too by default. But yeah immutable distros are good for beginners so they don't destroy their system!

I was the sole DevOps at my company for a long time, the team is now bigger. I used terraform for AWS and pulumi for K8S (terraform was too restrictive).

IMO pulumi is a huge gain of productivity when you know what you're doing. Cons: * It's plagued by bugs and the pulumi-kubernetes provider is not getting enough attention from the pulumi team (they're always working on compatibility with yet another language instead of focusing on one thing) * You end up with your very specific/personal codebase instead of having a generic/standard thing

Still, no regrets, I saved so much time thanks to pulumi!

With a bigger team: * Oboarding people takes more time * You end up with code quality issues. Most "DevOps" people aren't devs, sadly.