AI Engineering on Mitja Martini

Export ChatGPT Conversations as Markdown

Fri, 23 Jan 2026 00:00:00 +0000

Today I learned about Rashid’s solution to export ChatGPT conversations to Markdown or even PDF if you like. I prefer Markdown as I can use it to continue the conversation with Claude for example, or change the content and use it in other contexts.

You don’t need to install anything because it’s just a JavaScript snippet. You open the conversation in a browser, select anything in the conversation, inspect it with developer tools and use the console to paste and run the JavaScript snippet and then the Markdown gets downloaded. It’s really simple and extremely helpful in my view.

Here’s the link: Export Your ChatGPT Conversations to Markdown & PDF

From 8 Lines with Dokku to 200 with Kubernetes – Why I'm Still Switching

Tue, 13 Jan 2026 18:21:46 +0200

So far, my web apps run on a Dokku server. I haven’t tried Vercel or Fly because I didn’t want to deal with complex pricing models that incur more costs with every additional project.

Dokku works like Heroku:

dokku apps:create myapp
dokku postgres:create myapp-db
dokku postgres:link myapp-db myapp
dokku config:set myapp APP_SECRET="$(openssl rand -base64 48)"
dokku git:from-image myapp myregistry.example.com/image:tag
dokku domains:set myapp myapp.mitjas.com
dokku ports:set myapp http:80:8000 https:443:8000
dokku letsencrypt:enable myapp

It doesn’t get any simpler. After just 8 lines I have

an app on the server,
a PostgreSQL DB with a user and password,
the app linked to Postgres,
a secret configured,
the app deployed from a Docker image,
a reverse proxy configured to forward HTTP and HTTPS to the app’s container, and
TLS with certificates signed by Let’s Encrypt (including automatic renewal).

With Kubernetes I need almost 200 lines of YAML for this. Why do I still want to switch to Kubernetes?

Dokku is great for small projects that can make do with the Dokku plugins and run on a single server. But I believe Kubernetes is a better fit for me in the long run.

Kubernetes manifests tell me (and LLMs) what’s running on the cluster, and I can continuously develop and improve them. Dokku, in contrast, feels like “fire, forget, and start from scratch.” Other advantages of Kubernetes like better scalability, more choice, and security are nice, too, but for me the most important advantage right now is:

Kubernetes is well-suited for Vibe Coding.

That’s my assumption, anyway. Let’s see how it goes.

What Takes Time in Vibe Coding

Tue, 13 Jan 2026 00:00:00 +0000

Vibe scripting, for me, is when I develop small tools for myself with the help of coding agents. It works extremely well, especially for command-line tools.

I recently told a tax advisor about it. He was interested and wanted to see how it works. So I developed a small example on the spot: a VAT calculator. Not the best example, but I couldn’t think of anything better on short notice.

It worked well, and after five minutes the VAT calculator with a Flet/Flutter GUI was up and running.

But I could also see: there’s still room for improvement. For example, the layout wasn’t great and the functionality was too limited.

As i wanted to know how long it would take to turn it into an actually useful app, I later developed it to become a VAT calculator for all EU countries, which uses a small AI pipeline to load rates and descriptions of which product categories are subject to which VAT rate from official EU pages and displays them in an improved GUI.

The EU VAT Calculator after 2h dev time

What started with five minutes for the simple version turned into about two hours. Of course, it’s much better now. But it’s interesting how big the effort difference is between a solution that serves a specific, narrowly defined purpose and a tool with a broader scope. There’s a lot of work involved, and finesse is needed to make a tool that’s truly useful. Personally, I need iterations with a human in the loop for that. Maybe there are developers who can perfectly specify everything upfront, but I usually need to see and use something to evaluate and improve it.

AI accelerates iterations enormously, and you can decide whether to consider it “good enough” sooner or do a few more iterations. I think this is an important reason why I don’t develop faster with AI. I invest the time in more iterations and perhaps less thinking upfront, which then requires more iterations again.

MCP in ChatGPT Developer Mode Beta

Fri, 17 Oct 2025 00:00:00 +0000

