DEV Community: Nicolas Fränkel

AI-assisted genealogy

Nicolas Fränkel — Thu, 03 Sep 2026 09:02:00 +0000

My son recently came to me to brag about using AI to find our ancestors. While the results were correct, I didn't learn anything new, as it stopped at my grandparents. I was never very interested in my genealogy, but I decided to see if AI would be a good tool for this. TL;DR: Yes, it is, and even more than that. In a little less than one month, I managed to gather more than 600 individuals and get back 12 generations in some branches.

In this post, I want to explain how I did it so that you can do the same.

Setup

I decided to handle the project like any other software project:

git.
A git provider. I'm using both Codeberg and GitHub. See below for the rationale.
Cloudflare Pages to visualize the tree.

I searched a bit about how to store data and found the GEDCOM format specification:

The word GEDCOM is an acronym for GEnealogical Data Communication. GEDCOM was created by The Church of Jesus Christ of Latter-day Saints as the specification for exchanging genealogical data between different family tree software products. The original GEDCOM specification was released in 1984, and the last update to it was version 5.5 in 1996 with an incremental upgrade to version 5.5.1 released in 2019.

—- About GEDCOM

The latest 5.x specification version is 5.5.1, re-released as a standard in 2019. FamilySearch rebooted the specification in 2021 to create v7.0, which is still maintained today. Few tools are actually compatible with it. For this reason, I limited myself to using 5.5.1.

GEDCOM 101

GEDCOM is a structured format, based on indentation level. The indentation is not space-based, but relies on a leading number. It looks something like this (spaces added for better readability):

0 @I1@ INDI                                   # 1
  1 NAME John Martin /Doe/                    # 2
  1 SEX M
  1 BIRT
    2 DATE 1 JAN 1970
    2 PLAC Paris, 8e, Paris, France
    2 SOUR @S1@                               # 3
      3 PAGE Birth certificate EA68410

The base entity is the INDI, an individual
Last name is defined between slashes
Source with ID

As I mentioned, I added extra spaces. The following snippet is the correct format:

0 @I1@ INDI
1 NAME John Martin /Doe/
1 SEX M
1 BIRT
2 DATE 1 JAN 1970
2 PLAC Paris, 8e, Paris, France
2 SOUR @S1@
3 PAGE Birth certificate EA68410

The loop

The process is always the same.

Pick someone in the tree with unknown parents, and let the assistant do the search. It knows which genealogy sites to browse, and which archives hold the civil records for the place. When it finds the act, it transcribes it, adds the new individuals to the GEDCOM file, links them to their child, and records the source. Then it commits.

Rinse and repeat. Each loop adds one generation on one branch, until no records are found.

What worked with the assistant

Most AI-related advice also applies to professional projects.

Switch model according to the task: Your token quota is limited by nature, unless you pay per token (but in this case, you're rich and tokens aren't an issue). It's not efficient to use super powerful models such as Fable 5 to send emails. However, it's equally inefficient to use a weak model for complex multi-step tasks: you will probably get wrong results.
Create skills: When you start either repeating the same instructions or notice that the assistant does come to the same conclusion over and over, it's time to create a skill. Skills are reusable sets of instructions, scripts, assets, and references. However, the biggest benefit of skills is that they don't bloat the context by default: they are triggered if their description matches the prompt. Skills can be orthogonal.

I have created several skills:

more than a couple to know how to navigate a site
one to transcribe record images into plain text (see below)
two for autonomous sessions (see below)
- Transcribe records into plain text: All records you will get will either be PDFs or images. PDFs are hard to parse, and images even more so. In the long run, it pays to parse and transcribe them once, so they can be reused cheaply afterwards.
- The assistant can make mistakes: It does the research, so its mistakes are research mistakes. It may misread a name on a scan, or pick the wrong person when two of them share a first name, a surname, and a village. However, my experience is that Claude Code is pretty good on transcriptions, and it's cautious by default.
- Set up grammar checks: The bigger the GEDCOM file, the more chances the assistant will break it at some point. If you notice it after many commits, it will be a mess to straighten it back. Make sure to check the GEDCOM structure at every commit. Either use local pre-commit hooks or a remote job on GitHub/GitLab/whatever.
- Long-running autonomous tasks: After a while, I got frustrated waiting for my quota to reset, and treated myself to Claude Max. I now had a gazillion tokens to use. It was not long before I started to run sessions overnight or while at work. If you are in this case, you need to come up with a strong structure so you don't find out at the end of the whole session that you have drifted.

I found out that my sweet spot was:

A subagent to avoid polluting the main agent's context
Serial subagents, not parallel, since I don't have a deadline, and it avoids facing the quota limit mid-month
The subagent works, commits in a worktree branch, the main agent checks and merges

What I learned about genealogy

Here are the things I learned. For genealogy experts, they may seem obvious. However, if you're a beginner, I hope they might be helpful.

Different countries have different potential: Depending on the country, you may get widely different results with the same process. Results may even differ for places inside the same country.

For this reason, and depending on where your ancestors stem from, the tree will probably be unbalanced. In some cases, it may even be quite limited.

A lot of data is already there: There are plenty of genealogy websites around. All of these I stumbled upon have a free tier. If you can find a common ancestor with someone who already did the work upwards for you, why not use it?
Work of others can be wrong: While you will populate your tree very fast with third-party work, don't take it as proof. You need to verify the facts with a legitimate administrative certificate.

For the record, I stumbled upon a collateral family member who supposedly died in Switzerland. Since he was the only one, I spent a bit of time trying to find his death certificate, to no avail. It turns out that he died in France in a hunting accident, but next to the border. It made the news in a local Swiss newspaper, and the person inferred that he had died there. Trust, but verify.

People are genuinely trying to help: Everyone I have contacted on these sites has answered. Everyone tried to help. In the worst case, I got nothing that I could use. In the best case, actually two, I got connected to historians who wrote books on the subject.
Birth certificates help push boundaries: Birth certificates mention the parents and their own birth date and place. If you can loop over several times, you will get a few generations in no time.

Marriage certificates are the next best thing. You'll find the groom and bride's parents' names, but will probably miss their own birth data.

French marriages usually happened at the bride's parish: I had never heard of this tradition, but Claude Code apparently did. In the past, for marriages happening between people from different towns, the tradition was to hold it at the bride's parish.

Treat it as a heuristic rather than a rule. I had a couple of cases when my ancestors didn't follow the tradition.

French civil acts are public 75 years after the event's date: In France, if you want a civil act, you need to prove you're either the person in the act or a direct ancestor. But that rule is removed if the act dates back 75 years or more. You can actually access the birth certificate of public figures such as Général de Gaulle this way, and search for their ancestors.
In small hamlets, everyone had the same surname: Because some of them also had the same first name, they had to add a discriminant. The discriminant was fortunately sometimes written in civil records. When it wasn't, it got extremely confusing.

Savoy is a good example of such surname things. They added a second surname there. You can read more about it here (in French).

GEDCOM allows defining a place format: I came to know about GEDCOM by working on the project, so the TIL items are a very long list. However, I think this one takes first place.

Different countries have different location structures. GEDCOM has a powerful and flexible scheme for locations, which allows defining the format, then the value.

  2 PLAC Lyon, 7e, Rhône, France
  3 FORM Ville, Arrondissement, Département, Pays

Visualization with Topola on Cloudflare Pages

The more people you add to your tree, the harder it is to visualize the GEDCOM model in your head. I searched for a couple of visualization solutions and found:

Gramps: It's a desktop-based application, available for many different platforms. It works pretty well, but its internal storage is SQLite. Though you can import GEDCOM, you need to clear the existing data first: you can't override them.
Topola Genealogy Viewer: Topola provides an interactive website for you to display a GEDCOM 5.5.1 file. It's the software I chose.

Topola also allows you to display the tree from one single static GEDCOM file. You can use it in a build process, e.g., a GitHub workflow, to generate the visualization website. The tree holds data about people who are still alive. I keep it private for this reason. GitHub Pages are public by default, so I didn't want to go this route.

I checked for options and found Cloudflare Pages. It's the first time I've used it, and it's amazing:

It integrates natively with GitHub
You can configure authentication. The easiest one is OTP on a list of allowed emails you configure.
It creates a subdomain for each branch, so you can preview changes!

The only downside is a limit of 500 builds a month, more than enough for a free offer and a hobby project.

This is also the reason for the two git providers. Codeberg hosts the repository I work on. GitHub only holds a mirror, because Cloudflare Pages builds from it.

Conclusion

I never thought about genealogy before. However, it's a lot of fun, and I'm hooked on it now. In one month, the assistant got me what some people spend years searching for. I hope this post gave you ideas and set you on the path.

To go further:

Originally published at A Java Geek on August 30^th, 2026.

Solving Gradle metadata and Renovate integration

Nicolas Fränkel — Thu, 20 Aug 2026 09:02:00 +0000

My current company has settled on using Gradle. It doesn't make me very happy, but you need to learn to work with constraints. Plus, I must admit that the developers who actually implemented the build files did a pretty good job overall: they used Kotlin instead of Groovy, they moved code to regular plugins, etc.

This week, I worked on improvements to a new project and set up Renovate. Renovate is similar to Dependabot in that it checks for new versions of your dependencies and automatically creates PRs for you. However, I quickly noticed that merges of new dependency versions failed the build. Here's the full story on why, and how I fixed the issue.

