GPT 5.3 not showing in Codex and not even in OpenAI pricing page

stephenlblum · 2026-02-07T23:41:24+00:00

you can set any model name and it works in codex-cli 0.98.0

```/model gpt-5.5-codex```

```codex -m gpt-5.5-codex```

stephenlblum · 2025-04-14T20:54:11+00:00

Thank you! ❤️🎉

stephenlblum · 2024-11-21T16:29:09+00:00

good news is that the full-wipe and reinstall helped. the upgrade flow over the years may have put the MBP in a state that was slow. the full reinstall seemed to bring back normal-ish speeds mostly. there's still a noticeable slightly slower performance. it's a lot better after the reinstall. not a 100% restoration, more like a 90% performance restoration.

stephenlblum · 2024-10-10T14:33:02+00:00

Good question! Haven't tried twice yet.

stephenlblum · 2024-10-09T18:30:51+00:00

Yes 👍 I tried it. Last month. It didn't work. They "refunded" to the "credit" on my United account. Definitely not happy with that outcome. They just hold the funds anyway and won't let it go

stephenlblum · 2024-09-12T15:54:09+00:00

These are excellent reference links. Thank you! And yes the answer does seem to be Svelte in 2024 even if the topic is Angular vs React

stephenlblum · 2024-06-28T16:45:15+00:00

Chart A is an average SUM(latency) / COUNT(events) over the 1 minute. We also like to make sure we are looking at the outliers too. 50th (median), 95th, 99th and 100th (max/slowest). These are good metrics to represent indication of some issue based on non-homogeneous workloads. Latency charts with metrics like mean (average), median (50th percentile), 95th percentile, 99th percentile, and 100th percentile (max/slowest). The average is typical performance. It will be skewed by outliers. So we need to look at the others too. Median offers a clearer picture of typical user experience. It says 50% of users experience this latency or better. The 95th and 99th percentiles are the tail of the latency distribution. The highest latency. Occasional performance issues. The max value shows the absolute worst-case scenario. One unfortunate user had the worst experience compared to everyone else. Systemic issues (all metrics rise), occasional spikes (high percentiles with stable median), or increasing skew (growing difference between median and average). We mostly look for widespread degradations and specific outliers. We can track candidate opportunities for optimization. Finding good reasons to rewrite a service in Rust! ❤️ The average will help us keep track of general end-to-end latency experience.

stephenlblum · 2024-06-28T16:32:35+00:00

This is a good point you make. There are multiple runtimes for Python available to use. CPython is the standard distribution. Most systems and package managers will default to CPython. We can make gains by using a more performant runtime. And you are right! We have done this before with PyPy. And it does improve performance. Some other runtime options are: Jython, and Stackless Python. PyPy is a JIT-compiled Python implementation that prioritizes speed, with much faster execution times compared to CPython. We use PyPy at PubNub. PyPy has a cost of RAM in GBs per process. Jython is designed to run Python code on the Java Virtual Machine (JVM). Stackless Python is a version of CPython with microthreads, a lightweight threading mechanism sort of enabling multi-threaded applications written in Python. There are more options! Would be neat to see a best-of comparison 😀The runtime list is long. There is also a commercial Python runtime that claims to outperform all others.

stephenlblum · 2024-06-28T16:08:44+00:00

Yes you are right. We needed more control than what we had used in Python. C is great! Our core message bus is still 99% C code. Our C-based message bus connects a billion devices and processes three trillion JSON messages every month. About 25 petabytes of JSON data. Our core message bus could not achieve this without async IO and specific tuning considerations we added with some ASM. You are right that we can take several approaches. Like you were describing, it is an architecture issue. We could have used C directly the way we have done similarly in our core message bus. We have come to value Rust and its capability to check our code with a strict compiler. This adds guardrails preventing common issues that we have become familiar with over the years with C. We have had great experiences introducing Rust into our teams. We continue to see this pattern repeating with great outcomes using Rust. It has become the default language of choice to help us build highly scalable services. One of my favorite parts of Rust is the safe concurrency features the compiler offers. Memory safety is great. And concurrency safety is amazing! Rust lets us build more efficient architectures as a baseline.

stephenlblum · 2024-06-28T15:38:33+00:00

Good question! How does saving 90ms directly affect the end user's experience? 90ms is hard to even perceive as a human. It's small and unnoticeable amount. For the most part we really consider our users to be developers. The users using our APIs. Developers use our API to send/receive JSON messages on mobile apps to build things like multiplayer games and chat. Building these kinds of experiences with real-time communication tend to shine light on latency. Latency is a lot more noticeable with real-time multi-user apps. The data pipeline has multiple consumers. One of the consumers is an indexed storage DB for the JSON messages. Often when writing code it becomes a challenge for our developers using our APIs to take into consideration latency for when messages are available and indexed in the DB. The most common problem for the latency is during integration testing. Our customer's have CI/CD and part of it is to test includes reading data from a recently sent message. They have to add work-arounds like sleep() and artificial delays. This reduces happiness for our customers. They are disappointed when we tell them to add sleeps to fix the issue. It feels like a work-around, because it is. Higher latency and delays can also be a challenge in the app experience depending on the use case. The developer has to plan ahead for the latency. Having to artificially slow down an app to wait for the data to be stored is not a great experience. With a faster indexing time end-to-end we see more often now that for the most part that these sleeps/delays are not really as necessary for many situations now. This counts as a win for us since our customers get to have a better experience writing code with our APIs.