OpenAI just releasesd MCP connectors and ChatGPT developer mode beta. In this post, I describe the process of connecting MCP servers to ChatGPT, show how they look and feel right now in a chat session and give an overview of their current limitations.

Activating developer mode
#

MCP connectors can only be created and edited in developer mode which can look a bit scary:

Note: This article is written from the perspective of a Pro account user. OpenAI’s developer mode and MCP connectors in ChatGPT documentation describes that admins can publish MCPs in their organization. I cannot test this but I assume that MCP connectors are then also usable in normal mode.

Developer mode can be activated in Settings > Apps & Connectors > Advanced Settings.

Creating an MCP connection
#

Once the developer mode is active, MCP server connections can be added in Settings > Apps & Connectors:

Connectors take an icon, name, description, the MCP server url, and authentication information. Both SSE and streaming transports are supported and OAuth 2.0 can be used for authentication.

Using an MCP connection
#

MCP connections need to be activated for each chat session:

In my testing, ChatGPT only uses an MCP connection when it has been instructed to do so. Actions need to be confirmed, but decisions can be stored for the duration of a chat:

Note: ChatGPT marks this action as a write action, even though it’s really a read action from a user point of view. I don’t know if it’s a mistake on the side of the DeepWiki MCP, but the interesting part for me is, that Pro accounts seem to support write actions, already, even though this is still documented as a limitation.

MCP connections cannot be added to custom GPTs. Thus, there is no way to preconfigure the custom instructions needed to call an MCP server together with the MCP connection.

Current Limitations
#

Currently, there are still quite a few limitations:

Not available on free accounts.
Pro accounts can only use read/fetch actions (according to the documentation, this might not be true anymore)
local MCPs are not possible.
Agent mode does not support custom connectors.
Deep research mode only supports read/fetch actions.
Only available on the web, not in the mobile app. In the desktop app, connected MCPs are visible but cannot be used (in Pro accounts), as the desktop app does not support developer mode. I assume MCPs might be usable in Business and Enterprise/Edu accounts.

Trying to make sense of it
#

Right now, I think MCP connectors in ChatGPT are not yet ready for day-to-day use - no wonder, it’s a beta, after all. Meanwhile, actions in custom GPTs are still usable, more open and not as scary to use.

OpenAI could have added MCP connectors to custom GPTs and provided an option to pre-confirm actions for certain MCP servers but decided to go a different route with the developer mode.

For me, MCP is a way to customize chatbots and give them “agency”. I find use-case-specific MCP servers better than generic ones which tend to bloat the context and distract the LLM.

I hope, OpenAI will evolve ChatGPT’s MCP connectors without introducing an obligatory validation procedure, but I won’t bet on it, right now.

Claude Code in Devcontainers

Tue, 14 Oct 2025 00:00:00 +0000

Development Containers or just “devcontainers” add a layer of security, simplify developer onboarding enables developing in parallel with isolated environments.

For me, Devcontainers are a great addition to an AI Engineer’s toolbox, even though I don’t use them day-to-day.

I have setup Devcontainers with Claude Code using VS Code and the devcontainers cli, adapted it to a Python FastAPI based project, and documented it in this article.

Evals for Voice Agents (Session Notes)

Mon, 30 Jun 2025 00:00:00 +0000

Notes of a whirlwind intro to evals for voice agents by Kwindla and swyx

Coding Agents as Slot Machines

Sun, 01 Jun 2025 00:00:00 +0000

After reading a nice post via HN about On Stepping Back, I habitually scrolled through the comments and found this nugget by evrimoztamur:

Interacting with LLM coding tools is much like playing a slot machine, it grabs and chokeholds your gambling instincts. You’re rolling dice for the perfect result without much thought.

This probably applies to many systems that use Generative AI, especially systems that work on the cutting edge where randomness is more pronounced.

If you also “Can’t sleep gud anymore” as Mario Zechner beautifully put it, be aware that coding with agents can be addictive.

Pipecat Cloud Latency for EU Users

Sun, 11 May 2025 00:00:00 +0000

Pipecat Cloud is located in the US. Is its latency ok for voice agents for EU Users.

K/V Cache Quantization in Ollama

Sat, 10 May 2025 00:00:00 +0000