Supply chain hardening

In the last few years, one of the big issues in the IT world has been supply chain attacks. Depending on others' work isn't a new thing:

The woolen coat, for example, which covers the day-labourer, as coarse and rough as it may appear, is the produce of the joint labour of a great multitude of workmen.

—- Adam Smith, The Wealth of Nations

The software world has increased the phenomenon a lot due to two factors:

Digitized assets make the reproduction cost-free. You can distribute as many copies as you want.
Open Source has created many projects that serve as foundations for others, from full-fledged operating systems to specialized libraries, e.g., curl. Mandatory illustration:

For hackers, it creates an interesting attack vector:

Working with external dependencies and plugins from third-party repositories exposes your build to significant supply chain risks. Dependencies are the most commonly attacked part of the software supply chain, and every artifact you consume, including transitively pulled-in binaries, needs to be both legitimate and unchanged.

To illustrate the risk, consider building an application that uses the trusty-lib:1.0 library from a public repository. If an attacker successfully replaces trusty-lib in the repository with a malicious version having the same coordinates (trusty-lib:1.0), your next build will download the compromised code without any warning.

—- Verifying Dependencies

This type of attack is known as a supply chain attack. In recent years, there have been more than a couple of such attacks.

Verifying dependencies

The Java platform introduced dependency verification via JAR signing in early versions. It was present at the latest in 1.2. You can check the process documentation if you're interested. In short, a signed JAR has specific files in its META-INF folder.

JAR signing never became popular, and I can only assume the reasons why:

The process was (and still is) complicated
DevOps didn't exist
Certificates were expensive

Over JARs carrying their signature files, people preferred a weaker form of verification: no signature, but a short fingerprint of the file itself. This guarantees integrity. Integrity means you're downloading the exact file that you intend to.

Integrity verification is widespread because it's simple. You first download the file. Then, you run a dedicated application on the file to generate its hash. If the generated hash and the advertised hash match, the file is the original file; if not, it has been tampered with.

Maven Central provides such a hash for each artifact it offers for download. For example, here's the download page for the Log4J2 SLF4J bridge:

log4j-slf4j2-impl-2.26.1-cyclonedx.xml            2026-06-29 07:47     26067      
log4j-slf4j2-impl-2.26.1-cyclonedx.xml.asc        2026-06-29 07:47       856      
log4j-slf4j2-impl-2.26.1-cyclonedx.xml.md5        2026-06-29 07:47        32      
log4j-slf4j2-impl-2.26.1-cyclonedx.xml.sha1       2026-06-29 07:47        40      
log4j-slf4j2-impl-2.26.1-sources.jar              2026-06-29 07:47     23459      
log4j-slf4j2-impl-2.26.1-sources.jar.asc          2026-06-29 07:47       856      
log4j-slf4j2-impl-2.26.1-sources.jar.md5          2026-06-29 07:47        32      
log4j-slf4j2-impl-2.26.1-sources.jar.sha1         2026-06-29 07:47        40      
log4j-slf4j2-impl-2.26.1.jar                      2026-06-29 07:47     30212      
log4j-slf4j2-impl-2.26.1.jar.asc                  2026-06-29 07:47       856      
log4j-slf4j2-impl-2.26.1.jar.md5                  2026-06-29 07:47        32      
log4j-slf4j2-impl-2.26.1.jar.sha1                 2026-06-29 07:47        40      
log4j-slf4j2-impl-2.26.1.module                   2026-06-29 07:47      3524      
log4j-slf4j2-impl-2.26.1.module.asc               2026-06-29 07:47       856      
log4j-slf4j2-impl-2.26.1.module.md5               2026-06-29 07:47        32      
log4j-slf4j2-impl-2.26.1.module.sha1              2026-06-29 07:47        40      
log4j-slf4j2-impl-2.26.1.pom                      2026-06-29 07:47      5141      
log4j-slf4j2-impl-2.26.1.pom.asc                  2026-06-29 07:47       856      
log4j-slf4j2-impl-2.26.1.pom.md5                  2026-06-29 07:47        32      
log4j-slf4j2-impl-2.26.1.pom.sha1                 2026-06-29 07:47        40

Note the three associated files for each published file:

.asc: a GPG signature file
.md5: a MD5 hash
.sha1: a SHA1 hash

While Maven Central provides these files, it is up to consumers to verify the integrity (or authenticity) of the downloaded files.

Gradle verification

Gradle does help with signature or hash verification by automating the process. During the build process, it verifies the integrity or the authenticity of dependencies. To generate the file, run:

./gradlew --write-verification-metadata sha256,pgp

It creates an XML file similar to the following (sample taken from the documentation):

<verification-metadata
  xmlns="https://schema.gradle.org/dependency-verification"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="https://schema.gradle.org/dependency-verification
                      https://schema.gradle.org/dependency-verification/dependency-verification-1.4.xsd">
  <components>
    <!-- BOTH SIGNATURE AND CHECKSUM -->
    <component group="com.google.guava" name="failureaccess" version="1.0.3">
      <artifact name="failureaccess-1.0.3.jar">
        <pgp value="BDB5FA4FE719D787FB3D3197F6D4A1D411E9D1AE"/>
        <sha256 value="cbfc3906b19b8f55dd7cfd6dfe0aa4532e834250d7f080bd8d211a3e246b59cb"
            origin="Verified"
            reason="Added manually to fix CI"/>
      </artifact>
    </component>
    <!-- CHECKSUM ONLY -->
    <component group="antlr" name="antlr" version="2.7.7">
      <artifact name="antlr-2.7.7.jar">
        <sha256 value="88fbda4b912596b9f56e8e12e580cc954bacfb51776ecfddd3e18fc1cf56dc4c"
            origin="Verified"
            reason="Artifact is not signed"/>
      </artifact>
    </component>
    <!-- SIGNATURE ONLY -->
    <component group="com.beust" name="jcommander" version="1.78">
      <artifact name="jcommander-1.78.jar">
        <pgp value="C70B844F002F21F6D2B9C87522E44AC0622B91C3"/>
        <pgp value="DCBA03381EF6C89096ACD985AC5EC74981F9CDA6"/>
      </artifact>
    </component>
  </components>
</verification-metadata>

Gradle compares dependencies' hash or signature against data in the file above.

Note that the process is not foolproof: if the library has already been compromised, the command will write the hash/signature of the compromised library. Gradle's documentation doesn't try to sugarcoat it:

Gradle can automatically generate a dependency verification file by downloading all your dependencies and recording their checksums or signatures. This is called bootstrapping.

However, bootstrapping has a critical security limitation: it trusts whatever is currently in your repositories. If a malicious dependency has already been introduced into your build (or into a repository you use), Gradle will record the compromised artifact's checksum or signature.

This is why you must review the generated verification file. Bootstrapping is convenient for getting started or updating your verification file, but it's not a substitute for manual verification of critical dependencies.

—- Generating and Bootstrapping Verification Metadata

However, once you have bootstrapped the metadata file with safer dependencies, Gradle guarantees the same dependencies will be used in other environments, including CI.

The issue with Renovate and its fix

So far, I have explained how Gradle verifies dependencies and how useful it is. It's time to introduce Renovate and the issue I faced.

Renovate opened a PR.
I merged it.
It broke the build, and I had to manually regenerate the metadata file in a new PR.

I wrongly thought that Gradle only verified artifacts listed in the metadata file, and that a new, unlisted dependency version would pass. In fact, the build breaks in case of new dependency version pairs that aren't listed in the metadata. It makes sense, as otherwise, the metadata file would soon be made irrelevant.

I considered several solutions, including discarding Renovate or Gradle metadata. However, I finally settled on postUpgradeTasks.commands:

A list of commands that are executed after Renovate has updated a dependency but before the commit is made.

—- postUpgradeTasks.commands

We can generate the metadata file again by using this directive.

{
    "$schema": "https://docs.renovatebot.com/renovate-schema.json",                 // 1
    "postUpgradeTasks": {
        "commands": [
            "./gradlew --write-verification-metadata pgp,sha256 --refresh-keys --export-keys dependencies" // 2
        ],
        "fileFilters": [
            "gradle/verification-metadata.xml",                                     // 3
            "gradle/verification-keyring.gpg",                                      // 3
            "gradle/verification-keyring.keys"                                      // 3
        ],
        "installTools": {
            "java": {}                                                              // 4
        }
    }
}

Standard JSON schema
The exact command to run
Renovate is only allowed to update these files
Renovate runs in a dedicated container, without Java. Since Gradle relies on a JDK, you need to install it first.

Now, every Renovate PR for a Gradle dependency will regenerate the metadata file. It's not a perfect solution, though. The warning about the initial bootstrap still stands: if the downloaded dependency is compromised, the metadata is generated with the wrong hash and signature. I think that's the price to pay.

Conclusion

I started using Renovate on projects I didn't initiate. It allows me to learn about its issues and how to fix them. Renovate's configuration options page has become my new friend.

To go further:

Originally published at A Java Geek on August 16^th, 2026.

GitHub agentic workflows and Renovate

Nicolas Fränkel — Thu, 06 Aug 2026 09:02:00 +0000

