Yes there's no Opus at all on Pro. GPT 5.5 is also missing. Then again what would you expect, the economic reality is beginning to hit. Also I can't be too mad when the "base" models (GPT 5.4...) are still available and decent.
When I see how fast Codex max thinking GPT 5.5 eats our enterprise seat credits almost anything else seems cheap (until we switch our live systems from 5.4 api to 5.5 api I guess)... good thing I'm not the one paying for those credits and tokens (which is probably how most of the money is going to be made on AI going forward, borderline free chatbots for normies are done)
I just want the simple feature of PRs updating when the target branch changes. For example, say I have two tickets: T-100 and T-101. Both are targeting main, but T-101 builds on top of T-100. I put up a PR for the T-100 branch against main, and put up a PR for the T-101 branch against main.
The T-101 PR can't really be reviewed yet, since you are looking at changes from both T-100 and T-101 (because T-101 was based on T-100).
Ideally, after T-100 is reviewed and merged, the T-101 PR would automatically update to show only the T-101 changes. But it doesn't. You have to manually rebase or merge main and push changes to the branch to get it to update. It would be great if GitHub handled this automatically.
No I haven't seen that before. I used to just run the terminfo tic command that's recommended in the top searches and when that started failing I just swapped back to default terminal for SSH
Tilt is great but it doesn’t solve the problem you’re asking about. This project more directly addresses that. Fundamentally the problem is that you want to maintain the lifecycle of several services during an ephemeral ci run and tear them down when you are done. As you mentioned it gets unwieldy and annoying to try to run all of these on a single machine and doubly so when you have a lot of services/containers. Kubedock is more like what you are looking for, it translates compose calls to Kube equivalents and each service in the compose file is it’s one kube pod with its own lifecycle. It should be possible under that to do what you are saying, spawn multiple docker composes from a single run.
It is worth noting that Kubedock has some really annoying limitations, part of it is that it’s one person the other part is that some concepts don’t translate to kube very well. So make sure that whatever you will be doing fits into those constraints before you try it
With a single Tilt file combined with a docker compose file, almost all of the infrastructure you need is configured on a local machine. It also supports running kubernetes (most of the docs are around this), but you do not necessarily need to it it.My goto when I have more then 2 docker containers/services I want to keep changing code for. Some teams I work with usually have 20 such containers for local dev.
And yes, you can even nest Tilt files and even write normal python if you want to mix things up.
reply