A somewhat hidden feature of Ollama is K/V Cache quantization. This is relevant for local AI as it reduces memory consumption, especially for small LLMs with large context windows.

This post describes how to activate K/V Cache in Ollama and gives an overview of its benefits, drawbacks and use cases.

Activating K/V cache quantization in Ollama
#

K/V Cache quantization in Ollama is not on by default, so you need to activate it by setting the OLLAMA_KV_CACHE_TYPE environment variable. Supported values are documented in How can I set the quantization type for the K/V cache?:

f16
q8_0
q4_0

Benefits and Drawbacks
#

K/V Cache quantization can be the difference between being able to run a model on a machine, or not. You can use Sam McLeod’s vram-estimator to estimate the memory consumption of models with different quantization settings.

The benefit in brief is lower memory consumption which is most pronounced when using small models with large context windows.

The main drawback is reduced model accuracy. The lmdeploy team has written a blog post about K/V cache quantization accuracy test results if you want to see quantified impacts of K/V quantization on model accuracy.

Example numbers
#

Llama 3.2 8B supports 128.000 tokens context windows.

When you run it with Q4_K_M quantization and the longest possible context length, it consumes

23.3 GB memory without K/V cache qantization,
17.0 GB with Q8_K_0 K/V cache quantization, and
13.8 GB with Q4_K_0 K/V cache quantization.

With Q4_K_0 K/V cache quantization it now fits into 16 GB vRAM.

Use cases
#

Application	Benefit
code generation	more code in context
question answering	whole docs fit into the context
function calling	more tools
chat	longer conversations
multi-modal	images need many tokens

More Info
#

To learn more, read Sam McLeod’s in-dept blog post about Bringing K/V Context Quantisation to Ollama. Sam helped to implement this in Ollama.

Deploying Voice Agents to Production

Fri, 09 May 2025 00:00:00 +0000

Here are my notes on the session about deploying voice agents to production which is part of the Voice Agents Course.

The course if held by kwindla und swyx, the CTO und an investor of Daily.co, a WebRTC und Voice AI infrastructure provider. Some of their recommendations might be predisposed. I still state them as is as I trust them and because I don’t have enough experience with voice agents in production.

TL;DR
#

Use a voice AI provider for simple, scalable deployment for production.
Use a single VM or your homelab for demos.

Differences between voice agents and traditional web apps
#

are mostly in the transport
persistent connnection (minutes)
bidirectional streaming
stateful sessions

Voice agents in production need
#

A http service for
- API endpoints,
- a website, and
- webhooks,
- spawning bots.
A media transport layer or service:
- WebRTC based for client-to-server (udp), or
- websocket based for server-to-server (tcp).
Bots (udp or tcp, connect to media transport layer)

Bots
#

Are instances of the agents.
Can be written in Python with PipeCat.
Use STT, LLM, and TTS providers, which also are the main cost and latency drivers.
Usually come packaged with small models, eg. for voice activity detection (VAD)
Each spawned bot serves one session and needs allocated resources during the whole session:
- 0,5 vCPU
- 1 GB RAM
- 40kbps for WebRTC audio (in 30-60 kbps range)
- video requires more CPU (eg. 1 vCPU), and bandwidth
Need to be quickly available. Target time-to-first-word:
- 2-3 secs (web),
- 3-5 secs (phone)

Ways to solve the “fast start challenge”
#

percentage-based warm pool
fast startup times (caching, pre-loading)
proactive/predictive scheduling
fallbacks from reactive world (eg. UX based solutions, not just silent fails)

Infra providers
#

need to support tcp and udp
voice ai providers are easiest (Pipecat Cloud, Daily, Vapi, Layercode)
Fly.io (and potentially other container platforms) are good if they support udp (Fly does)
ML focused provides are good for converged bots with larger models included (gpu clouds)
hyperscalers are flexible but complex
BTW: CloudRun does not support udp
demos can run on single VMs or even be served from a home lab
by serving everything converged, time-to-first word can get down to 500ms
otherwise 800-1000 ms is good enough and achievable
proximity to users matters (Daily plans global regions for PipeCat cloud, currently only us-west)
conn between servers can be implemented with WebSockets

What’s next?
#