I've been a big fan of Renovate for a couple of years already. Renovate scans your repositories, detects outdated package versions, and opens pull requests to automatically bump them. It's similar to Dependabot in that it keeps your dependencies up to date. If I had to compare them in one sentence, I'd say Renovate is less integrated in the GitHub ecosystem, but handles more ecosystems and, more importantly, is extensible. My current company is a happy Renovate user, and I already started to use it in some repositories.

I have previously written about Agentic Workflows. As a reminder, you first create the workflow in Markdown with a very loose syntax. Then, you "compile" it to generate a GitHub Workflow-compliant YAML file, suffixed with .lock.yml.

In this post, I want to describe the problem when combining the two, how I tried to fix it, and the correct solution.

The core problem

Renovate is very eager to please. By default, it scans all ecosystems used for dependencies: build.gradle.kts, pom.xml, pyproject.toml, Dockerfile, GitHub workflows, etc. Most "manual" GitHub workflows use GitHub actions, which are versioned dependencies.

The generated lock of agentic workflows does make use of GitHub actions, in particular gh-aw-actions/setup.

When Renovate worked on my repository, it did what it always does. It searched for candidate files, found my documentation-review workflow’s lock file, scanned the dependencies, and opened a PR bumping the SHA to the latest, including gh-aw-actions/setup. So far, so good.

However, it created an interesting problem. The action SHA pointed to a new version of gh-aw-actions. The script body inside the same file didn't change, but referenced a helper script that the new version didn't provide. The workflow failed.

The wrong fix

I have to admit I didn't understand the above synchronization issue at first.

To fix it, I created a new non-agentic GitHub workflow. Whenever Renovate upgrades lock.yml, the workflow automatically recompiles the agentic workflow. This introduced a subtler bug. The trigger fired on any change to docs-review.lock.yml, not just gh-aw-actions version bumps.

In my case, Renovate later opened a separate PR to pin the Node.js version inside the same file: the recompile workflow triggered, ran gh aw compile, and overwrote the file, rolling back the node-version change Renovate had just made.

The actual solution

After the second rollback, I realized something was fishy and understood the root cause. The compiler generates the whole lock file from a single gh-aw release. The action pin and the inline scripts inside the file must match. Renovate bumped the former and left the latter untouched.

The solution was much simpler. It consisted of two parts.

Exclude the lock file from Renovate

Renovate has an ignorePaths entry. I added the lock file and agentics-maintenance.yml, another workflow that the compilation generates:

"ignorePaths": [
  ".github/workflows/docs-review.lock.yml",
  ".github/workflows/agentics-maintenance.yml"
]

Update the actual source, then recompile everything

The real source of version pins is .github/aw/actions-lock.json, a manifest file that gh aw compile reads to resolve action SHAs. Renovate can't update this file yet. There's an open feature request to support it. In the meantime, gh aw update-actions refreshes the manifest. I kept my recompile workflow but narrowed its trigger to this single file. When the manifest changes, the workflow fires and runs bare gh aw compile, regenerating all compiled artifacts at once.

on:
  pull_request:
    branches: [master]
    paths:
      - .github/aw/actions-lock.json

GH_TOKEN=${{ secrets.GITHUB_TOKEN }} gh aw compile

The gh-aw documentation warns against editing generated references by hand: you should run gh aw compile to regenerate them. It boils down to the same split: the manifest owns the pins, the compiler owns the generated outputs.

Conclusion

Generated files are not dependency files, even when they contain version strings. We all know we shouldn't change generated files. New tools shouldn't change this approach.

In our case, Renovate should only know about the source, not the generated files, even when they are under source control. Ergo, filter out files generated by agentic workflows.

To go further:

Originally published at A Java Geek on August 2^nd, 2026.

Two nasty surprises in Home Assistant's config

Nicolas Fränkel — Thu, 09 Jul 2026 07:02:00 +0000

Last year, I motorized the rolling shutters on the southern façade of my apartment. My idea was to manage them via Home Assistant. I had a couple of automations in mind:

In the evening, roll down the shutters of my bedroom
In the morning:
- If it's too hot outside, roll down all shutters
- If it's too cold outside, roll down all shutters
- In other cases, roll up all shutters but my bedroom's

Living in France, I added the official Météo France integration. The integration provides different measurements, including air temperature for my city. Here's the historical data. As you can see, it was pretty hot.

I could have used the temperature directly in the automation, but I wanted to define boolean sensors for "too hot" and "too cold" so I could reuse them across different automations. I defined two custom sensors:

template:
  - binary_sensor:
    - name: "Hot outside"
      unique_id: hot_outside_condition
      device_class: heat
      state: >
        {{ states('sensor.mycity_temperature') | float(0) >= 20 }}
    - name: "Cold outside"
      unique_id: cold_outside_condition
      device_class: cold
      state: >
        {{ states('sensor.mycity_temperature') | float(0) < 10 }}

At this point, you can use the time for the trigger, and a sensor defined for the condition:

  alias: Close all shutters in the morning when it's hot
  description: Close all shutters if it's already hot in the morning
  triggers:
    - trigger: time
      at: 06:00:00                               # 1
  conditions:
    - condition: state
      entity_id: binary_sensor.hot_outside
      state:
        - 'on'
  actions:
    - action: cover.close_cover
      metadata: {}
      data: {}
      target:
        entity_id:
          - cover.volet_salon_gauc_low_speed     # 2
          - cover.middle_shutter_low_speed       # 2
          - cover.s_so_rs100_io_low_speed_3      # 2
          - cover.s_so_rs100_io_low_speed_2      # 2
          - cover.s_so_rs100_io_low_speed        # 2

Time is relative to the timezone of the Home Assistant instance.
Unrelated, but I noticed that I need to work on my naming scheme

This year, I woke up earlier than last year. Because I was awake when the automation was supposed to run, I noticed it didn't. After fiddling a bit around, I noticed that the problem was related to the time. The UI showed a weird timezone: Paris/+1. If you're familiar with European time zones, you know about summer time. We move one hour forward during summer, then back again in autumn. However, it showed Paris/+1 instead of Paris/+2, though I was in summer.

I didn't know if it was a bug or not, but it felt like it was. The trigger time is relative to the instance's timezone, as callout <1> pointed out. Stuck one hour behind, my automation fired exactly on schedule. It was just an hour late compared to the actual time outside. In any case, you can override the timezone in the configuration.

I did, and immediately lost the connection. It turns out that once you override a single line in the homeassistant section, you lose all parameters set via the UI. It comprises the temperature unit, the distance metric, but also the URL you can access it. It falls back to the IP.

The fix is straightforward: set every line again.

homeassistant:
  name: Home
  time_zone: Europe/Paris
  latitude: <redacted>
  longitude: <redacted>
  elevation: <redacted>
  radius: 30
  unit_system: metric
  currency: EUR
  country: FR
  internal_url: http://home.local:8123

Note that once you use YAML-based configuration, the whole UI block becomes invalid.

After the changes, the automation worked as expected. Still, I shouldn't have to set the timezone manually for summer time to apply correctly. And I definitely shouldn't lose all UI-related settings because of it. Both feel like bugs on Home Assistant's side, and a quick search confirmed they are:

Time-based automations can get stuck on the pre-Daylight Saving Time offset until Home Assistant restarts: issue on core#153175, closed as not planned
Setting a single key under homeassistant disables the whole General settings page in the UI, not just the key set: issue on frontend#14628, also closed as not planned

Good luck on your Home Assistant path. I hope the above can be helpful.

To go further:

Originally published at A Java Geek on July 5th, 2026.

On programming languages, targets, and platforms

Nicolas Fränkel — Thu, 25 Jun 2026 09:02:00 +0000

I started as a Java developer, but for some time now, I have broadened my horizons. Recently, I thought about how early languages were dedicated to a single target and platform, and now they are broadening their focus. In this post, I want to write down my thoughts in the hope that it may be useful to others, probably to my future self.

Definitions

You may have been wondering about the title terms. I'm pretty sure that if you read this post, you have a pretty good picture of what a programming language is. Some may disagree on some finer points or raise a hair-splitting one, but it's not a PhD thesis, only a post on my blog. I must define what I mean by target and platform in the context of this post before going further.

Target
A target only makes sense in the context of compiled programming languages. For example, C's target is native code, and Java's is bytecode.

Platform
A platform is the system that will ultimately run the target. Native code runs on the operating system; bytecode on the JVM.

Early programming languages

Early programming languages had a single target and platform. I mentioned C and Java, but Ruby, Python, JavaScript, etc., were all the same.

Programming language	Target	Platform
C	Native code	Operating system
C++	Native code	Operating system
Java	Bytecode	JVM
Python	-	Python runtime
TypeScript	JavaScript	Browser & server-side JS
JavaScript	-	Browser

I believe it was the case for a long time. It changed at some point, though.

Multi-target is the new black

The first time I heard about multi-target was in Scala. Scala came from the era of single-target and targeted bytecode on the JVM platform. However, in 2015, Martin Odersky announced Scala.js, which added JavaScript to Scala's target.

The original article was published on InfoWorld, but it seems to have redirection issues nowadays. Here's the introduction on a copy:

Scala, developed as a functional and object-oriented language for the JVM, is now multiplatform, with developers using it in abundance on JavaScript via Scala.js, Scala founder Martin Odersky says.

