DEV Community: LakBud

Thanks for 1,000+ downloads! VernLLM v1.0.0 is here

LakBud — Fri, 24 Jul 2026 14:04:11 +0000

Thanks for 1,000+ downloads! VernLLM just hit v1.0.0, and it comes with one breaking change worth knowing about if you're using a custom cache adapter, plus a handful of smaller improvements that landed alongside it.

What is VernLLM?

VernLLM is a lightweight resilience layer for LLM chat completions: retries, timeouts, caching, circuit breaking, structured output, and usage tracking. All behind one typed interface, with adapters for OpenAI-compatible providers (OpenAI, Groq, Mistral, DeepSeek, Cerebras, Together AI, Fireworks, Ollama), plus Anthropic, Gemini, and AWS Bedrock.

import OpenAI from 'openai';
import { VernLLM } from 'vern-llm';

const llm = new VernLLM({
  client: new OpenAI({ apiKey: process.env.OPENAI_API_KEY }),
  model: 'gpt-4o',
  maxRetries: 3,
  timeoutMs: 10_000,
  circuitBreaker: true,
});

const result = await llm.call({
  systemPrompt: 'Return JSON: { "skills": string[] }',
  userContent: 'Extract skills from: ...',
});

The breaking change: `CacheAdapter.get()`

Previously, CacheAdapter.get() returned Promise<T | null>. The problem: there was no way to tell the difference between "nothing is cached for this key" and "the cached value legitimately is null." Both looked identical, so a real null result got treated as a cache miss and silently re-triggered another LLM call every time.

In v1.0.0, get() now returns:

Promise<{ hit: boolean; value: T | null }>

hit reflects whether the key existed in the underlying store, independent of what the value was. { hit: true, value: null } means "we have a cached result, and it's null." { hit: false, value: null } means "nothing is cached."

If you're using the built-in InMemoryCacheAdapter, you don't need to do anything, it's already updated.

If you've written a custom adapter (Redis, Upstash, etc.), you'll need to update get():

// Before
async get(key: string): Promise<MyValue | null> {
  const raw = await redis.get(key);
  return raw ? JSON.parse(raw) : null;
}

// After
async get(key: string): Promise<{ hit: boolean; value: MyValue | null }> {
  const raw = await redis.get(key);

  if (raw === null) {
    return { hit: false, value: null };
  }

  return { hit: true, value: JSON.parse(raw) };
}

Most stores already give you this signal for free — Redis's GET returning null for "key doesn't exist" is distinguishable from a null you stored yourself, so the fix is usually just an existence check rather than a value !== null check.

If you'd rather not bother with the distinction and are fine with null results never being served from cache, there's also a one-line shim:

return { hit: value !== null, value };

Also in this release

CallParams.systemPrompt is now optional — omit it and no system message is sent at all, instead of forcing an empty string through.
AnthropicClient, GeminiClient, and BedrockConverseClient are now exported as public types, so you can type your own client instances against them without reaching into internals.
New adapters barrel export — import { fromAnthropic, fromGemini, fromBedrock, fromFetch, fromOpenAICompatible } from 'vern-llm/adapters' instead of digging through individual files.
In-memory cache now has a size limit to prevent unbounded growth, evicting the oldest entries once the limit is hit.
Internal types got refactored into focused modules, and test coverage was extended for optional system prompts, adapter payloads, and cache adapter edge cases (custom adapters, size bounds, failure handling).

Upgrading

npm install vern-llm@latest

If you're only using the built-in InMemoryCacheAdapter (the default), this is a drop-in upgrade. If you've implemented a custom CacheAdapter, update its get() method per the migration guide above before upgrading in production.

Full changelog and docs: vernllm.vercel.app · GitHub

Thanks for using VernLLM, and for the 1,000+ downloads. If you hit any issues with the migration, open an issue on GitHub.

[Boost]

LakBud — Tue, 21 Jul 2026 00:05:36 +0000

LakBud

Jul 20

VernLLM - lightweight resilience layer for LLM Applications

#showdev #opensource #ai #webdev

2 min read

