// portability

Switch providers,
not your stack.

Helmcode should make open models easier to operate. It shouldn't become another dependency you can't replace.

Build your application against a standard interface, keep models interchangeable and decide where inference runs as your requirements change.

// architecture

The application stays. The layer under it can change.

Where the interface is a standard one, the provider sits in configuration rather than in the code. Different providers still behave differently, which is what the migration section below is about.

Stays put

Your application
OpenAI-compatible interface

Can change

Today

Helmcode

If requirements change

Another inference provider
Open model

Infrastructure

  • Managed
  • Dedicated
  • On-premise

// three layers

Portability has three layers.

They are worth separating, because they fail separately. An application can be portable at the interface and still be pinned by a model nobody else serves.

  1. 01 Interface

    Keep the application separated from the provider.

    Helmcode uses an OpenAI-compatible API so applications and tools can connect through an interface already widely supported across the AI ecosystem.

    Changing inference infrastructure should not require rewriting the entire application layer.

    • OpenAI-compatible API
    • Standard SDKs
    • Configurable endpoint
    client.py
    from openai import OpenAI
    
    client = OpenAI(
        base_url=INFERENCE_BASE_URL,
        api_key=INFERENCE_API_KEY,
    )

    The value the application reads is a variable. Which provider it points at is a deployment decision, not a code change.

      Today With Helmcode
    INFERENCE_BASE_URL Your current provider's endpoint https://api.helmcode.com/v1
    INFERENCE_API_KEY Your current provider's key Your Helmcode key
  2. 02 Model

    The open model isn't owned by Helmcode.

    Helmcode operates open models. The underlying models exist independently of Helmcode and, where the relevant weights and licence allow it, can be served by other infrastructure.

    Today
    1. Application
    2. Helmcode
    3. Open model
    If requirements change
    1. Application
    2. Another inference provider
    3. Same open model
    Or
    1. Application
    2. Your infrastructure
    3. Same open model
  3. 03 Infrastructure

    Choose where inference runs.

    The same application architecture can support different infrastructure decisions over time.

    Managed
    Helmcode operates inference.
    Dedicated
    Reserved infrastructure for workloads requiring additional isolation or predictable capacity.
    On-premise
    Inference runs inside infrastructure controlled by the organisation.

    The right answer can change as the workload changes.

// migration

What changes when you switch provider?

All of it, honestly. This is the list a team should price before treating portability as free.

  1. Endpoint and authentication The API endpoint and credentials will change.
  2. Model availability The exact checkpoint must be available on the destination infrastructure.
  3. Quantisation Different serving configurations can affect model behaviour and performance.
  4. Context limits Providers may expose different effective context windows.
  5. Tooling and features Tool calling, structured outputs, multimodality and other capabilities may differ.
  6. Latency and throughput Hardware and serving architecture affect performance.
  7. Evaluation The workload should be re-evaluated before production traffic moves.

Keep the option to choose again.

Use Helmcode where it makes sense today.

Keep the architecture flexible enough to choose differently tomorrow.

Talk to us about your workload

// direct line

Questions about any of this?

Write to Pedro. He handles enterprise evaluations and answers the technical, security and commercial questions himself.

// get started

START BURNING TOKENS

Skip the AI infra work. Deploy your first private inference endpoint today.

Flat rate. EU data. OpenAI API compatible.