With Scala.js, developers write code in Scala, and the code is then compiled to JavaScript, analogous to using Microsoft's TypeScript. Developers can leverage their Scala skills in Web development. "[Scala is] very popular on JavaScript now," Odersky said at the Scala Days conference in San Francisco.

—- Scala.js lets you compile Scala to JavaScript

While Scala was the first I had heard about, other languages started to target JavaScript: I know at least Kotlin and Clojure, two originally JVM-bound languages. From that point on, it seemed every language started to add more targets. When they didn't, third parties tried to do it.

I believe that Kotlin was the epitome of such a strategy. It started with JavaScript, but the team later added native with LLVM and is currently working on WebAssembly, as far as I know. Java developers weren't left behind. The GraalVM project, managed by Oracle, allows them to generate native code. A third-party project, TeaVM, targets JavaScript and WebAssembly. It seems that nowadays lots of languages target Wasm.

Here's a small excerpt of languages and what targets and platforms they support at the time of this writing. It can't be exhaustive and obviously focuses on the JVM ecosystem, which I happen to know better.

Programming language	Native/supporting project	Target	Platform
Java	Native	Bytecode	JVM
	GraalVM	Native code	Desktop OS
	TeaVM	JavaScript	Browser
		WebAssembly	Wasm runtime
		C	-
Kotlin	Native	Bytecode	JVM
		JavaScript	Browser
		JavaScript	Server-side runtimes
		Native	Desktop OS
			iOS
			Android
Dart	Native	JavaScript	Browser
	Native	WebAssembly	Wasm runtime
	DartNative	Native	Desktop OS
			iOS
			Android
Rust	Native	Native code	Desktop OS
	Native via a `target`	WebAssembly	Wasm runtime
	rustc_codegen_jvm	Bytecode	JVM
Zig	Native	Native code	Desktop OS
Zig	Zig and WebAssembly	WebAssembly	Wasm runtime
Swift	Native	Native code	Desktop OS
	Native	ARM machine code	Android
	SwiftWasm	WebAssembly	Wasm runtime
Python	Native	Python runtime	Desktop OS
	jythonc (archived)	Bytecode	JVM
	py2wasm	WebAssembly	Wasm runtime

Again, this is just a snapshot of projects I know at the time of this writing.

Discussion

Programming languages were initially focused on a single target and platform. With time, more and more languages broaden their horizon. It comes either as part of the language itself or is an effort from third parties.

It made sense so far. The bigger your organization's investment in a programming language, the harder it is to pivot to another one. In that light, GraalVM's native is a value proposition for Java-heavy organizations using Kubernetes. The JVM was meant for long-running tasks, while Kubernetes is built on the idea of stopping pods and starting new ones.

However, with the fast progress of AI, I wonder whether the trend will continue. Some might question the value. Instead of GraalVM'ifying existing Java applications, why not rewrite them directly in Rust, which natively compiles to machine code? This won't happen for core applications at the beginning, but I expect some may experiment with peripheral ones. If the experience nets benefits in terms of resource usage, then it may gnaw at core apps.

I'm very interested in the next few years to understand whether I'm imagining things, or if it will be a complete upheaval of the landscape.

To go further:

Originally published at A Java Geek on June 21^st, 2026.

Seasons time-lapse - the video

Nicolas Fränkel — Thu, 11 Jun 2026 09:02:00 +0000

In the first post of this series, I focused on the project foundations: what should I do to create a video from photos taken from the same position year after year? I dedicated the second part to aligning images. It wasn't as easy as I expected. I stumbled upon new concepts, such as ORB and RANSAC.

In this third and final post, I want to tackle the video creation itself, explain some "artistic" decisions, and leave the door open to future work.

Order

The decision with the greatest impact was about ordering pictures. I had several options available. The first thing that came to mind was to order by time of day. There were several problems:

I mostly run at lunch time. Thus, the passing of time would have been skewed toward a range from noon to 2PM.
The summer time vs. winter time change would have required a slight change in the pipeline.
Most importantly, the passing of seasons could have made the video weirdly looking. Frame X could be a sunny blue sky with man-high corn plants, frame X+1 a barren field under the snow, and then frame X+2 in summer again.

I decided instead to first order by day of the year, and only then by time of day. To get the time, I chose the EXIF metadata embedded in the picture itself.

Exif is supported by almost all digital camera manufacturers.

The metadata tags defined in the Exif standard cover a broad spectrum:

Camera settings: This includes static information such as the camera model and make, and information that varies with each image such as orientation (rotation), aperture, shutter speed, focal length, metering mode, and ISO speed information

Image metrics: Pixel dimensions, resolution, colorspace, and filesize

Date and time information, digital cameras will record the current (local) date and time set on the device and save this in the metadata

Location information

A thumbnail for previewing the picture on the camera's LCD screen, in file managers, or in photo manipulation software

Descriptions

Copyright information

— Wikipedia

I already extracted the EXIF data to get the location.

Images to video

In essence, a video is just a rapid succession of images. With enough frames per second, it gives the illusion of movement.

To get a feel of what it would look like, I did a straightforward montage. I had three realizations:

Creating the video is slow.
Just putting images one after another was not very aesthetically pleasing.
The video was quite short.

For point 1, I added code to make the video from a limited sample of pictures. For points 2 and 3, I interpolated frames between the pictures. Interpolation wasn't as easy as I had thought.

Imagine the pixel with coordinates (1,1) and color rgb(150,50,100) on picture 1. The same pixel in picture two has the same coordinates (1,1), but color rgb(50,250,120). I naively thought that if you inserted a single frame between them, the pixel's color would be the average of both colors' values: rgb((150+50)/2, (50+250)/2, (100+120)/2). This approach holds for images taken from the same location with the same angle, which is my use case.

In theory, there's no difference between theory and practice; in practice, there is.

It turns out that even with images within the same location and angle, there are elements moving between two consecutive images. The most frequent elements are clouds, but because images are not 100% aligned, most elements of interest move slightly. If you apply the above algorithm, clouds will become transparent or appear out of thin air, or probably both at the same time. It doesn't render nicely.

To improve the rendering, I applied the Gunnar-Farnebäck optical flow.

Optical Flow: Optical flow is known as the pattern of apparent motion of objects, i.e., it is the motion of objects between every two consecutive frames of the sequence, which is caused by the movement of the object being captured or the camera capturing it. Consider an object with intensity I (x, y, t), after time dt, it moves to by dx and dy, now, the new intensity would be, I (x+dx, y+dy, t+dt).

— GeeksForGeeks

You're welcome to read more of the mathematical foundations. Suffice it to say that it fits my use case. Note that frames with too many differences, such as those to or from a fog or snow picture, confuse the algorithm. In this case, I fall back to the simple color blending above. To check whether the fallback activates or not, the computation takes into account:

The average magnitude of the Farneback flow vectors across all pixels. It models large motion.
The mean absolute difference of grayscale pixel values between the two frames. It represents a large change in overall appearance.

Above a certain threshold, fall back.

I showed the work in progress on the first post, but here it is again:

Future works

I'm wondering how to even better align the images. The biggest problems are my lack of knowledge in the field and the lack of guaranteed reference points in the landscape I chose. For the former, I'll dig deeper using Claude Code. For the latter, the project is configurable enough to be reused with another picture set. I have fewer of them, but I'm pretty sure I'll be able to use more of them. A bit of disalignment makes the video more dynamic, though.

I'd also like to use another image set to validate the code's "productization". While I don't plan to make it a product, I'm still interested in whether it's possible and how much freedom it gives people.

Another axis is Open Sourcing it. You noticed I didn't publish the sources yet. The project is Python, and it's not a language I excel in. Plus, all the code has been generated with Claude Code. Thus, I don't feel very comfortable. If you are interested in helping me publish it, feel free to ping me.

Finally, I'm thinking about adding a filter option. For this project, I have something impressionist in mind. More specifically, I want to try both a Turner's style and a Seurat pointillist one. I like their respective work, even though their styles are quite far apart.

If I can implement both, then nothing would stop potential users from implementing their own.

Conclusion

I had this project in mind for ages. However, only Claude Code allowed me to make it a reality. For once, I have more fun creating something than coding. I actually didn't write a single line of code by myself.

Have I joined the dark side?

Originally published at A Java Geek on June 7^th, 2026.

AI gateways: why and how

Nicolas Fränkel — Thu, 04 Jun 2026 09:02:00 +0000

Before working for 2 years on the Apache APISIX API gateway, I was mainly oblivious to API gateways. It's only by working with them that I understood their value. Decoupling the client and the server unlocks a lot of options: moving authentication to the API Gateway, securing APIs, deduplicating API requests, etc.

In this post, I want to describe how the same pattern applies to AI.

AI gateways

AI gateways work in a similar way. They proxy requests and responses between an AI client and its LLM backend(s). Likewise, it unlocks many improvements:

AI management: single glass pane to address multiple AI models and providers, simplifying the complexity of integrating and switching between different services.
Compliance and governance: enforce security, data privacy, and compliance in a single place.
Cost control: intelligent routing, semantic caching, and budget management.
Avoiding lock-in: clients depend on an abstraction under control; the gateway manages server API updates and even migrations to a new provider.
Scalability and reliability: supports automatic failover and load balancing.
Observability: need I say more?

My use-case

