Multimodal Embedding & Reranker Models with Sentence Transformers

Sentence Transformers is a Python library for using and training embedding and reranker models for applications like retrieval augmented generation, semantic search, and more. With the v5.4 update, you can now encode and compare texts, images, audio, and videos using the same familiar API. In this blogpost, I'll show you how to use these new multimodal capabilities for both embedding and reranking.

Multimodal embedding models map inputs from different modalities into a shared embedding space, while multimodal reranker models score the relevance of mixed-modality pairs. This opens up use cases like visual document retrieval, cross-modal search, and multimodal RAG pipelines.

Table of Contents

• What are Multimodal Models?
• Installation
• Multimodal Embedding Models
• Loading a Model
• Encoding Images
• Cross-Modal Similarity
• Encoding Queries and Documents
• Multimodal Reranker Models
• Ranking Mixed-Modality Documents
• Predicting Pair Scores
• Retrieve and Rerank
• Input Formats and Configuration
• Supported Input Types
• Checking Modality Support
• Processor and Model kwargs
• Supported Models
• Additional Resources

What are Multimodal Models?

Traditional embedding models convert text into fixed-size vectors. Multimodal embedding models extend this by mapping inputs from different modalities (text, images, audio, or video) into a shared embedding space. This means you can compare a text query against image documents (or vice versa) using the same similarity functions you're already familiar with.

Similarly, traditional reranker (Cross Encoder) models compute relevance scores between pairs of texts. Multimodal rerankers can score pairs where one or both elements are images, combined text-image documents, or other modalities.

For example, you can compare a text query against image documents, find video clips matching a description, or build RAG pipelines that work across modalities.

Installation

Multimodal models require some extra dependencies. Install the extras for the modalities you need (see Installation for more details):

# For image support
pip install -U "sentence-transformers[image]"

# For audio support
pip install -U "sentence-transformers"

# For video support
pip install -U "sentence-transformers"

# Mix and match as needed
pip install -U "sentence-transformers[image,video,train]"

VLM-based models like Qwen3-VL-2B require a GPU with at least ~8 GB of VRAM. For the 8B variants, expect ~20 GB. If you don't have a local GPU, consider using a cloud GPU service or Google Colab. On CPU, these models will be extremely slow; text-only or CLIP models are better suited for CPU inference.

Multimodal Embedding Models

Loading a Model

Loading a multimodal embedding model works exactly like loading a text-only model:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

The revision argument is required for now because the integration pull requests for these models are still pending. Once they're merged, you'll be able to load them without specifying a revision.

The model automatically detects which modalities it supports, so there's nothing extra to configure. See Processor and Model kwargs if you want to control things like image resolution or model precision.

Encoding Images

With a multimodal model loaded, model.encode() accepts images alongside text. Images can be provided as URLs, local file paths, or PIL Image objects (see Supported Input Types for all accepted formats):

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

# Encode images from URLs
img_embeddings = model.encode([
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg",
])
print(img_embeddings.shape)
# (2, 2048)

Cross-Modal Similarity

You can compute similarities between text embeddings and image embeddings, since the model maps both into the same space:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

# Encode images
img_embeddings = model.encode([
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg",
])

# Encode text queries (one matching + one hard negative per image)
text_embeddings = model.encode([
 "A green car parked in front of a yellow building",
 "A red car driving on a highway",
 "A bee on a pink flower",
 "A wasp on a wooden table",
])

# Compute cross-modal similarities
similarities = model.similarity(text_embeddings, img_embeddings)
print(similarities)
# tensor([[0.5115, 0.1078],
# [0.1999, 0.1108],
# [0.1255, 0.6749],
# [0.1283, 0.2704]])

As expected, "A green car parked in front of a yellow building" is most similar to the car image (0.51), and "A bee on a pink flower" is most similar to the bee image (0.67). The hard negatives ("A red car driving on a highway", "A wasp on a wooden table") correctly receive lower scores.

