ChatGPT 4o
#
If the behavior is chronic and unproductive, decide how much engagement is worthwhile.
Sometimes planting a seed is better than trying to change their mind in the moment.
Some people are resistant to new perspectives. If they refuse to engage, focus on managing your own reaction rather than changing theirs.
Choose your battles: Not every conversation is worth having. Consider whether it’s worth investing time and energy into trying to change someone’s mind.
ChatGPT OSS 20B
#
Change is a marathon, not a sprint; pace yourself and your words.
Every conversation is a decision.
Here is the list of python tools and libraries I use regularly.
(Sorted alphabetically)
Reference
#
In this article I list all the AI tools I’ve used.
I also try to keep this list up to date with regards to whether I’m still using the tool or not.
Legend:
- 🟢 Regularly using
- 🟡 Sometimes using
- 🔴 Not using
Text generation
#
Code generation
#
Image generation
#
Audio generation
#
Task orchestration
#
Speech to text
#
Desktop client
#
Web client
#
Models
#
gantt
title Model usage
dateFormat YYYY-MM-DD
axisFormat %b %Y
section Composer
Composer 1 :done, 2026-01-01, 2026-03-13
Composer 1.5 :done, 2026-02-09, 2026-03-19
Composer 2 Fast :done, 2026-03-20, 2026-04-30
Composer 2.5 :done, 2026-05-19, 2026-08-28
section Claude Opus
Claude Opus 4.6 :done, 2026-03-05, 2026-04-11
Claude Opus 4.7 :done, 2026-04-16, 2026-05-29
Claude Opus 4.8 :done, 2026-05-28, 2026-07-29
Claude Opus 5 :done, 2026-07-27, 2026-08-06
section DeepSeek
DeepSeek v4 Flash :done, 2026-06-04, 2026-08-12
DeepSeek v4.1 Flash :active, 2026-09-10, 2026-09-23
section GLM
GLM 4.7 :done, 2026-02-08, 2026-04-20
GLM 5 :done, 2026-02-14, 2026-04-14
GLM 5.1 :done, 2026-04-15, 2026-06-13
GLM 5.2 :done, 2026-06-14, 2026-08-17
GLM 5.3 :done, 2026-08-14, 2026-08-28
GLM 5.3 Flash :active, 2026-08-26, 2026-09-23
- 🔴 Composer-1
- 🔴 Composer-1.5
- 🔴 Composer-2
- 🔴 Composer-2.5
- 🔴 Claude Fable 5
- 🔴 Claude Opus 4.1
- 🔴 Claude Opus 4.5
- 🔴 Claude Opus 4.6
- 🔴 Claude Opus 4.7
- 🔴 Claude Opus 4.8
- 🔴 Claude Opus 5
- 🔴 Claude Sonnet 4.5
- 🔴 Claude Sonnet 5
- 🔴 DeepSeek r1
- 🔴 DeepSeek v4 Flash
- 🟢 DeepSeek v4.1 Flash
- 🔴 Gemini 2.5 Pro
- 🔴 Gemini 3 Pro
- 🔴 GLM 4.6
- 🔴 GLM 4.7
- 🔴 GLM 5
- 🔴 GLM 5.1
- 🔴 GLM 5.2
- 🔴 GLM 5.3
- 🟢 GLM 5.3 Flash
- 🔴 GPT 3.5
- 🔴 GPT 4
- 🔴 GPT 4.1
- 🔴 GPT 4o
- 🔴 GPT 5
- 🔴 GPT 5.1
- 🔴 GPT 5.2
- 🔴 GPT 5.2
- 🔴 GPT 5.3
- 🔴 GPT 5.4
- 🔴 GPT 5.6 Sol
- 🔴 GPT OSS 120B
- 🔴 GPT OSS 20B
In this article we’ll cover adding rate limiting to an Apache Flink pipeline. While Apache Flink already contains some APIs that implement some form of rate limiting indirectly, such as AsyncDataStream through a capacity limit which limits the number of concurrent executions, these do not rate limit directly.
Rate limiting is critical in applications where calling 3rd party APIs with rate limits or quotas could result in multiple unnecessary retries or even failures to process an event successfully.
- Implementation of rate limiting
- This consist mostly in including a call to a blocking implementation of a rate limiter just before you would execute the code you want rate limited. For example if you are rate limiting calls to an API, you would block just before sending your HTTP request.
- Rate limiting in relation to parallelism
- When defining rate limiting we generally think of the overall rate limit per second. With Apache Flink parallelism, this number ends up being used by each instance, which makes the rate limit useless in this situation, unless it is divided by the number of parallel instances running the code that is rate limited.
- One way to implement this local rate limit is given in the
open function in 
Flink GuavaFlinkConnectorRateLimiter by dividing the global rate limit by runtimeContext.getTaskInfo().getNumberOfParallelSubtasks()
- In a scenario where we could increase the parallelism indefinitely, what will determine if we autoscale will be how busy the vertex containing our rate limiting operation is. If we have a rate limit of 100/s, it will be 100% busy as soon as we’re processing that many and are rate limited.
- In most situations however we will want to cap our total rate so we will need to configure a maximum parallelism.
- I’ve always thought that we should be making use of the full rate limit we’re allowed, such that even with a parallelism of 1, if our rate limit is 1000/s, that is our rate limit. If the vertex containing the rate limited operation scales to 2, the rate limit of each operator would now be 500.
- Earlier we mentioned that busyness was used to determine when to scale. In this scenario, it seems we would only scale once we reached 1000/s. But then scaling would not help us, as we would simply be 100% busy but on more instances.
- This approach only makes sense if scaling happens for a different reason than rate limiting, such as getting capacity limited or because we cannot reach the rate limit on a single instance. Another reason could be that the rest of the operations in the vertex make it highly busy.
- The downside of specifying a rate limit that is smaller than the total rate limit you have is that you will need to scale possibly unnecessarily because the instance could have handled all the rate limited operations of the global limit.
- What options do we have?
- Keep the rate limited in the same vertex and divide the global rate limit by the number of parallel subtasks
- This allows us to benefit from lower overhead communication between operators
- Isolate the rate limited operation in its own chain
- This allows the operation to scale independently of what happens before and after.
- The downside is increased overhead to transfer the data between the chains before and after.
- Partially isolate the operation in a new chain (either with the operators before or after)
- It’s a trade-off of the benefits of full isolation with no isolation, namely that overhead is partially reduced, but you may affect the parallelism of other operations within the same vertex.
Tools I use on a regular basis at work (sorted alphabetically).
Gradually, then Suddenly: Upon the Threshold
I’ve recently started playing with Claude 3.5 artifacts for fun to prototype an idea I had and while I struggled to get it to do something “fairly” simple, I was impressed with the ease of prototyping compared to if I had to do it myself. I expect this to continue to improve, reducing the amount of time spent on setting up your development environment and getting more immediate results.
[…] I suggest that people and organizations keep an “impossibility list” - things that their experiments have shown that AI can definitely not do today but which it can almost do.
Innovation through prompting
Pretty exciting ideas on how to use LLMs to enable more dynamic teaching, even though it might not be perfect.
Algorithmic progress in language models
[LLM] Models require 2× less compute roughly every eight months
This would be 3 times faster than Moore’s law (every 24 months). Similar to Moore’s law, the big question is when we’ll reach a plateau on those performance improvements.
How to Make Yourself Into a Learning Machine
A lot of things I’ve found myself doing over the years, mostly reading many books each year, keeping quotes (highlights) and notes from what I’m reading, using Anki to learn and remember languages and concepts/ideas, the use of Zettelkasten (but really, just the habit of writing down any thoughts into a digital note), etc. Definitely a recommended read it you’re into personal information management.
Writing one sentence per line
A good way to make your writing clear and to the point. I also suggest to use easy words instead of fancy ones that people don’t often use.