After the session I have looked at the PipeCat examples and realized it should be easy enough to run a basic voice agent with PipeCat’s SmallWebRTCTransport on a virtual server hosted in Europe and then switch the transport and deploy it to production on PipeCat Cloud.

I will probably try that to see if the latency between US based PipeCat cloud and users in Europe is low enough for a good user experience.

An Overview of the Voice AI Landscape (Session Notes)

Thu, 08 May 2025 00:00:00 +0000

I’m so happy to be part of the Voice Agents Course by Kwindla and swyx. Yesterday, Kwindla kicked it off with an overview of the voice AI landscape. The pace, insights, and questions from the audience were just great.

Here are my personal notes, probably incomplete and maybe not always correct. For a more authoritative overview of the Voice AI landscape, check out their free online book Voice AI & Voice Agents - An Illustrated Primer.

Voice AI has highly valuable use cases with actual real business value.
Benefits:
- Today: lower cost.
- Soon: Better. (peak load response, better answers than most humans can give)
RAG is still important
Some challenges:
- latency
  - measure regularly end-to-end from/to clients,
  - record conversation with mic,
  - visually look at gaps in waveforms,
  - test calls from different regions and cell phone providers
  - aim for 800ms, tough but possible to hit with hosted inference,
  - very optimized/limited deployments can hit 500ms with quality compromises
  - 1000ms is not uncommon (still makes users happy)
- turn detection
  - from VAD to semantic
  - OpenAI shipped a good text mode TDM
  - Gemini flash in audio is ok, but needs to run as parallel flow (“greedily”)
  - LifeKit vs. PipeCat is text vs. audio / end of speech, no audio cues vs. with audio cues
  - both a hard ML challenge and important for experience
- interruption handling
- context management
- function calling, tool use
- sripting, instruction following
standard architecture
- today: 3 models (STT - LLM - STT), easier to achieve robust results with LLMs in text mode
- future probably converged
- 3 models, because
  - LLMs’ text mode is their mode
  - we ride on the edge what the best models can do
  - today, we need to use their best mode
- other use cases, like language learning, can better leverage the benefits of speech-to-speech (1 model)
models used (speed and quality, time-to-first token/byte more important than tokens/s)
- STT:
  - Deepgram
  - Whisper (optimized for streaming, original not built for streaming), down at 400
  - Gladia (for non-english languages)
- LLM:
  - GPT-4o
    - still the workhorse, still more than 4.1
    - big model changes take work and good evals (nobody has good ones),
    - models usually not optimized for voice AI,
    - not yet better results
    - 4o-mini was cheaper but slower and worse for tool/function
    - note from a fellow student: 4.1-mini might be interesting
  - Gemini 2.0 Flash
    - very good, fast, cost efficient
    - best audio model for voice AI, today (gemini in audio input mode for voice-to-voice)
    - multi-lingual input is ok, output not so much (use English)
  - mid-sized open models get better, esp. fine-tuned Llama4 (upcoming OpenPipe finetuning session)
  - additional notes about LLM use in voice AI:
    - reliable function calling/tool use is mostly a question of how to prompt 4o against Gemini
    - llama can get there
    - evals are important as ever
- TTS:
  - PlayAI, Grok
  - OpenAI, Google
  - Cartesia
  - Rime
  - Elevenlabs
- network transport:
  - why network? We don’t get capable enough models on mobile or laptop (yet),
  - hybrid architectures might be relevant, already
  - telephone is a great transport for voice AI, too
    - PSTN is with a phone number (eg. from Twilio)
    - SIP is for interconnectivity with digital telephony infra
  - WebSockets are not good for real time client-to-server audio (and video), but ok for server-to-server audio
  - WebRTC is best, complex, but PipeCat supports it ootb, local for testing, in the cloud offering for production,
- Voice AI building blocks in 2025
  - evals - huge topic
  - hosting and scaling - very different (if you love k8s, your topic)
  - workflow/multi-agent/state machines
  - “perfect” speech
    - LLMs in text mode have passed the turing test
    - not quite reached the point for real-time audio recognition and generation
    - eg. accurately recording email, postal addess
  - human-like turn detection
    - very important for qualitative experience
    - fun and hard ML problem