I love Claude Code; it's amazing, and my experience is more than positive. It has one problem, though: Anthropic is a US-based company, and subject to the Patriot Act. By design, Anthropic must comply with any US government request to access all of my data. As a non-US citizen, I have no right to object. I have no right to be told.

On the other hand, Mistral AI is a European Union-based company. I have heard pretty good stuff about it, especially devstral:

Today we introduce Devstral, our agentic LLM for software engineering tasks. Devstral is built under a collaboration between Mistral AI and All Hands AI 🙌, and outperforms all open-source models on SWE-Bench Verified by a large margin. We release Devstral under the Apache 2.0 license.

— Devstral

It would be amazing if I could use Claude Code while routing the calls to devstral. AI gateways are a perfect fit.

Available AI gateways

In case you are in need of an AI gateway, please do your due diligence. Because it's exploratory work, I did a pretty shallow search, not deep research. These are the ones that surfaced.

LiteLLM:

LiteLLM is an open-source library that gives you a single, unified interface to call 100+ LLMs — OpenAI, Anthropic, Vertex AI, Bedrock, and more — using the OpenAI format.

Call any provider using the same completion() interface — no re-learning the API for each one

Consistent output format regardless of which provider or model you use

Built-in retry / fallback logic across multiple deployments via the Router

Self-hosted LLM Gateway (Proxy) with virtual keys, cost tracking, and an admin UI

— Getting Started

Bifrost:

Bifrost is a high-performance AI gateway that unifies access to 20+ providers OpenAI, Anthropic, AWS Bedrock, Google Vertex, Azure, and more, through a unified API. Deploy in seconds with zero configuration and get automatic failover, load balancing, semantic caching, and enterprise-grade governance. In sustained benchmarks at 5,000 requests per second, Bifrost adds only 11 µs of overhead per request.

— Overview

OpenRouter:

OpenRouter provides a unified API that gives you access to hundreds of AI models through a single endpoint, while automatically handling fallbacks and selecting the most cost-effective options. Get started with just a few lines of code using your preferred SDK or framework.

— Quickstart

