I made my .NET travel AI library work with OpenAI, Anthropic, Ollama, and Azure. Not just one.

#dotnet #claude #ai #productivity

When I first shipped TravelAI.Core, it only worked with Azure OpenAI and Azure AI Search. You needed an Azure subscription, a deployed GPT-4o model, a configured AI Search index, and the patience to wire it all up before you could generate a single itinerary.

Downloads were slow. Not surprising in hindsight.

Most developers don't have Azure credentials sitting around. They want to try something before committing to a cloud provider. I was basically asking people to do significant setup work before they could see if the library was even useful to them.

So I rebuilt the provider layer.

What changed

The core interfaces stayed exactly the same. IItineraryGenerationService, IDestinationSearchService, IPriceAnomalyDetector all look identical from the outside. What changed is how you wire up the backend.

In v1.0.0 you needed a config section with Azure credentials. In v2.0.0 you pick a provider:

builder.Services.AddTravelAI(options => options.UseMock());
builder.Services.AddTravelAI(options => options.UseOpenAI("sk-..."));
builder.Services.AddTravelAI(options => options.UseAnthropic("sk-ant-..."));
builder.Services.AddTravelAI(options => options.UseOllama("http://localhost:11434"));
builder.Services.AddTravelAI(options => options.UseAzureOpenAI("endpoint", "key", "gpt-4o"));

The mock provider is the one I'm most pleased with. Zero credentials, works offline, returns a realistic 3-day Rome itinerary with activities, costs, and timing. You can build and test the full integration flow on a train with no internet.

How the abstraction works

There's a single ILlmProvider interface:

public interface ILlmProvider
{
    Task<string> GenerateAsync(
        string systemPrompt,
        string userPrompt,
        CancellationToken ct = default);
}

Each provider implements it. ItineraryGenerationService now takes ILlmProvider instead of AzureOpenAIClient. The Anthropic adapter uses Anthropic.SDK, the Ollama adapter makes raw HTTP calls to /api/chat, the mock just returns a hardcoded JSON string.

The destination search side has a mock too. MockDestinationSearchService does keyword scoring in memory against five curated destinations. Good enough to build against while you decide whether you want Azure AI Search or something else.

The Ollama adapter

Ollama's API is simple but you're dealing with streaming responses and the JSON format varies slightly across model versions. I went with a non-streaming request to keep the adapter stateless, which works fine for itinerary generation.

var response = await _http.PostAsJsonAsync("/api/chat", new
{
    model = _model,
    stream = false,
    messages = new[]
    {
        new { role = "system", content = systemPrompt },
        new { role = "user", content = userPrompt }
    }
});

Nothing clever. Just works.

What the library does

Four things once registered:

Itinerary generation takes a traveller profile and destination and returns a structured day-by-day plan with activities and cost estimates. Price anomaly detection analyses flight options against historical baselines and flags anything unusual. Destination search understands natural language queries like "warm with beaches and local food, not too touristy". Booking automation runs the end-to-end flow with retry logic and rollback on failure.

The whole thing is deployed to Azure Kubernetes Service. The GitHub Actions pipeline builds for linux/arm64, pushes to GHCR, and deploys with a manual approval gate. Took me a while to figure out the arm64 part.