It is 7:00 a.m. on September 4, 2026.
I recently caught COVID-19 and spent a week recovering. It has also been a long time since I last wrote a journal entry. The previous one was written at the end of June—two months ago.
I’ve done quite a lot during this period.
OpenAI LB Relay
OpenAI-LB is a load balancer for OpenAI that I developed myself. In practice, though, it has become our team’s OpenAI proxy server and infrastructure. We previously used the New API product, but New API’s support for OpenAI OAuth was not very good, so we often had to manually disable and re-enable accounts whose quotas had been exhausted.
After thinking it over, I realized this was because open-source relay software cannot openly support OpenAI OAuth. So why not simply keep it closed source? We only needed a Load Balancer for using OpenAI OAuth, after all. I thought about it for a while, realized it would not be particularly difficult, and built one from scratch with CodeX. It is written in Rust, and its performance is excellent.
This project essentially confirmed my previous judgment: when a relay project supports many different AI upstream providers, its support for the features of any particular upstream tends to become weaker. Compatibility inevitably requires a generic interface, which means we can only build a fairly mediocre piece of software. It is extremely difficult to do both compatibility and provider-specific implementations well. You have to consider not only the design of the abstraction layer, but also the differences between the features of different upstream providers. Ultimately, the trade-off between compatibility and specialization often prevents us from taking either aspect to the extreme.
Here is another example: we even support an OpenAI-specific “manual quota reset” feature. OpenAI occasionally gives users an opportunity to reset their quota, and other upstream providers do not offer anything similar. So we implemented an OpenAI-specific feature to support it. If I were building a relay service compatible with every upstream provider, it is hard to imagine that I would spend time implementing such a specialized feature—the design would inevitably look rather “dirty.” But if you only plan to support OpenAI as your upstream provider, the feature becomes perfectly reasonable. Without an abstraction layer, everything becomes much simpler.
I thought: if we only use OpenAI as our upstream provider, why bother with compatibility at all? My judgment is that OpenAI will remain one of the best upstream providers for a long time. Although it is not a stable provider in China, OpenAI will continue to lead the industry for quite some time.
Don’t build software you don’t need yourself. Again.
Thanks to this, our team now has more than enough OpenAI Tokens. We can even rent them out to others.
Auth Mini & Linkit
Auth Mini is still a project that should not be bypassed. It is a very basic identity authentication service, and it has now become the infrastructure behind various products within our team. Our user system is built on Auth Mini. It supports Email OTP, passkey authentication, and remote authorization code authentication (QR code login).
The publicly available products built on top of Auth Mini include:
- OpenAI-LB
- 1Exchange, a fund investment app.
- Linkit, an instant messaging app.
- Cybion, an Agent Harness.
Basically, whenever I dislike how a piece of software works, I just rebuild it myself. As long as a product is accessible over the public internet, the first step is to put it behind an Auth Mini identity authentication service. If it has multiple users, Auth Mini is even more necessary. If it has any social features, you can directly integrate Linkit.
Auth Mini is a pure authentication service. Linkit, on the other hand, builds on Auth Mini to provide User Profile management. After integrating Linkit, users have usernames and avatars, making the overall experience more usable.
Linkit also includes an instant messaging service. At first, I actually wanted it to replace Feishu or WeChat for sending messages, because these existing IM applications are not very friendly to Agent integration. Applications such as Discord and Telegram also have a relatively high barrier to entry for users, and they present certain barriers to Agent integration as well.
So I thought: why not just build an IM application ourselves? It only needs to send notifications, after all; it does not need complicated IM features. And that is how Linkit came about.
Quantitative Strategies
The quantitative strategy for domestic stock index futures has been running in a simulated account for quite a long time, but it still has not been deployed to live trading. Since I do not have much capital, the notional value of a single stock index futures contract is more than one million yuan. I was somewhat concerned that there might be problems with the live CTP interface, so I kept running the strategy in a simulated account.
Later, I worked on a BTC strategy. CodeX’s target mode quickly optimized several usable strategies for me. I published them directly on the 1Exchange funds platform, so everyone could invest in them directly.
The fund descriptions are available on the platform. These two strategies were essentially created by me describing an idea and then having GPT-5.6-SOL iterate on it directly. They work extremely well, and the results have been phenomenal.
These days, even quantitative strategies can be mass-produced. It is truly frightening.
Still, I need to find a way to deploy the domestic stock index futures strategy to live trading.
I still have some psychological resistance, even though I am just one final step away.
