DEV Community

Cover image for Compile Once, Run Anywhere: Supporting Multiple LLM Providers
PRANAV THAWAIT
PRANAV THAWAIT

Posted on

Compile Once, Run Anywhere: Supporting Multiple LLM Providers

#ai #webdev #promptengineering #typescript

Compile Once, Run Anywhere: Supporting Multiple LLM Providers

One of the biggest challenges in AI development isn't writing prompts.

It's maintaining them across multiple providers.

Today you might use:

  • OpenAI
  • Anthropic Claude
  • Google Gemini
  • Ollama
  • Groq
  • Mistral

Tomorrow?

Maybe a completely different model.

The problem isn't the prompt itself.

It's that every provider expects a slightly different format.

The Reality Today

Suppose you have a simple assistant.

For OpenAI, your request looks like this.

messages: [

  {
    role: "system",
    content: "You are an expert assistant."
  },

  {
    role: "user",
    content: question
  }

]
Enter fullscreen mode Exit fullscreen mode

Looks straightforward.

Now switch to another provider.

Suddenly you have to rewrite your message format.

Multiply that across every prompt in your project...

...and switching providers becomes expensive.

Vendor Lock-In

Most AI applications don't intentionally become locked to one provider.

It happens gradually.

You start with OpenAI.

Months later your company wants to compare Claude.

Or Gemini.

Or run locally with Ollama.

Now every prompt needs changes.

Not because your instructions changed...

...but because the payload did.

The Prompt Isn't the Problem

The actual prompt rarely changes.

This doesn't.

You are an expert software engineer.

Review this code.

Return JSON.
Enter fullscreen mode Exit fullscreen mode

Only the transport layer changes.

Which means...

Your prompt definition shouldn't know anything about OpenAI.

Separate Intent from Implementation

Instead of defining provider payloads...

Define your intent.

const reviewPrompt = pf.define({

    input: z.object({

        code: z.string()

    }),

    messages: ({ code }) => [

        pf.system`
        You are a Senior Security Engineer.
        `,

        pf.user`
        Review this code.

        ${code}
        `

    ]

})
Enter fullscreen mode Exit fullscreen mode

Notice something?

There's no OpenAI.

No Claude.

No Gemini.

Just the prompt.

Compile It

Now compile for the provider you need.

const compiled = reviewPrompt.compile({

    code

})
Enter fullscreen mode Exit fullscreen mode

From there...

compiled.toOpenAI()

compiled.toAnthropic()

compiled.toGemini()

compiled.toOllama()
Enter fullscreen mode Exit fullscreen mode

One prompt.

Multiple providers.

Why Compilation Matters

Think of TypeScript.

You don't write JavaScript directly.

You write TypeScript.

Then compile.

PromptForge follows the same philosophy.

Prompt Definition

↓

Validation

↓

Compilation

↓

Provider Format
Enter fullscreen mode Exit fullscreen mode

The prompt stays consistent.

Only the output changes.

Easier Provider Testing

Imagine comparing GPT-4o with Claude.

Without PromptForge

Prompt A

↓

Rewrite

↓

Claude
Enter fullscreen mode Exit fullscreen mode

With PromptForge

Prompt

↓

OpenAI

Claude

Gemini

Ollama
Enter fullscreen mode Exit fullscreen mode

Exactly the same prompt.

Fair comparison.

Cleaner Architecture

Instead of

openai.ts

claude.ts

gemini.ts
Enter fullscreen mode Exit fullscreen mode

containing duplicated prompts...

Your project becomes

prompts/

review.ts

summary.ts

translation.ts

↓

compiler

↓

provider adapters
Enter fullscreen mode Exit fullscreen mode

Much easier to maintain.

Future-Proof

The AI ecosystem changes every month.

New providers appear.

APIs evolve.

Models improve.

Your prompts shouldn't have to change every time.

PromptForge keeps your prompt definitions stable while adapters handle provider-specific differences.

Why This Matters

Prompt engineering shouldn't be tied to one company.

Your prompts are your intellectual property.

They should outlive whichever model happens to be popular today.

That's why PromptForge is designed around provider independence.

Write your prompt once.

Compile it anywhere.

Looking Ahead

Supporting multiple providers is only part of the story.

The next challenge is making sure your prompts are actually correct before you send them to an LLM.

In the next article, we'll explore Prompt Validation and see how catching errors before an API call can save both time and tokens.

Installation 

npm install @promptforgee/core
Enter fullscreen mode Exit fullscreen mode

Resources

🌐 Documentation

https://prompt-forge-docs.vercel.app/

⭐ GitHub

https://github.com/Omnikon-Org/PromptForge

📦 npm

https://www.npmjs.com/package/@promptforgee/core

Final Thoughts

Frameworks come and go.

Models come and go.

Providers come and go.

Your prompts shouldn't have to.

PromptForge separates prompt design from provider implementation so you can focus on building AI applications—not rewriting payloads every time the ecosystem changes.

Top comments (0)