You might notice that even the best matching scores (0.51, 0.67) aren't very close to 1.0. This is due to the modality gap: embeddings from different modalities tend to cluster in separate regions of the space. Cross-modal similarities are typically lower than within-modal ones (e.g., text-to-text), but the relative ordering is preserved, so retrieval still works well.

Encoding Queries and Documents

For retrieval tasks, encode_query() and encode_document() are the recommended methods. Many retrieval models prepend different instruction prompts depending on whether the input is a query or a document, similar to how chat models might apply different system prompts depending on the goal. Model authors can specify their prompts in the model config, and encode_query() / encode_document() automatically load and apply the correct one:

• encode_query() uses the model's "query" prompt (if available) and sets task="query".
• encode_document() uses the first available prompt from "document", "passage", or "corpus", and sets task="document".

Under the hood, both are thin wrappers around encode(), they just handle prompt selection for you. Here's what cross-modal retrieval looks like:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

# Encode text queries with the query prompt
query_embeddings = model.encode_query([
 "Find me a photo of a vehicle parked near a building",
 "Show me an image of a pollinating insect",
])

# Encode document screenshots with the document prompt
doc_embeddings = model.encode_document([
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg",
])

# Compute similarities
similarities = model.similarity(query_embeddings, doc_embeddings)
print(similarities)
# tensor([[0.3907, 0.1490],
# [0.1235, 0.4872]])

These methods accept the same input types as encode() (images, URLs, multimodal dicts, etc.) and pass through the same parameters. For models without specialized query/document prompts, they behave identically to encode().

Multimodal Reranker Models

Multimodal reranker (CrossEncoder) models score the relevance between pairs of inputs, where each element can be text, an image, audio, video, or a combination. They tend to outperform embedding models in terms of quality, but are slower since they process each pair individually. The currently available pretrained multimodal rerankers focus on text and image inputs, but the architecture supports any modality that the underlying model can handle.

Ranking Mixed-Modality Documents

The rank() method scores and ranks a list of documents against a query, supporting mixed modalities:

from sentence_transformers import CrossEncoder

model = CrossEncoder("Qwen/Qwen3-VL-Reranker-2B", revision="refs/pr/11")

query = "A green car parked in front of a yellow building"
documents = [
 # Image documents (URL or local file path)
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg",
 # Text document
 "A vintage Volkswagen Beetle painted in bright green sits in a driveway.",
 # Combined text + image document
 {
 "text": "A car in a European city",
 "image": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 },
]

rankings = model.rank(query, documents)
for rank in rankings:
 print(f"{rank['score']:.4f}\t(document {rank['corpus_id']})")
"""
0.9375 (document 0)
0.5000 (document 3)
-1.2500 (document 2)
-2.4375 (document 1)
"""

The reranker correctly identifies the car image (document 0) as the most relevant result, followed by the combined text+image document about a car in a European city (document 3). The bee image (document 1) scores lowest.

Keep in mind that the modality gap can influence absolute scores: text-image pair scores may occupy a different range than text-text or image-image pair scores.

You can also check which modalities a reranker supports using modalities and supports(), just like with embedding models:

print(model.modalities)
# ['text', 'image', 'video', 'message']

print(model.supports("image"))
# True

# Check if the model supports a specific pair of modalities
print(model.supports(("image", "text")))
# True

Predicting Pair Scores

You can also use predict() to get raw relevance scores for specific pairs of inputs:

from sentence_transformers import CrossEncoder

model = CrossEncoder("jinaai/jina-reranker-m0", trust_remote_code=True)

scores = model.predict([
 ("A green car", "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg"),
 ("A bee on a flower", "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg"),
 ("A green car", "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/bee.jpg"),
])
print(scores)
# [0.9389156 0.96922314 0.46063158]

Retrieve and Rerank

A common pattern is to use an embedding model for fast initial retrieval, then refine the top results with a reranker:

from sentence_transformers import SentenceTransformer, CrossEncoder

# Step 1: Retrieve with an embedding model
embedder = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