VernLLM - lightweight resilience layer for LLM Applications

LakBud — Mon, 20 Jul 2026 21:20:29 +0000

Introducing vernLLM: A Resilience Layer for LLM Applications

Building production-ready LLM applications is not just about sending prompts and receiving responses. Real-world AI systems need to handle timeouts, provider failures, rate limits, inconsistent outputs, and reliability issues.

That is where vernLLM comes in.

vernLLM is a lightweight resilience layer for OpenAI-compatible chat completion APIs, providing a single interface with built-in retries, timeouts, circuit breaking, caching, structured output, and usage tracking.

Instead of rebuilding the same reliability features for every LLM project, vernLLM gives you the tools needed to make your AI integrations more robust from the start.

Features

Automatic retries with backoff

Transient failures happen. vernLLM automatically retries recoverable errors while failing fast on validation errors and non-retryable responses.

Timeouts & cancellation

Prevent hanging requests with configurable timeouts and cancellation support.

Circuit breaker protection

Automatically stop sending requests to failing providers and recover when the service becomes healthy again.

Structured output with type safety

Pass a Zod schema and receive validated, typed results back.

const result = await llm.call({
  systemPrompt: 'Return JSON: { "skills": string[] }',
  userContent: 'Extract skills from: ...',
  schema: SkillsSchema // zod schema
});

Provider-native JSON Schema support

Constrain model generation itself instead of only validating responses afterward.

Built-in caching support

Cache LLM responses using your own cache adapter with cachedCall and cachedLLMCall.

One interface across providers

Use the same API across multiple providers:

OpenAI
Groq
Mistral
DeepSeek
Cerebras
Together AI
Fireworks AI
Ollama
Anthropic
Gemini
AWS Bedrock
Any HTTP-compatible provider through fromFetch

Why vernLLM?

Many LLM applications end up creating their own wrappers around provider SDKs to handle:

retry logic
API failures
provider switching
response validation
caching
monitoring

vernLLM packages these patterns into a reusable, lightweight library so developers can focus on building AI features instead of maintaining infrastructure.

Quick Start

Install:

pnpm add vern-llm openai

Create your client:

import OpenAI from 'openai';
import { VernLLM } from 'vern-llm';

export const llm = new VernLLM({
  client: new OpenAI({ apiKey: process.env.OPENAI_API_KEY }),
  model: 'gpt-4o',

  maxRetries: 3,
  timeoutMs: 10_000,
  circuitBreaker: true,

  onUsage: ({ totalTokens }) => {
    console.log(`Used ${totalTokens} tokens`);
  },
});


// now do something with it!
export const summary = await llm.cachedLLMCall({
  cacheKey: `resume:${resumeId}`,
  ttl: 3600,
  call: {
    systemPrompt: 'Analyze this resume and return structured hiring insights.',
    userContent: resumeText,
    schema: HiringSummarySchema, // Zod schema
  }
});

Built for Production

vernLLM is designed with production usage in mind:

Zero bundled dependencies
TypeScript-first API
Provider adapters
Extensive test coverage
MIT licensed

Whether you are building AI agents, document processing pipelines, chat applications, or LLM-powered tools, vernLLM provides the reliability layer needed to ship with confidence.

Learn More

Documentation: https://vernllm.vercel.app/

GitHub: https://github.com/LakBud/vernLLM

Contributions, feedback, and ideas are welcome!

DEV Community: LakBud

Thanks for 1,000+ downloads! VernLLM v1.0.0 is here

What is VernLLM?

The breaking change: CacheAdapter.get()

Also in this release

Upgrading

[Boost]

VernLLM - lightweight resilience layer for LLM Applications

VernLLM - lightweight resilience layer for LLM Applications

Introducing vernLLM: A Resilience Layer for LLM Applications

Features

Automatic retries with backoff

Timeouts & cancellation

Circuit breaker protection

Structured output with type safety

Provider-native JSON Schema support

Built-in caching support

One interface across providers

Why vernLLM?

Quick Start

Built for Production

Learn More

The breaking change: `CacheAdapter.get()`