I chose Bifrost for several reasons. It's self-hosted, it's close to the metal (it's written in Go), and the quickstart is dead simple via npx. It is also available via a Docker image. It has a UI, which is great for exploring features. Finally, it has baked-in observability.

Bifrost 5-minute quick start

Starting Bifrost is a single command:

npx -y @maximhq/bifrost

The menu's first item shows the telemetry dashboard. It's quite useful.

The first step is to create a model provider for Mistral. Go to Models > Model Providers. Then click on + Add New Provider. Finally, choose + Add new key and fill the fields accordingly. You should have previously generated a Mistral API key.

The second step is to create a routing rule so that Claude Code requests targeting any of Anthropic's models target Mistral instead. Go to Models > Routing Rules. Click on + New rule, then inside the opening menu, on + Add Target.

Provider: Mistral AI
Model: devstral-2512

Leave all other fields blank.

Before launching Claude Claude, export the following environment variables:

export ANTHROPIC_BASE_URL=http://localhost:8080/anthropic     # 1
export ANTHROPIC_AUTH_TOKEN=sk-dummy                          # 2

Use the local Bifrost instead of the default Anthropic URL
Unused, but necessary

It should just be a matter of starting Claude Code and having fun. Unfortunately, it fails.

❯ hello
  ⎿  API Error: 422 {"type":"error","error":{"type":"api_error","message":"provider API error (status 422)"}}

Debugging the setup

Failures are always great opportunities to understand a solution better. On the provider, click on Edit Provider Config. Set the switch of the Debugging tab.

Then, in Observability > LLM Logs, select the failing request. Find the section named Raw Response from Mistral. It looks something like this:

{
  "object": "error",
  "message": {
    "detail": [
      {
        "type": "enum",
        "loc": [
          "body",
          "reasoning_effort"
        ],
        "msg": "Input should be 'none' or 'high'",
        "input": "medium",
        "ctx": {
          "expected": "'none' or 'high'"                // 1
        }
      }
    ]
  },
  "type": "invalid_request_error",
  "param": null,
  "code": null,
  "raw_status_code": 422
}

There's a mismatch between the request sent by Claude Code and what Mistral expects.

At this point, I had pinpointed the issue. I opened a bug report. The feedback came back in less than an hour, and the fix attempt was in a couple of weeks. It still doesn't work, but I found a workaround.

export CLAUDE_CODE_DISABLE_THINKING=1

Extended thinking is the reasoning Claude emits before responding. On models that support adaptive reasoning, the effort level is the primary control for how much thinking happens; the settings below turn thinking on or off and control how it displays.

— Extended thinking

At this point, it works, but at the cost of a lack of higher reasoning.

Budget management

The above is good for a personal setup, but in enterprise settings, you'll rarely see this approach, if ever. What you regularly see, however, is a monthly spending limit. This situation has two issues:

Users must be able to track their usage. Without precise tracking, they run the risk of consuming too many tokens too early.
If you overspend, you are stuck until the counter resets, which generally happens at the start of the next month. Ask me how I know.

AI gateways in general, and Bifrost in particular, allow lots of options to handle both. I'll leave the metering aside for this post to focus on the usage itself. The AI gateway could do a couple of things to help manage the budget.

Set a daily cap. It's better to be capped for half an hour at the end of the day than for more than a day at the end of the month.
Redirect request using specific models to other models. You can use it to prevent users from using expensive models. At the moment of this writing, Claude Opus tokens cost at least 5 times more than Claude Sonnet's.
Degrade model when over-budget. Once users have gone over a specific budget, redirect requests to a less expensive model.
Redirect to self-hosted model when over-budget.

These are just a couple of the use cases that you could implement.

Simple fallback

In this section, I want to demo the last item. In an enterprise setting, you could host the fallback on a cloud instance or even self-host. In the context of this post, I'll limit myself to falling back to a local llama-server if above the set limit.

The first step is to define a spending limit. Go to the Mistral provider defined earlier. Set the limit in the Governance tab. Here's where I set the cap to 100,000 tokens daily for demo purposes.

The second step is to add a Llama Server provider. It's type custom.

API Structure: The base is OpenAI, because llama-server is compatible. Remember to limit the Allowed Request Types to what the model can actually do. For my model, it's Chat Completion and Chat Completion Stream.
Network: Set the Base URL to http://localhost:<port>. Because Bifrost binds on port 8080, I run llama-server on 8081.

The third and final step is to add a fallback to the existing routing rule.

With the low number of tokens set, you'll hit the ceiling after one or two requests.

On the next request, Bifrost will:

Evaluate the condition
Prevent the request from reaching Mistral
And send it to the fallback Llama server instead.

Bifrost logs the two requests, the first one to Mistral AI and the second to Llama. Here's a sample:

Conclusion

AI gateways are a fantastic architectural improvement. Bifrost looks great on paper, and the dashboard seems quite exhaustive.

Unfortunately, a Bifrost bug currently prevents the implementation of my extended thinking. I hope maintainers fix it fast and I can work further on AI gateways "for real".

However, when it works, I'll be able to leverage Claude Code's amazing client with the LLM of my choice, including Devstral.

To go further:

Originally published at A Java Geek on May 31^st, 2026.

Seasons time-lapse - alignment

Nicolas Fränkel — Thu, 28 May 2026 09:02:00 +0000

In the previous post, I described the Seasons project: a time-lapse of hundreds of pictures taken from nearly the same viewpoint over the years. The hardest challenge wasn't taking the pictures or assembling them, but aligning them.

You might have noticed the nearly part about viewpoint in the above paragraph. Indeed, it's an approximation. I'm a human being, not a tripod. The position changes ever so slightly, and so does the exact angle. My phone has changed over the years, from a Samsung S10 to an S21, and now I'm using an iPhone 14 Pro. Each of them has a different camera with a different focal length. The resulting photos look similar but are definitely not identical: slightly different scales and angles. Without any correction, the landscape appears to be moving a lot.

Alignment is the process of warping each photo so it looks like it was taken from exactly the same angle as a reference image.

OpenCV for feature matching

For image-related features, OpenCV is the go-to library.

OpenCV is the world's biggest computer vision library.

OpenCV is open source, contains over 2500 algorithms, and is operated by the non-profit Open Source Vision Foundation.

—- OpenCV

The most straightforward approach is to find key points across images, match them, then compute a geometric transform from the matches. It's feature matching. OpenCV provides an algorithm for that called ORB.

ORB is basically a fusion of FAST keypoint detector and BRIEF descriptor with many modifications to enhance the performance. First it use FAST to find keypoints, then apply Harris corner measure to find top N points among them. It also use pyramid to produce multiscale-features.

—- ORB (Oriented FAST and Rotated BRIEF)

I mentioned two steps above: first, matching key points, then transforming the rest of them. Once key points are matched, you need an algorithm for the transformation. Meet RANSAC:

The RANSAC algorithm is a learning technique to estimate parameters of a model by random sampling of observed data. Given a dataset whose data elements contain both inliers and outliers, RANSAC uses the voting scheme to find the optimal fitting result. Data elements in the dataset are used to vote for one or multiple models. The implementation of this voting scheme is based on two assumptions: that the noisy features will not vote consistently for any single model (few outliers) and there are enough features to agree on a good model (few missing data).

—- RANSAC

I first used a 3x3 matrix, also called homography for the transformation. It resulted in very distorted images with perspective distortion. Every small error in keypoint matching was amplified. I fixed it by using a smaller matrix, 2x3, which only handled translation and uniform scale.

That still left a nondeterministic problem. RANSAC is randomised by design. Run it twice on the same data, and you may get slightly different rotations. For a time-lapse, that means the horizon can drift from frame to frame. The fix was to discard rotation entirely and force it to zero after RANSAC, then recompute the translation analytically from the inlier matches.

The scale tolerance also required careful tuning. The Samsung S10 has a 4.30mm focal length, while the iPhone 14 Pro has a 6.86mm one. A photo from one device is 1.6× the scale of a photo from the other. Any scale gate tighter than that would wrongly reject valid cross-device frames.

There was one more spatial problem. ORB keypoints cluster on high-texture regions — in my photos, trees and rooftops. A transform fitted only from one corner of the image is less stable than one fitted from points spread across the whole frame. The fix was to divide the image into a 4×4 grid and cap the number of keypoints per cell, forcing a more even spatial distribution.

Finally, the output resolution. Each aligned frame produces a valid crop region — the area of the reference frame it fully covers. If you take the intersection of all crops, one frame with an extreme offset shrinks the output for everyone. Instead, the crop boundaries are computed from percentiles across all frames: the worst 15% of frames on each edge are ignored, and any frame that falls outside the resulting crop is dropped.

Neural matching with SuperPoint and LightGlue

ORB works well on scenes with clear texture. In winter, photos with snow-covered fields, foggy mornings, and overcast skies degrade quickly. There is simply not enough distinctive texture for classical descriptors to anchor on. I kept it as a fallback when the following approach doesn't fall within the expected range.

The first step is a pair of Open Source neural models:

SuperPoint is a self-supervised keypoint detector trained to find stable, repeatable points across varying lighting and viewpoints.
LightGlue is a transformer-based matcher that pairs SuperPoint keypoints across two images and produces a confidence score for each match.

Both run locally on Apple Silicon via MPS.

SuperPoint needs a reference image. To avoid extracting its features hundreds of times, they are computed once at startup and reused for every frame.

The first version of the quality score was wrong. I measured it as the fraction of LightGlue matches that survived RANSAC. That made almost every frame poorly aligned.

The root cause was parallax. LightGlue finds geometrically correct matches, the same real-world point in both images, but many are rejected by RANSAC because the scene has depth. Objects at different distances don't move the same way when the camera shifts slightly. The matches aren't wrong; they just don't fit a flat-world model.

The fix was to score alignment using the mean LightGlue confidence of the RANSAC inliers only. With trial and error, I found that a good alignment score sits between 0.82 and 0.96. Frame acceptance went from 19.7% to 53.2%.

Here's the final representation of the alignment pipeline's nominal path:

In the next part, I'll describe how I smoothed the motion between frames using optical flow and the final result.

Originally published at A Java Geek on May 24^th, 2026.

Seasons time-lapse - the foundations

Nicolas Fränkel — Thu, 21 May 2026 09:02:00 +0000

I live close to nature. I regularly go for a run in the countryside. Over several years, during my runs, I've taken pictures from the same position, always roughly the same angle. I had a vague idea in the back of my mind, as an "artistic" project. One day, I'd turn those photos into a time-lapse video, one that would show the passage of seasons across a single place.

Spoiler, here's the work in progress:

However, I knew that this project would take ages. I have no experience in image manipulation and video making. My knowledge of codecs is that the movie I have doesn't play on my Internet box.

The amazing progress in coding assistants made this project possible. I hate the term "vibe coding", and I hope I provided accurate technical direction, but I admit I didn't do anything on my own. I just fed my instructions to the assistant, and it did the job.

In this multi-part series, I aim to reflect on my actions. There's no reason why we can't have a useful retrospective in LLM-assisted projects.

In any regular project, choosing your stack is the most important part. You can refer to Choosing a dependency for them. Vibe-coding adepts will gladly tell you that code is not an asset anymore, but that you can (and should) discard it and start from scratch at every iteration.

After describing my idea and its foundation, I asked the assistant whether to choose between the JVM, Python, or any other stack. It chose Python. At several steps in the process, I asked it to reassess its choice again. Still Python.

My argument for performance got rebuked:

The performance argument doesn't apply. The slow parts — OpenCV operations, neural inference — run as C++/CUDA/Metal underneath regardless of whether you call them from Python or Java. Python's interpreter overhead is irrelevant here.

To keep things in check and help the assistant, I enforce types and tests.

The project is fundamentally a processing pipeline. Steps are:

Inventory: glob all configured directories for photos and extract EXIF metadata, date, focal length, GPS coordinates.
Filter: keep only photos taken within 100 metres of a configured reference GPS point. Many photos lacked GPS data entirely, those are dropped.
Align: warp each photo so it looks like it was taken from exactly the same angle as a reference image. This is the hard part, and it gets its own post.
Order: sort the aligned frames according to a simple algorithm. I chose by day-of-year and time-of-day to assemble a composite year from photos taken across multiple real years.
Render: encode the ordered frames into a video.

The pipeline is driven by a config file at the project root:

[input]
dirs = ["/path/to/photos/1", "/path/to/photos/2"]        # 1
extensions = [".heic", ".jpg", ".jpeg"]                  # 2

[reference]
dir = "reference"
latitude = 46.135536
longitude = 6.111831

[filter]
gps_radius_m = 100.0

[output]
fps = 12
blend = true

The autosave application changed its default location
I changed my phone as well

GPS coordinates are mandatory. The pipeline fails early if they're missing. Without them, the filter step has nothing to anchor to.

To iterate more quickly, I weaved in a --sample flag to run the full pipeline on a random subset of photos. A full run processes hundreds of images and takes minutes; a 50-image sample takes seconds. Iterating on the alignment code was initially too time-consuming without sampling.

The inventory, filter, order, and render steps are largely straightforward. Alignment is not. In the next part, I'll describe how I went from a naive approach that produced wobbly, misaligned frames to a neural matcher that gets most frames right.

Originally published at A Java Geek on May 17^th, 2026.

Tokensparsamkeit for coding assistants

Nicolas Fränkel — Thu, 14 May 2026 09:02:00 +0000

You make decisions with data. Most businesses assumed that the most data, the better the decision. Then, several factors put a halt to the hoarding of always more data. GDPR and its localized counterparts, and the cost of storage. However, before it happened, the Datensparsamkeit approach already existed.

Datensparsamkeit is a German word that's difficult to translate properly into English. It's an attitude to how we capture and store data, saying that we should only handle data that we really need.

— Datensparsamkeit

I don't agree with Martin Fowler's claim that it's difficult to translate. The translation of Sparsamkeit is frugality. In the context of coding assistants, token frugality is a good thing.

Today, critical resources aren't CPU, RAM, or storage, but tokens. Tokens are a finite and expensive resource. My opinion is that soon, developers will be measured on their token usage: the better one will be the one using the fewest tokens to achieve similar results.

— Writing an agent skill

Imagine two engineers finishing the same job with the same quality in the same timeframe. If the organization needs to let go of one, it will be the one that costs more. In the era of AI, it means the one who consumes more tokens.

In this post, I want to show a couple of methods to keep the usage of tokens small.

Compression

One of the first steps toward Tokensparsamkeit is to compress tokens sent to the underlying LLM while keeping the same data. But what are tokens? It's a gross oversimplification, but you for the sake of explanation, let's consider a word is a token. Read this deep dive if you want more details.

If we consider tokens are words, we could remove articles and similar words from the payload to decrease the tokens number. "Find the distance between the Earth and the moon" becomes "Find distance between Earth and moon". For all intents and purpose, the data received is the same, with less words.

The trick is to set a proxy between the client and the LLM backend. I'm using rtk myself:

CLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Single Rust binary, zero dependencies

— rtk project on GitHub

The tool works across file commands, git, gh, test runners, build/lint commands, aws, docker, kubectl, etc. Note that it's not a magical recipe, as rtk itself mentions:

This only applies to Bash tool calls. Claude Code built-in tools such as Read, Grep, and Glob bypass the hook, so use shell commands or explicit rtk commands when you want RTK filtering there.

Context optimization

The second step toward Tokensparsamkeit is to avoid stuffing the context with irrelevant data.

Most people who start using coding assistants assume the context only consists of the system prompt and user prompts. There actually is a lot more. Anthropic's Effective context engineering for AI agents article mentions:

System prompt
User prompt
Message history
Tool definitions
Tool results
MCP servers
RAG
Agent memory if applicable

Claude Code introduced the option to compact (or clear?) the context before each interaction. It explicitly asked with each interaction whether to do it. I liked it, but they removed it a week or so later. Perhaps too many people didn't understand what it entailed? In any case, make good use of the /compact command that most assistants provide: it will reduce the conversation history to reduce its token usage, while trying to keep the relevant bits.

Also notice that tools and MCP servers use tokens; the more you configure, the more tokens used. Some MCP servers are so easy to set up, it's tempting to stuff your assistant with them. Don't. Or enable them either on a case-by-case basis or at the project level. Why enable the Vaadin MCP on a Rust project?

The same goes for tools, although I don't think many do use them a lot in comparison to MCP servers.

Local models

Tokens usage is only important for cloud-based billing. We don't care about it if we use a local model. There are several ways to do it, including AI gateways. In the scope of this article, I'll keep it simple.

I want to keep Claude Code as the client, because it's really good. At the same time, I want to use my own hardware with a local model: the cost is upfront, but then I have zero recurring cost but the power.

If you want to just do it, How to Run Local LLMs with Claude Code is where I found the solution. Continue reading the section if you want to read about the issues I faced.

I tried initially to run Qwen3 32B via Ollama in Docker. Docker containers cannot access Apple's Metal GPU framework, so the model ran entirely on CPU. It loaded successfully but crashed during inference with a 500 error; CPU-only inference on a 32B model is simply too slow to be usable.

I have been using Ollama a bit as the default, because others did. Then I stumbled upon Friends Don't Let Friends Use Ollama. I switched from Ollama to llama-cpp, which enabled low-level configuration.

The biggest hurdle was the context window size. Claude Code sends lots of tokens to the backend. On the OpenTelemetry tracing demo, it's around 35k on each request.

I started with Qwen3 models. The default token size wasn't big enough. When a model received more tokens than its maximum, llama server immediately rejects the request. I tried to increase the limit with the --ctx-size option, to no avail. Qwen3 modelsare trained with 32,768 tokens. It's a hard limit baked into the GGUF file metadata. Llama server abides by it.

Llama server is meant to serve multiple requests simultaneously. It turns out that the count of available tokens is shared equally across all possible requests. If the number of max tokens is T and the server can handle x requests in parallel, each request only has T/x tokens available. For this reason, I set the parallelism with --parallel 1.

Despite all of the above, it still didn't work.

Mixture of Experts vs. dense models

I was using a dense model, which is what we use regularly. Dense models load all in memory at once. The alternative is to use a Mixture of Experts model.

In the context of transformer models, a MoE consists of two main elements:

Sparse MoE layers are used instead of dense feed-forward network (FFN) layers. MoE layers have a certain number of "experts" (e.g. 8), where each expert is a neural network. In practice, the experts are FFNs, but they can also be more complex networks or even a MoE itself, leading to hierarchical MoEs!

A gate network or router, that determines which tokens are sent to which expert. For example, in the image below, the token "More" is sent to the second expert, and the token "Parameters" is sent to the first network. As we'll explore later, we can send a token to more than one expert. How to route a token to an expert is one of the big decisions when working with MoEs - the router is composed of learned parameters and is pretrained at the same time as the rest of the network.

— What is a Mixture of Experts

In layman's terms, a MoE segments its weights/parameters into separate specialized submodels called experts. A routing layer activates only the necessary experts depending on the request. Compared to regular dense models, instead of computing across the entire model of size T, only a small subset of experts is activated per request. The combined size of activated experts t is much smaller than T, even though the sum of all experts together is larger than T.

The Qwen3.5-35B-A3B model is a MoE that works perfectly on my machine.

Putting it all together

We still miss a couple of elements to reach the goal.

To better interact with Claude Code, the model should return structured content. That's what the --jinja flag is for. For better performance, you should also use Flash Attention. It's an optimized algorithm for computing the attention mechanism in Transformer models. It's faster, more memory-efficient, and more scalable than standard attention. Activate it via --flash-attn on. The last configuration parameter is to offload as many layers as possible to the GPU with --n-gpu-layers 99.

The final server command line is:

llama-server \
  --model ~/models/Qwen3.5-35B-A3B-Q4_K_M.gguf \
  --n-gpu-layers 99 \
  --ctx-size 65536 \
  --parallel 1 \
  --flash-attn on \
  --jinja \
  --port 8080

On the Claude Code side, we need to set several environment variables:

Environment variable	Meaning	Example
`ANTHROPIC_BASE_URL`	URL to the `llama-server` instance	`http://127.0.0.1:8080`
`ANTHROPIC_API_KEY`	Anything	`dummy`
`ANTHROPIC_AUTH_TOKEN`	Anything	`dummy`
`CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC`	Self-explicit	`1`

export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export ANTHROPIC_API_KEY=dummy
export ANTHROPIC_AUTH_TOKEN=dummy
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
claude

At this point, you can use Claude Code, which will query your local model. Here's a sample server output for a query, for information.

srv  params_from_: Chat format: peg-native
slot get_availabl: id  0 | task -1 | selected slot by LCP similarity, sim_best = 0.788 (> 0.100 thold), f_keep = 0.789
slot launch_slot_: id  0 | task -1 | sampler chain: logits -> ?penalties -> ?dry -> ?top-n-sigma -> top-k -> ?typical -> top-p -> min-p -> ?xtc -> temp-ext -> dist 
slot launch_slot_: id  0 | task 1464 | processing task, is_child = 0
slot update_slots: id  0 | task 1464 | new prompt, n_ctx_slot = 65536, n_keep = 0, task.n_tokens = 56401
slot update_slots: id  0 | task 1464 | n_past = 44456, slot.prompt.tokens.size() = 56378, seq_id = 0, pos_min = 56377, n_swa = 0
slot update_slots: id  0 | task 1464 | Checking checkpoint with [56141, 56141] against 44456...
slot update_slots: id  0 | task 1464 | Checking checkpoint with [55629, 55629] against 44456...
slot update_slots: id  0 | task 1464 | Checking checkpoint with [49151, 49151] against 44456...
slot update_slots: id  0 | task 1464 | Checking checkpoint with [40959, 40959] against 44456...
slot update_slots: id  0 | task 1464 | restored context checkpoint (pos_min = 40959, pos_max = 40959, n_tokens = 40960, n_past = 40960, size = 62.813 MiB)
slot update_slots: id  0 | task 1464 | erased invalidated context checkpoint (pos_min = 49151, pos_max = 49151, n_tokens = 49152, n_swa = 0, pos_next = 40960, size = 62.813 MiB)
slot update_slots: id  0 | task 1464 | erased invalidated context checkpoint (pos_min = 55629, pos_max = 55629, n_tokens = 55630, n_swa = 0, pos_next = 40960, size = 62.813 MiB)
slot update_slots: id  0 | task 1464 | erased invalidated context checkpoint (pos_min = 56141, pos_max = 56141, n_tokens = 56142, n_swa = 0, pos_next = 40960, size = 62.813 MiB)
slot update_slots: id  0 | task 1464 | n_tokens = 40960, memory_seq_rm [40960, end)
slot update_slots: id  0 | task 1464 | prompt processing progress, n_tokens = 43008, batch.n_tokens = 2048, progress = 0.762540
slot update_slots: id  0 | task 1464 | n_tokens = 43008, memory_seq_rm [43008, end)
slot update_slots: id  0 | task 1464 | prompt processing progress, n_tokens = 45056, batch.n_tokens = 2048, progress = 0.798851
slot update_slots: id  0 | task 1464 | n_tokens = 45056, memory_seq_rm [45056, end)
slot update_slots: id  0 | task 1464 | prompt processing progress, n_tokens = 47104, batch.n_tokens = 2048, progress = 0.835163
slot update_slots: id  0 | task 1464 | n_tokens = 47104, memory_seq_rm [47104, end)
slot update_slots: id  0 | task 1464 | prompt processing progress, n_tokens = 49152, batch.n_tokens = 2048, progress = 0.871474
slot update_slots: id  0 | task 1464 | n_tokens = 49152, memory_seq_rm [49152, end)
slot update_slots: id  0 | task 1464 | 8192 tokens since last checkpoint at 40960, creating new checkpoint during processing at position 51200
slot update_slots: id  0 | task 1464 | prompt processing progress, n_tokens = 51200, batch.n_tokens = 2048, progress = 0.907785
slot update_slots: id  0 | task 1464 | created context checkpoint 6 of 32 (pos_min = 49151, pos_max = 49151, n_tokens = 49152, size = 62.813 MiB)
slot update_slots: id  0 | task 1464 | n_tokens = 51200, memory_seq_rm [51200, end)
slot update_slots: id  0 | task 1464 | prompt processing progress, n_tokens = 53248, batch.n_tokens = 2048, progress = 0.944097
slot update_slots: id  0 | task 1464 | n_tokens = 53248, memory_seq_rm [53248, end)
slot update_slots: id  0 | task 1464 | prompt processing progress, n_tokens = 55296, batch.n_tokens = 2048, progress = 0.980408
slot update_slots: id  0 | task 1464 | n_tokens = 55296, memory_seq_rm [55296, end)
slot update_slots: id  0 | task 1464 | prompt processing progress, n_tokens = 55885, batch.n_tokens = 589, progress = 0.990851
slot update_slots: id  0 | task 1464 | n_tokens = 55885, memory_seq_rm [55885, end)
slot update_slots: id  0 | task 1464 | prompt processing progress, n_tokens = 56397, batch.n_tokens = 512, progress = 0.999929
slot update_slots: id  0 | task 1464 | created context checkpoint 7 of 32 (pos_min = 55884, pos_max = 55884, n_tokens = 55885, size = 62.813 MiB)
slot update_slots: id  0 | task 1464 | n_tokens = 56397, memory_seq_rm [56397, end)
reasoning-budget: activated, budget=2147483647 tokens
slot init_sampler: id  0 | task 1464 | init sampler, took 4.37 ms, tokens: text = 56401, total = 56401
slot update_slots: id  0 | task 1464 | prompt processing done, n_tokens = 56401, batch.n_tokens = 4
slot update_slots: id  0 | task 1464 | created context checkpoint 8 of 32 (pos_min = 56396, pos_max = 56396, n_tokens = 56397, size = 62.813 MiB)
srv  log_server_r: done request: POST /v1/messages 127.0.0.1 200
reasoning-budget: deactivated (natural end)
slot print_timing: id  0 | task 1464 | 
prompt eval time =   65949.79 ms / 15441 tokens (    4.27 ms per token,   234.13 tokens per second)
       eval time =    3639.91 ms /    87 tokens (   41.84 ms per token,    23.90 tokens per second)
      total time =   69589.71 ms / 15528 tokens
slot      release: id  0 | task 1464 | stop processing: n_tokens = 56487, truncated = 0

Discussion

While the underlying model is important, most people undervalue the client. I used both Claude Code and Copilot CLI with the same underlying model, Claude Sonnet 4.6. I found Claude Code superior by far across several sessions.

The move of most vendors toward subscriptions to benefit from recurring revenues make sense for them. For the customer, however, it's another question: once you stop paying, you lose access to the service.

In the context of coding assistants, vendors justify it by cloud usage. Unfortunately, the per-token metering is quite opaque. If the vendor doesn't size their service properly, users get charged more. I don't think that's fair.

Keeping Claude Code while hosting the model local is a great cost-savvy alternative. You only need to pay for the hardware once. Granted, it's slower, but it's a business model I prefer. If you have well-designed working autonomous agents, you can run them during the night anyway.

To go further:

Originally published at A Java Geek on May 10^th, 2026.

Designing a team of agents

Nicolas Fränkel — Thu, 07 May 2026 09:02:00 +0000

I continue to experiment with AI in the context of software engineering. I'm fortunate that my team supports me in exploring different ways to improve our daily work. This week, I designed a team of autonomous agents to implement features, from design to implementation.

Why autonomous agents?

A long time ago, we were delighted when the IDE offered auto-completion. In the previous two years, things have changed. A lot.

Coding assistants have become our primary interfaces for coding. We still use IDEs, at least I do. Yet, I had an IDE licensing issue two weeks ago, and I continued to code even without it. The assistant automatically compiles and tests after every change. While it was forced on me, I believe it could be a valuable test for seasoned programmers: can you replace your IDE with your coding assistant, or are they complementary?

That being said, chatting with your assistant is but a step in the AI maturity level. In The 8 Levels of Agentic Engineering, the author mentions the following steps:

Levels 1 & 2: Tab Complete and Agent IDE
Level 3: Context Engineering
Level 4: Compounding Engineering
Level 5: MCP and Skills
Level 6: Harness Engineering & Automated Feedback Loops
Level 7: Background Agents
Level 8: Autonomous Agent Teams

Claude Code's experimental Agent Teams feature is an early implementation: multiple instances work in parallel on a shared codebase, where teammates operate in their own context windows and communicate directly with each other. Anthropic used 16 parallel agents to build a C compiler from scratch that can compile Linux. Cursor ran hundreds of concurrent agents for weeks to build a web browser from scratch and migrate their own codebase from Solid to React.

Obviously, I have neither the resources nor the know-how to tackle such a huge undertaking. However, I wanted to design a team to handle smaller tasks.

Subagents

I recently wrote about subagents.

Claude describes several benefits of using subagents:

Preserve context by keeping exploration and implementation out of your main conversation

Enforce constraints by limiting which tools a subagent can use

Reuse configurations across projects with user-level subagents

Specialize behavior with focused system prompts for specific domains

Control costs by routing tasks to faster, cheaper models like Haiku

— Create custom subagents

Claude Code provides several built-in subagents: explore, plan, general purpose, status line, and Claude Code guidelines. You can read more about each of them in the documentation.

However, and this is where it gets interesting, you can define a specialized subagent through a dedicated Markdown file with a specific front matter in a .claude/agents folder. The front matter defines: a name, a description, a model, and a list of available tools. The body describes the subagent's purpose, i.e., its instructions. Here's a sample:

---
name: code-reviewer
description: "Reviews code for quality and best practices"
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.

— Write subagent files

The team design

I asked Claude Code to come up with the team design. He created a plan that included five subagents: planner, challenger, coder, tester, and documenter. Their name are pretty self-descriptive, but I'll come back to them later. In the meantime, I read that the optimal number of agents in a team is between three and five: I removed the documenter.

"Regular" subagents do their tasks autonomously, but then come back to the main agent. Subagents in teams communicate with each other directly.

After defining agents, you need to specify how subagents communicate with each other toward the accomplishment of a task. You describe such interactions in a skill, which Claude also created for me. Here's a very simplified model.

States represent agent responsibilities in their respective agent file, while interactions represent communication between agents in the skill. Note that I added extra communication constraints within agent descriptions. I work as usual with Claude Code. The only difference is when it's time to implement; instead of telling it to proceed, I call the /implement skill from the command line.

Here's how it looks (at the moment) in the console:

4 tasks (0 done, 4 open)
  ◻ Approve plan › blocked by #3
  ◻ Implement merged CSV hierarchy changes › blocked by #1
  ◻ Plan: materialize merged CSVs with new hierarchy across both repos
  ◻ Write tests for merged CSV changes › blocked by #2

Team agents beyond marketing

Agents' teams are amazing, but they come with issues.

The biggest one is the tension between autonomy and security. In regular Claude Code sessions, it's easy to grant permission when it asks for a command. With regular subagents, I notice it gets a bit more tedious: requests for permissions are much more frequent. Agents' teams reach a peak in that regard.

To cope with that, you can add permissions in your settings.json and hope they cover the commands made by Claude Code in the session. Alternatively, you can use the aptly-named --dangerously-skip-permissions flag, or wait for the slightly safer auto mode. In all cases, you must arbitrate between autonomy and security. Too much security slows you down, too much autonomy is risky.

Also, agents' teams are experimental at the moment. They might be better in the future, be widely different, or not exist at all. To enable them now, set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS to 1 in settings.json.

On the plus side, it pays to invest time in agents. Within or without teams, you explicitly call agents on the command line.

Conclusion

Autonomous agent teams sit at the top of the agentic engineering ladder. Getting there requires designing agent interactions upfront and solving the autonomy vs. security tradeoff.

The feature is experimental, and I'd treat it as such, but the direction is clear. We are already spending less time coding directly and more time managing agents. Agents' teams are the next logical step.

To go further:

Originally published at A Java Geek on May 3^rd, 2026.

Three Mastodon issues because of Cloudflare Bot protection

Nicolas Fränkel — Thu, 30 Apr 2026 09:02:00 +0000

I noticed some time ago that three Mastodon features had stopped working on my blog. Each of them seemed like a separate problem, but they had the same root cause. In this blog post, I want to describe these issues and the simple fix.

Domain verification

Mastodon allows you to prove that you own a domain. The mechanism requires two steps:

Add a <link rel="me"> tag in your pages, pointing to your Mastodon profile
Add your website URL to your Mastodon profile

When Mastodon crawls your page and finds the backlink, it displays a green checkmark next to your URL in your profile.

I had set this up long ago and made it work, for my blog and GitHub. Then, the blog link stopped working, while GitHub's still worked. It made me sad, but I couldn't understand what changed.

Post preview

When you share a link on Mastodon, your instance crawls the page to generate a preview card. It reads the page's OpenGraph tags: title, description, and image.

My blog had all the correct tags. Yet every blog post I shared appeared as a plain link with no card. However, all newsletters shared the same preview image, and they mysteriously worked.

Attribution

Mastodon introduced author attribution in the 4.3 version. If a page contains the following meta tag, Mastodon displays a "By @author" badge when someone else shares the link — and lets their followers follow you directly from the preview.

<meta name="fediverse:creator" content="@frankel@mastodon.top">

This had never worked for my blog since I added it.

The culprit

All three features share the same mechanism: Mastodon's server needs to crawl your page. I took me about 20 minutes of chatting with Claude Code to solve the three above issues, by solving the card preview one. The key was to understand that since the newsletter card preview worked, my blog wasn't at fault. Claude Code checked the response headers and understood the following.

My blog runs behind Cloudflare. I had enabled Bot Fight Mode, a Cloudflare feature that blocks automated traffic it deems suspicious. Services can register domains on Cloudflare to be recognized as good actors. In fact, Bluesky and Twitter have done it.

However, Mastodon was betrayed by its decentralized nature. Each Mastodon instance runs a specific domain; mine is https://mastodon.top. mastodon.top's crawler runs on Hetzner infrastructure. Hetzner IP addresses carry a high threat score in Cloudflare's database — they're a popular choice with bot operators.

When Mastodon's crawler tried to fetch my pages, Cloudflare served it a JavaScript challenge instead of HTML. Mastodon's http.rb client can't solve JavaScript challenges. It got no useful response, cached the failure, and moved on.

The fix: turn off Bot Fight Mode in Security > Bots in the Cloudflare dashboard.

Conclusion

This is a well-known issue in both the Mastodon and Cloudflare communities. For a public static blog, Bot Fight Mode offers minimal protection while actively breaking legitimate crawlers. Turning it off fixed all three Mastodon issues at once.

To go further:

Originally published at A Java Geek on April 26^th, 2026.