query = "revenue growth chart"
query_embedding = embedder.encode_query(query)

# Pre-compute corpus embeddings (do this once, then store them)
document_screenshots = [
 "path/to/doc1.png",
 "path/to/doc2.png",
 # ... potentially millions of document screenshots
]
corpus_embeddings = embedder.encode_document(document_screenshots, show_progress_bar=True)

# Simple cosine similarity retrieval, viable as long as embeddings fit in memory
similarities = embedder.similarity(query_embedding, corpus_embeddings)
top_k_indices = similarities.argsort(descending=True)[0][:10]

# Step 2: Rerank the top-k results with a reranker model
reranker = CrossEncoder("nvidia/llama-nemotron-rerank-vl-1b-v2", trust_remote_code=True)

top_k_documents = [document_screenshots[i] for i in top_k_indices]
rankings = reranker.rank(query, top_k_documents)
for rank in rankings:
 print(f"{rank['score']:.4f}\t{top_k_documents[rank['corpus_id']]}")

Since the corpus embeddings are pre-computed, the initial retrieval is fast even over millions of documents. The reranker then provides more accurate scoring over the smaller candidate set.

Input Formats and Configuration

Supported Input Types

Multimodal models accept a variety of input formats. Here's a summary of what you can pass to model.encode():

Checking Modality Support

You can check which modalities a model supports using the modalities property and supports() method:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("Qwen/Qwen3-VL-Embedding-2B", revision="refs/pr/23")

# List all supported modalities
print(model.modalities)
# ['text', 'image', 'video', 'message']

# Check for a specific modality
print(model.supports("image"))
# True
print(model.supports("audio"))
# False

The "message" modality indicates that the model accepts chat-style message inputs with interleaved content. In practice, you rarely need to use this directly. When you pass strings, URLs, or multimodal dicts, the model converts them to the appropriate message format internally. Sentence Transformers supports two message formats:

1. Structured (most VLMs, e.g. Qwen3-VL): Content is a list of typed dicts, e.g. [{"type": "text", "text": "..."}, {"type": "image", "image": ...}]
2. Flat (e.g. Deepseek-V3): Content is a direct value, e.g. "some text"

The format is auto-detected from the model's chat template.

Since all inputs get converted into the same message format internally, you can mix input types in a single encode() call:

embeddings = model.encode([
 # A text input
 "A green car parked in front of a yellow building",
 # An image input (URL)
 "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 # A combined text + image input
 {
 "text": "A car in a European city",
 "image": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/tasks/car.jpg",
 },
])

Processor and Model kwargs

You may want to control image resolution bounds or model precision. Use processor_kwargs and model_kwargs when loading the model:

model = SentenceTransformer(
 "Qwen/Qwen3-VL-Embedding-2B",
 model_kwargs={"attn_implementation": "flash_attention_2", "torch_dtype": "bfloat16"},
 processor_kwargs={"min_pixels": 28 * 28, "max_pixels": 600 * 600},
 revision="refs/pr/23",
)

processor_kwargs controls how inputs are preprocessed (e.g., image resolution bounds). Higher max_pixels means higher quality but more memory and compute. These are

The post Multimodal Embedding & Reranker Models with Sentence Transformers first appeared on Hard Wired.

Průvodce modely Claude od Anthropic

Úvod

Anthropic je americká firma, která se zabývá vývojem bezpečné AI - jejich hlavní produkt je rodina jazykových modelů Claude, v současnosti jedny z nejpokročilejších AI asistentů na trhu, které mají tři hlavní úrovně: Opus, Sonnet a Haiku. Když jsem poprvé začal s těmito modely pracovat, upřímně jsem nevěděl který kdy použít - všechny vypadaly podobně, ale rozdíly v kvalitě výstupu a ceně byly obrovské. V tomhle článku si projdeme co který model umí, kdy ho použít a proč, a sdílím zkušenosti z reálných projektů kde jsem každý z nich testoval.

Architektura rodiny Claude

Anthropic postavil třístupňovou hierarchii modelů, kde každá úroveň má svoje místo:

Všechny modely používají Constitutional AI framework pro bezpečnost a mají kontextové okno 200 000 tokenů (zhruba 150 000 slov), což v praxi znamená že můžeš nahrát celou kódovou bázi menšího projektu nebo technickou knihu a model si pamatuje všechno. Novější verze Opus a Sonnet nabízejí experimentální podporu až 1 milion tokenů - zkoušel jsem to s kompletní dokumentací ESP-IDF frameworku a fungovalo to překvapivě dobře, i když latence byla znatelně vyšší.

Claude Opus — hluboký myslitel

Co je Opus?

Opus je top tier model od Anthropic - navržený pro úlohy kde potřebuješ hluboké analytické uvažování, komplexní vícekrokové plánování, pokročilé programování a refaktoring, nebo práci s rozsáhlými kontexty jako jsou celé knihy nebo velké kódové báze. Když jsem poprvé testoval Opus na code review komplexní Flask aplikace s asynchronními tasky a Celery workers, byl jsem fascinovaný tím, jak model dokázal propojit souvislosti mezi moduly které byly od sebe vzdálené stovky řádků kódu a identifikovat potenciální race condition, kterou jsem já sám přehlédl.

Kdy použít Opus?

Ideální scénáře:

1. Code review před nasazením — Opus zachytí subtilní chyby jako memory leaky, async bugy nebo chybějící dispose volání, které ostatní modely přehlédnou
2. Architektonická rozhodnutí — Při návrhu systémové architektury nebo rozsáhlém refaktoringu
3. Výzkum a analýza — Sumarizace celých knih, analýza právních dokumentů, finanční modelování
4. Agentické workflow — Dlouhodobé autonomní úlohy vyžadující vícekrokové uvažování

Praktický příklad

Scénář: Máš komplexní Flask aplikaci s 50+ soubory a potřebuješ identifikovat 
bezpečnostní zranitelnosti.

Proč Opus: Model dokáže udržet kontext celé aplikace, propojit souvislosti mezi 
moduly a identifikovat zranitelnosti typu race condition nebo injection attacks, 
které vyžadují pochopení toku dat napříč celým systémem.

Cena

Opus 4.5 přinesl výrazné zlevnění oproti předchozím verzím (Opus 4/4.1 stál $15/$75), což zpřístupnilo prémiovou inteligenci širšímu spektru uživatelů - upřímně, při těch starých cenách jsem Opus používal jen na kritické review před nasazením do produkce, protože každý delší prompt stál dost peněz. Teď s novými cenami je to mnohem dostupnější, i když pořád ne na každodenní použití pokud máš omezený budget.

Claude Sonnet — spolehlivý kolega

Co je Sonnet?

Sonnet je vyvážený model - kombinuje vysokou inteligenci s rozumnou rychlostí a cenou, což z něj dělá ideální volbu pro většinu každodenní práce. Většina vývojářů tráví s tímhle modelem nejvíc času, a já nejsem výjimka - odhadem 80 % mých promptů jde na Sonnet, protože pro běžné programování, refaktoring nebo psaní dokumentace je naprosto dostačující a odpovídá rychle.

Kdy použít Sonnet?

Ideální scénáře:

1. Každodenní programování — Vývoj funkcí, práce s více soubory, správa stavu, připojení k API
2. Analýza a reporting — Strukturované analýzy, Q&A s dokumenty, vytváření reportů
3. Kreativní úlohy — Psaní obsahu, copywriting, technická dokumentace
4. Orchestrace agentů — Sonnet vytvoří plán a rozdělí úkoly pro Haiku instance

Praktický příklad

Scénář: Vyvíjíš React aplikaci s Tailwind CSS a potřebuješ implementovat
autentizaci s Firebase.

Proč Sonnet: Model zvládne multi-file logiku, správu stavu (Riverpod, Redux),
připojení k Firebase a generuje čistý, použitelný kód. Má vynikající výkon
v oblasti frontend/UI vývoje a generuje „pixel-perfect layouts".