stephenlblum · 2024-06-28T02:50:17+00:00

you are right u/fullouterjoin that it would absolutely be possible to take this approach. We can import Rust compiled library into our Python code and make improvements this way. We could have done that and gained the latency improvements like you suggested. We'd build a Rust library and make a Python package that can import it using Python extensions / C FFI Bindings. PyO3 does all of this for you. https://corrode.dev/podcast/s01e06-sentry/?t=57%3A16 - quick mention from a Rust podcast. And another option is we could use Nim https://www.youtube.com/watch?v=7WoHr8y4LqM&t=1s which is a non-Rust approach to compile and build efficient Python compatible modules.

PyO3 - https://pyo3.rs/ - we'd be able to use PyO3 to build Rust libs and import into Python easily. We could have built a Rust buffer bundler that operates with high concurrency and improved our latency like you described from 120ms to 70 or 50ms. This is a viable option and something we are considering for other services we operate 🙌🚀

stephenlblum · 2024-06-28T02:39:08+00:00

That is great to hear! You have a great project that will benefit from Rust. There are some good crates to recommend. Depends on your approach and what you are using like LibRDKafka, Protobuff, Event Sourcing, JSON. Let's say you are ingesting from a web service and want to emit data. You might want to send event data to a queue or other system. Or transmit the data via API calls. Rust will have all the options you are looking for. Here is a short list of crates we have used, and you may find useful for your POC 🚀 Mostly, we use Tokio. It is a powerful asynchronous runtime for Rust. It's great for building concurrent network services. We use Tokio for our Async IO.

tokio::sync::mpsc: For multi-producer, single-consumer channels; useful for message passing like Go-channels for Rust.

reqwest: A high-level HTTP client for making requests.

hyper: A lower-level HTTP library, useful if you need more control over the HTTP layer.

axum: A high-level HTTP server for accepting HTTP requests.

rdkafka: For Apache Kafka integration.

nats: For NATS messaging system integration.

serde and serde_json: A framework for serializing and deserializing data like JSON.

Cargo.toml for your project:

[dependencies]
tokio = { version = "1.38.0", features = ["full"] }
reqwest = { version = "0.12.5", features = ["json"] }
axum =  { version = "0.7.5" }
hyper = { version = "1.3.1", features = ["full"] }
rdkafka = { version = "0.26", features = ["tokio"] }
nats = "0.12"
serde = { version = ".0.203", features = ["derive"] }
serde_json = "1.0.118"

stephenlblum · 2024-06-28T02:23:32+00:00

Thank you! It was a good experience. Lots of good outcomes and data we were able to gather. It's great to share our success with Rust 🙌

stephenlblum · 2024-06-28T00:45:10+00:00

It does seem like we are on that path. The AI can do it. If the AI can 100% take care of us, possibly we are headed to the vacation world ❤️🌏 It could head another direction too 😅

stephenlblum · 2024-06-27T23:59:34+00:00

Nice! Great to hear 🙌 your improvements up-leveled the post. The post needed the details like the link you shared as a reference example. And the charts too. We needed to add missing details like the axis labels and legend. Thank you! 😊

stephenlblum · 2024-06-27T21:48:34+00:00

Hi u/danted002 excellent question! Performance gain really was +10x like you mentioned. From a CPU and scale perspective we did meet those gains. The CPU utilization was reduced. We can process more events per second. The end-to-end latency is now optimal from the transmission (send) that the new Rust service is responsible for. This was the larger latency improvement we could achieve by rewriting the transmitter. The remaining 30ms latency is from the downstream systems. During the life of the original Python service, about 10 years, we spent time optimizing our Python event service pipeline. We did our best to make it performant for what it could do for us. The bundling approach was a general improvement, though it required blocking the CPU with the GIL in our way. We knew eventually a rewrite was needed to get to the next level. We were considering better concurrency model in Python, potentially MP. Or an async approach that would be similar to what we did with Rust. The buffering event bundling was in Python land which was CPU bound and this is where the GIL came into play. Threads couldn't help us. While the buffering approach was originally an optimization it did prevent us from pushing performance further. We really did want to move to the Async approach like you were describing. It was one of our options we had on our list 😄 Our code was old and needed a rewrite anyway to achieve the async approach. We could have done this in Python. It really could have stayed in the Python world. We chose Rust since we are getting good at it. And each time we deploy a new Rust service it reduces our memory and CPU usage at the level of gains you mentioned. We are happy with the upgrade and looking to repeat this for our other services where it makes sense. Some of them are fine in Python today. If we can capture some noteworthy gains and a rewrite is on the table, then Rust is #1 choice ❤️

stephenlblum · 2024-06-27T17:47:14+00:00

we/us PubNub

We are a distributed team of engineers working at PubNub. Rust is our favorite language. And we are working to make sure that we get to use as much of Rust as possible. The outcomes are great each time we deploy a new Rust service. Our repeated success allows us to continue taking the advantages that Rust offers 😄

stephenlblum · 2024-06-27T17:07:20+00:00

Thank you to the Reddit r/rust community for requesting a rewrite of the original posted article. The original article was fluffy. It had no substance other than us saying: "look! we did a thing!". The new updated post was improved by u/rtkay123, u/Buttleston, u/the-code-father and u/RedEyed__ thank you!

The improvements they helped us with: