LoRA Adapters

A LoRA adapter specialises a base model without swapping it out. Apply one, generate, remove it. The base model stays loaded throughout, so switching behaviour costs far less than switching models.

await RunAnywhere.lora.apply('legal-summarizer')

const result = await RunAnywhere.llm.generate('Summarize this clause: …')

await RunAnywhere.lora.remove('legal-summarizer')

The namespace

lora.apply(adapterId: string, scale?: number): Promise<void>
lora.remove(adapterId: string | null): Promise<void>
lora.removeAll(): Promise<void>
lora.list(): Promise<LoraState>

Scale

scale controls how strongly the adapter pulls the base model. Leave it unset for the adapter’s own default. Lower values blend the adapter with base behaviour; higher values commit to it. If output degrades after applying an adapter, scale is the first thing to turn down.

Removing

await RunAnywhere.lora.remove('legal-summarizer')
await RunAnywhere.lora.removeAll()

Removal is keyed by adapter id.

Switching adapters

Adapters stack. Remove before applying another, or two of them fight and the output is worse than either alone.

The base model has to support it

An adapter is trained against a specific base model. Applying one to a different base either fails or produces nonsense. Check the model’s supportsLora flag before offering adapters in your interface. Web exposes the short form only. Catalog management is available on the Swift and Electron SDKs. Adapters are small compared with the base model, often a few megabytes, which makes them a practical way to ship several behaviours in a browser without several downloads.

Getting Started

Swift SDK

Kotlin SDK

React Native SDK

Flutter SDK

Web SDK

Electron SDK

Vibe Coding

The namespace

Scale

Removing

Switching adapters

The base model has to support it

​The namespace

​Scale

​Removing

​Switching adapters

​The base model has to support it

The namespace

Scale

Removing

Switching adapters

The base model has to support it