Osobní zkušenost: Když jsem dělal redesign jednoho projektu s Flutter a Material 3,
Sonnet mi vygeneroval kompletní theme configuration včetně custom color schemes
a typography - kód fungoval na první pokus, což mě docela překvapilo protože
Material 3 API je dost komplexní a čekal jsem že budu muset něco ladit.

Cena

Sonnet nabízí výkon blížící se Opusu za zlomek ceny, což z něj dělá optimální volbu pro 90 % produkčních úloh - a tady je důležité si uvědomit že rozdíl mezi Sonnetem a Opusem není vždycky tak velký jak by se podle ceny mohlo zdát, takže pokud nejdeš do opravdu komplexních analýz nebo kritického code review, Sonnet ti bude stačit.

Claude Haiku — rychlý sprinter

Co je Haiku?

Haiku je nejrychlejší a nejlevnější model v rodině Claude - optimalizovaný pro minimální latenci (odpovědi pod sekundu), vysoký objem dotazů a nákladovou efektivitu. Upřímně, nejdřív jsem Haiku podceňoval a myslel si že je to jen "levná verze" pro lidi co chtějí ušetřit, ale když jsem ho začal používat na rychlé prototypování UI komponent, zjistil jsem že pro tento konkrétní use case je vlastně lepší než Sonnet - odpovídá skoro okamžitě a pro jednoduchý layout kód je kvalita naprosto dostačující.

Kdy použít Haiku?

Ideální scénáře:

1. Chatboti a zákaznická podpora — Real-time odpovědi bez čekání
2. UI prototypování — Rychlé generování layoutů a komponent
3. Klasifikace a moderace obsahu — Vysokoobjemové úlohy
4. Paralelní provádění subtasků — V orchestrovaném workflow s Sonnetem

Praktický příklad

Scénář: Potřebuješ rychle vytvořit Flutter screen s Material 3 designem.

Proč Haiku: Model vygeneruje layout téměř okamžitě. Pro brainstorming a rychlé
prototypy je ideální volbou. Ale pozor — v delších sessions „ztrácí nit"
a není vhodný pro komplexní logické stavby.

Osobní zkušenost: Zkoušel jsem s Haiku dělat složitější state management
s Riverpod providers a po třech čtyřech iteracích začal generovat kód který
nedával smysl - zapomínal na kontext z předchozích promptů a navrhoval řešení
která byla v rozporu s tím co jsme dělali předtím. Pro jednoduché úlohy super,
ale na komplexní logiku radši Sonnet.

Cena

Haiku je 5× levnější než Opus na vstupních tokenech, což z něj dělá ekonomickou volbu pro vysokoobjemové scénáře - pokud děláš chatbota nebo zákaznickou podporu kde potřebuješ zpracovat tisíce dotazů denně, rozdíl v ceně mezi Haiku a Sonnetem se rychle nasčítá na stovky dolarů měsíčně.

Srovnávací tabulka modelů

Orchestrační workflow — jak modely kombinovat

Když pracuješ na větším projektu, dává smysl kombinovat modely podle jejich silných stránek - tohle je něco co jsem se naučil až po pár měsících práce s Claude, protože na začátku jsem používal jen Sonnet na všechno a nevěděl jsem že můžu ušetřit čas i peníze tím že rozdělím úlohy mezi modely strategicky.

Fáze 1: Plánování (Sonnet)

Sonnet analyzuje požadavky, navrhuje architekturu a rozděluje úkoly na paralelizovatelné podúlohy.

Fáze 2: Implementace (Haiku)

Více instancí Haiku provádí subtasky paralelně — scaffolding, komponenty, API integrace.

Fáze 3: Review (Opus)

Před mergem provede Opus hlubokou revizi — zachytí async bugy, memory leaky a subtilní logické chyby.

Příklad z praxe:

Developer pracuje na mobilní aplikaci:
1. Používá Haiku pro rychlé UI prototypy
2. Přepne na Sonnet pro implementaci business logiky
3. Před releasem nechá Opus udělat finální code review

