open-index/open-npm huggingface dataset:
npm package: @krugle/llm-info
Description: A lightweight package providing information about various Large Language Models (LLMs), including embedding, reranking, and other models.
Author: Jason Williams
Latest version: 0.6.10

# @krugle/llm-info

A lightweight package providing information about various Large Language Models (LLMs), including embedding, reranking, and other models.

Whereas @krugle/openai-adapters is responsible for translation between API types, @krugle/llm-info is concerned with

- Templates
- Capabilities (e.g. tools, images, streaming, predicted outputs, etc.)
- Model aliases

and openai-adapters might depend on llm-info for some of these things.

### Goal

We know we are done when the steps required to add support for a new model in Klip are exactly

1. editing a single LlmInfo object, and
2. adding it to the supporting ModelProviders.

### Code structure

The two primary types are LlmInfo and ModelProvider

Models are defined on their own in the `models` directory. They can be grouped however makes sense.

Providers are defined in the `providers` directory, with all models that they support in their `models` attribute. It's important that models are tied to providers, because the model might have slightly different attributes (e.g. context length) per provider. Define as much as possible in the base object, and then spread to update for the specific providers as needed.

### Where to use llm-info

- Replace autodetect.ts
- See usage in `BaseLLM` constructor, and finish the job of using llm-info everywhere relevant.
- Replace `gui/pages/AddNewModel/configs/[providers/models].ts`
npm package: @krugle/openai-adapters
Description: OpenAI adapters convert an OpenAI-compatible request to a request for another API and back.
Author: Jason Williams
Latest version: 0.6.10

# OpenAI Adapters

OpenAI adapters convert an OpenAI-compatible request to a request for another API and back.

They are purely a translation layer, and are not concerned with:

- Templates
- Whether a model supports tools, images, etc.
- Dynamically changing API base for model
- Keeping track of system message (it will always be the first message with a systemMesage)
- Keeping a private variable with anything that is already passed through the OpenAI request body
- Appending "/" to the apiBase (but this is TODO)
- Batching embeddings (yes, it requires some knowledge of max batch size, but it's more important to maintain 1 req = 1 req)
- Using streamChat for streamComplete and vice-versa if one isn't defined

The goal is for this to change as infrequently as possible. It should only require updating when the actual API format changes.

They are concerned with:

- Converting model aliases
- Cache behavior
- max stop words
- use legacy completions endpoint?
- anything else that couldn't possibly be guess by the client since it won't know the endpoint behind the proxy

## Supported APIs

- [x] Anthropic
- [ ] AskSage
- [x] Azure
- [ ] Bedrock
- [ ] Bedrock Import
- [x] Cerebras
- [ ] Cloudflare
- [x] Cohere
- [x] DeepInfra
- [x] Deepseek
- [ ] Flowise
- [x] Function Network
- [x] Gemini
- [x] Groq
- [ ] HuggingFace Inference API
- [ ] HuggingFace TGI
- [x] Kindo
- [x] LMStudio
- [x] LlamaCpp
- [x] Llamafile
- [x] Msty
- [x] Mistral
- [x] Nvidia
- [x] Nebius
- [x] OpenRouter
- [x] OpenAI
- [ ] !Ollama
- [ ] Replicate
- [ ] SageMaker
- [x] SambaNova
- [x] Scaleway
- [ ] Silicon Flow
- [x] TextGen Web UI
- [x] Together
- [x] Novita AI
- [x] Vllm
- [ ] Vertex AI
- [x] Voyage AI
- [ ] WatsonX
- [x] xAI
- [x] Fireworks
- [x] Moonshot