agnostisk. dk

Agnostisk.dk is about technical freedom of movement. Vendor-agnostic. Database-agnostic. Library-agnostic. Tool-agnostic. LLM-agnostic. Harness-agnostic. Infra-agnostic. The list could go on. Being fully invested in something is great, as long as you can leave when you want.

The blinking endings are the point. You can use a technology very intensely without wanting to build your whole system around it. This is about building escape hatches into every brick of the stack from the start. The real lock-in is rarely just the model. It lives in the surrounding layer: context, knowledge, ontology, the agent toolbox, and the integrations. Agnostisk.dk is less about being able to switch from Opus to GPT, but explains how to be a digital nomad in the lands of LLMs.

This is not anti-big tech. Quite the opposite. The frontier agents become more useful when they are part of a setup with real optionality around them.

Disclosure: Agnostisk.dk doesn't sell anything. It's a presentation layer of thoughts around agentic engineering and related concepts.

Claude Code CPH

The talk

A practical example of model-agnostic coding

How I switch between Claude, Codex, and Qwen on a DGX Spark without rebuilding the agentic setup each time.

The point is not to collect interfaces. The point is to build one working layer that can move between them. I want to show a concrete setup where the repo, the tools, and the expectations stay stable while the model backend can change.

Same repo

The work stays in the same project, not in three different workflows.

Same toolbox

Rules, tools, and prompt conventions live in one shared layer.

Three backends

Claude, Codex, and local Qwen are choices, not separate worlds.

Claude Code CPH

The build

How the toolbox is wired

The stable layer sits in the middle. Interfaces sit above it. Model backends sit below it.

Claude Code

Codex

Local shell

Shared layer

fhh-toolkit

Rules and prompts

Tools and plugins

Adapters and setup

Shared working patterns

`fos` consumes this layer instead of reinventing it per model.

Claude hosted

Codex hosted

Qwen on Spark local

Claude Code CPH

The switch

What actually changes when I switch model

The backend changes. The surrounding working method does not.

Claude

I use it when I want the strongest hosted coding experience and long-form reasoning inside Claude Code.

Codex

I use it when I want the same repo flow through a second provider and a different coding surface.

Qwen on DGX Spark

I use it when the work should stay local or when I want a private fallback that I control myself.

What stays the same

Repo structure, tool access, prompt rules, expected output shape, and the way I evaluate the result.

What changes

The backend, the privacy boundary, the cost profile, and sometimes the interface I choose to work in.

Hosted

Claude and Codex give me provider choice without changing the repo setup.

Local

Qwen on Spark gives me a private path when the work should stay on the machine.

Practical point

The model stops being the whole workflow and becomes one component in it.