Výsledek: Opus odhalil rebuild issues a chybějící disposes,
které Haiku i Sonnet přehlédly.

Moje zkušenost: Přesně tenhle workflow jsem použil na jednom Flutter projektu
kde jsem dělal aplikaci pro správu IoT zařízení. Haiku mi vygeneroval asi 15
různých screen layoutů za pár minut, Sonnet implementoval komunikaci s MQTT
brokerem a state management, a Opus pak při finálním review našel memory leak
v subscription handleru který by v produkci způsobil problémy - model si všiml
že StreamSubscription není správně disposed při dispose() widgetu, což by
vedlo k postupnému nárůstu paměti. Tohle by Sonnet pravděpodobně přehlédl.

Rozhodovací strom: Který model zvolit?

START
  │
  ├── Je úloha časově kritická (real-time)?
  │     └── ANO → HAIKU
  │
  ├── Je to rutinní práce (coding, analýza, psaní)?
  │     └── ANO → SONNET
  │
  ├── Vyžaduje hluboké uvažování nebo rozsáhlý kontext?
  │     └── ANO → OPUS
  │
  ├── Je to finální review před nasazením?
  │     └── ANO → OPUS
  │
  └── Nejste si jistí?
        └── Začněte se SONNET, eskalujte na OPUS při potřebě

Cenové předplatné pro běžné uživatele

Pro ty, kteří nepoužívají API, nabízí Anthropic předplatné:

Praktické tipy pro optimalizaci nákladů

1. Začni s Haiku, eskaluj nahoru

Pro většinu dotazů postačí Haiku - na Sonnet nebo Opus přepni pouze pro složitější úlohy, což ti ušetří peníze a zároveň nezpomalí workflow, protože Haiku odpovídá tak rychle že rozdíl v latenci je znatelný.

2. Využij Prompt Caching

Při opakovaném dotazování na stejný kontext (např. velký dokument) snížíš náklady až o 90 % - tohle je obrovská úspora pokud pracuješ s rozsáhlou kódovou bází nebo dokumentací, protože model si cachuje kontext a při dalších dotazech ho nemusí znovu zpracovávat. Zkoušel jsem to s dokumentací k ESP-IDF a rozdíl v ceně byl dramatický - první prompt stál normálně, ale následující dotazy byly skoro zadarmo.

3. Batch API pro neurgentní úlohy

Asynchronní zpracování přes Batch API poskytuje 50% slevu na tokeny.

4. Optimalizuj prompty

Každý token stojí peníze. Odstraň zbytečný kontext a buď konkrétní.

Závěr

Každý model v rodině Claude má svoje místo:

• Opus je senior architekt — pomalejší, ale nejspolehlivější pro kritické rozhodnutí a hluboké analýzy
• Sonnet je spolehlivý kolega — zvládne 90 % každodenní práce kvalitně a efektivně, což z něj dělá můj go-to model
• Haiku je rychlý junior — ideální pro opakované úlohy a prototypování, překvapivě schopný pokud víš jak ho použít

Nejde o to používat jeden model na všechno. Jde o to strategicky kombinovat jejich silné stránky podle toho, co zrovna potřebuješ - a tohle pochopení přišlo až s praxí, protože na začátku jsem dělal chybu že jsem používal Sonnet i na úlohy kde by Haiku stačil, nebo naopak jsem se snažil ušetřit a používal Sonnet na code review kde by Opus odvedl mnohem lepší práci. Teď po několika měsících práce s těmito modely mám docela dobrý cit kdy který použít, a doufám že tento článek ti pomůže zkrátit tu learning curve.

Zdroje a další čtení

• Anthropic dokumentace
• Claude.ai
• API cenový přehled

Pro opravu diakritiky a překlepů byl použit model Claude Sonnet 4.5.

Článek aktualizován: březen 2026

The post Průvodce modely Claude od Anthropic first appeared on Hard Wired.