- what’s next?
  - speech to speech models
  - realtime video
  - programming with voice
  - voice as universal user experience
  - LLM as a judge
orchestration and flows questions
- voice in text out can be done with PipeCat aggregator (no great example, yet)
- accents and voice models: Gladia input, PlayAI output
- tip for Gemini: if you want accents, specify your country.
- how to solve cold-start?
  - Daily solved it for us
  - own infra: Combine optimized startup and warm capacity
- faster responses:
  - greedily inference/speculative before turn-detection
  - helpful but more costly
- multi-speaker:
  - hard, no great solution, so far.
  - training data doesn’t map well to multi-person/agent conversation
  - challenge: know when models should or shouldn’t respond (emit a no-response-token)
- observability tooling (multiple vendors, eg. Coval, will be in Discord and hold sessions)

Even after the first session, I can already say: If you are interested in Voice AI: Take the course!.

The Fast Solopreneur

Thu, 08 May 2025 00:00:00 +0000

In The Batch 300, Andrew Ng shared some insights about the importance of speed for startups and how to move fast as a startup. I think they apply well to ideas for a fast solopreneur:

Focus on one idea,
Code prototypes intuitively,
Be creative about getting user feedback quickly (it doesn’t have to scale),
Pivot quickly but stay within your domain,
Use a KISS stack you know, and
Learn AI technology well.

Here is a summary of Andrew’s original perspective:

Focus on a concrete idea (don’t get distracted)
Switch quickly to another hypothesis when data shows that the original hypothesis is flawed
Trust a domain expert’s gut instinct
Build and test prototypes quickly with AI-assisted coding
Be fast at getting user feedback (this becomes the bottleneck and the competitive advantage)
Know the technology well (a deep understanding of what AI is good at and what it isn’t saves time and avoids dead ends)

A note on the hidden complexities of WebSockets

Sat, 25 Jan 2025 00:00:00 +0000

AI Apps are often expected to be realtime. On the web, realtime communication can be implemented with WebSockets. I’ve started with WebSockets to create chatbots and other live-updated interfaces, but then switched to SSE and now mostly follow these rules of thumbs:

Use WebSockets for server-to-server communication.
Use SSE for server-to-client communication.
If you still want or need to use WebSockets for server-to-client communication, add a fallback to SSE.
If you need realtime voice/video server-to-client communication, use WebRTC.

If you still want or need to build a websocket service, please read Atul Jalan’s blog post about The Hidden Complexity of Scaling WebSockets. It’s a quick read and captures important lessons to keep in mind when working with WebSockets.

All of his lessons are important, even when working not at scale. Here is a quick summary:

Downtimeless deployments are much more involved than in HTTP services.
Establish a good message schema, eg. 2 byte prefixes and single character field delimiters.
Use heartbeats to detect dead connections - both ways.
Have an http fallback as WebSockets are often blocked. Usually: Server sent events (SSE) for server to client communication and simple requests for client to server.
More, like standard tooling (rate limiting, validation, error handling), no caching at the edge, per-message authentication.

Standard framworks like Django, FastHTML, and Quart (an async Flask clone) have good basic support for WebSockets, but don’t really help dealing with their hidden complexities. I hope, frameworks will level up a bit, as this is mostly “undifferentiated heavy lifting”.

RTX 5090 for Local AI

Tue, 26 Nov 2024 00:00:00 +0000

A look at the NVIDIA RTX 5090 specs for local LLM inference.

AI Engineering on Mitja Martini

Export ChatGPT Conversations as Markdown

From 8 Lines with Dokku to 200 with Kubernetes – Why I'm Still Switching

What Takes Time in Vibe Coding

MCP in ChatGPT Developer Mode Beta

Activating developer mode #

Creating an MCP connection #

Using an MCP connection #

Current Limitations #

Trying to make sense of it #

Claude Code in Devcontainers

Evals for Voice Agents (Session Notes)

Coding Agents as Slot Machines

Pipecat Cloud Latency for EU Users

K/V Cache Quantization in Ollama

Activating K/V cache quantization in Ollama #

Benefits and Drawbacks #

Example numbers #

Use cases #

More Info #