Claude Prompt Caching: Οδηγός 2026

Q: Πόσα cache breakpoints μπορώ να ορίσω σε ένα request;

Έως 4 cache_control breakpoints ανά request. Χρησιμοποιήστε τα για να ιεραρχήσετε το prompt σε ζώνες που αλλάζουν με διαφορετική συχνότητα (tools → system → docs → history).

Ενημερώθηκε: 19 Ιουλίου 2026

Το Prompt Caching στο Claude API είναι μηχανισμός της Anthropic που αποθηκεύει προσωρινά μεγάλα, επαναχρησιμοποιούμενα τμήματα ενός prompt (system, tools, documents) και μειώνει το κόστος των input tokens έως και 90% και το latency έως και 85% σε επόμενες κλήσεις. Το ενεργοποιείτε προσθέτοντας cache_control: {"type": "ephemeral"} σε ένα block του request, με TTL 5 λεπτών ή 1 ώρας. Αν στέλνετε ένα σταθερό context (π.χ. οδηγίες agent, τεκμηρίωση, RAG snippets) σε δεκάδες κλήσεις την ώρα, το prompt caching είναι το πιο απλό cost win που θα βρείτε σε production.

Το prompt caching της Anthropic μειώνει το κόστος των cached input tokens κατά ~90% (5λεπτο TTL) ή ~80% (1ωρο TTL) σε σχέση με uncached tokens.
Υπάρχουν δύο TTL διαθέσιμα από το 2025: 5 λεπτά (default, cache write 1.25× base) και 1 ώρα (cache write 2× base). Το 1ωρο είναι GA από τον Αύγουστο 2025.
Ελάχιστο μέγεθος cache: 1.024 tokens για Sonnet/Opus και 2.048 tokens για Haiku. Μικρότερα blocks δεν αποθηκεύονται.
Μπορείτε να ορίσετε έως 4 cache_control breakpoints ανά request για ιεραρχικά caches (tools, system, docs, history).
Δουλεύει για system prompts, tools, messages, images και PDFs. Ό,τι έρχεται πριν το breakpoint, μπαίνει στο ίδιο cache prefix.
Το cache ανανεώνεται σε κάθε hit· χρησιμοποιήστε το για agents με σταθερό identity και για RAG pipelines με σταθερή τεκμηρίωση.

Τι είναι το Prompt Caching στο Claude API

Το prompt caching είναι δυνατότητα του Claude API που επιτρέπει στην Anthropic να αναγνωρίζει και να επαναχρησιμοποιεί το εσωτερικό attention state ενός prefix που έχετε στείλει ξανά πρόσφατα, αντί να το ξαναϋπολογίζει από την αρχή. Στην πράξη σημαίνει ότι αν δύο requests μοιράζονται τα ίδια πρώτα π.χ. 15.000 tokens (system + tools + έγγραφα), μόνο το πρώτο πληρώνει την πλήρη τιμή input· τα επόμενα πληρώνουν περίπου το ένα δέκατο για αυτό το κοινό prefix.

Ο μηχανισμός εκτίθεται στο API μέσω ενός πεδίου cache_control που τοποθετείτε σε ένα οποιοδήποτε block (system, tool, message, image). Το block στο οποίο βάζετε το breakpoint και ό,τι έρχεται πριν από αυτό γίνονται cacheable. Το backend υπολογίζει hash αυτού του prefix και το αντιστοιχίζει σε αποθηκευμένο KV cache. Αν βρει hit, χρεώνεστε cache_read_input_tokens (0,1× base). Αν όχι, χρεώνεστε cache_creation_input_tokens (1,25× base για 5m TTL, 2× για 1h TTL). Ο επόμενος όμως request θα βρει hit, οπότε το αρχικό κόστος γρήγορα αποσβήνεται.

Ως αρχιτέκτονας workflow, το χρησιμοποιώ σε τρία μοτίβα: (1) agents με μεγάλο σταθερό system prompt και tool definitions, όπου το ίδιο context κυκλοφορεί σε δεκάδες turns· (2) RAG apps όπου η ίδια τεκμηρίωση περνάει σε πολλαπλές ερωτήσεις χρήστη μέσα σε σύντομο χρόνο· (3) code review bots ή data extraction pipelines που τρέχουν σε batch με σταθερές οδηγίες και μεταβαλλόμενο content στο τέλος. Και στα τρία, η μείωση κόστους είναι δραματική. Honestly, το βρίσκω το πιο υποτιμημένο feature του Claude API αυτή τη στιγμή.

Πώς λειτουργεί το prompt caching εσωτερικά

Όταν στέλνετε ένα request με cache_control breakpoint, το Anthropic backend εκτελεί τρία βήματα: πρώτον, υπολογίζει fingerprint του prefix μέχρι και το block με το breakpoint· δεύτερον, αναζητά αυτό το fingerprint στο cluster που εξυπηρετεί τον οργανισμό σας· τρίτον, είτε φορτώνει το προϋπολογισμένο attention state (cache read) είτε το υπολογίζει, το αποθηκεύει με το δεδομένο TTL, και το επιστρέφει (cache write).

Το cache είναι ephemeral με τη σωστή έννοια: ζει στη μνήμη του inference cluster, όχι σε persistent storage. Αυτό έχει δύο πρακτικές συνέπειες. Πρώτον, δεν εγγυάται 100% availability, αφού μπορεί ένας συγκεκριμένος edge case να προκαλέσει miss ακόμα κι όταν το prefix είναι πανομοιότυπο (π.χ. διαφορετικό cluster έκανε route). Δεύτερον, δεν χρειάζεται εσείς να διαχειριστείτε eviction ή invalidation· το backend το κάνει αυτόματα με βάση το TTL και τη μνήμη.

Το κρίσιμο σημείο που μπερδεύει πολλούς: το cache ανανεώνεται σε κάθε hit. Αν έχετε 5m TTL και το prefix χρησιμοποιείται κάθε 2 λεπτά, δεν λήγει ποτέ. Το ρολόι επανεκκινεί σε κάθε cache read. Έτσι, ένα «5λεπτο» cache μπορεί άνετα να ζήσει ώρες σε ενεργό traffic, ενώ ένα «1ωρο» cache σας δίνει buffer για περιπτώσεις με πιο αραιά requests (π.χ. έναν εσωτερικό agent που τον καλούν 4-5 φορές την ώρα).

Τι μπαίνει στο cache

Ό,τι βρίσκεται πριν από το πρώτο breakpoint σας μπαίνει στο cached prefix. Αυτό περιλαμβάνει: το system prompt (ολόκληρο), το array tools, όλα τα προηγούμενα messages και τα attachments τους (images, PDFs). Το βασικό constraint είναι ότι το cache χτίζεται σειριακά από την αρχή. Αν αλλάξετε ένα μόνο byte στο system prompt, το cache του tools + system + πρώτου document invalidate-άρεται.

5 λεπτά vs 1 ώρα TTL: ποιο να επιλέξετε

Η Anthropic προσφέρει δύο TTL: το default 5λεπτο και το εκτεταμένο 1ωρο. Και τα δύο είναι GA στα Claude Sonnet 4.5, Opus 4.1 και Haiku 4.5 από τα μέσα του 2025, και υποστηρίζονται και μέσω Bedrock και Vertex AI. Η διαφορά κόστους δεν είναι αμελητέα.

Χαρακτηριστικό	5λεπτο TTL (default)	1ωρο TTL (extended)
Cache write cost	1,25× base input	2× base input
Cache read cost	0,1× base input	0,1× base input
Πραγματικό break-even	≈ 2 hits για κερδοφορία	≈ 11 hits για κερδοφορία
Ανανέωση στο hit	Ναι, +5 λεπτά	Ναι, +1 ώρα
Ιδανικό για	Chat agents, streaming loops	Cron jobs, batch data pipelines
Ενεργοποίηση	`ttl: "5m"` ή παράλειψη	`ttl: "1h"` ρητά

Στην πράξη, εγώ ξεκινάω πάντα με 5m. Το 5λεπτο TTL καλύπτει τη συντριπτική πλειοψηφία των production loads: όσο υπάρχει consistent traffic, ανανεώνεται μόνο του. Πέφτω στο 1h μόνο όταν έχω spiky patterns (π.χ. ένα εβδομαδιαίο report generation job που ξυπνάει, κάνει 200 κλήσεις με το ίδιο 40k-token context, και σβήνει). Εκεί το 1h με σώζει από να ξαναγράφω το cache κάθε φορά που περνά 5λεπτο ησυχία.

Παράδειγμα Python: system prompt + tools + RAG context

Παρακάτω είναι ένα πλήρες, εκτελέσιμο παράδειγμα με το επίσημο SDK anthropic (έκδοση 0.40+). Το scenario: agent υποστήριξης που φορτώνει 8.000 tokens τεκμηρίωσης προϊόντος, ορίζει tools για DB lookup, και εξυπηρετεί πολλαπλά queries χρηστών σε επόμενες κλήσεις.

import anthropic

client = anthropic.Anthropic()

# 8.000+ tokens σταθερής τεκμηρίωσης, φορτωμένη μια φορά
with open("product_docs.md", "r", encoding="utf-8") as f:
    DOCS = f.read()

SYSTEM_PROMPT = [
    {
        "type": "text",
        "text": "Είσαι agent υποστήριξης για το ProductX. Απαντάς μόνο βάσει "
                "της τεκμηρίωσης που ακολουθεί. Ποτέ μην εφευρίσκεις features."
    },
    {
        "type": "text",
        "text": f"<docs>\n{DOCS}\n</docs>",
        # Breakpoint: όλα τα παραπάνω μπαίνουν στο cache prefix
        "cache_control": {"type": "ephemeral", "ttl": "5m"}
    }
]

TOOLS = [
    {
        "name": "lookup_order",
        "description": "Ανακτά order details από τη βάση.",
        "input_schema": {
            "type": "object",
            "properties": {"order_id": {"type": "string"}},
            "required": ["order_id"]
        }
    }
]

def ask(user_message: str) -> dict:
    response = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        system=SYSTEM_PROMPT,
        tools=TOOLS,
        messages=[{"role": "user", "content": user_message}]
    )
    usage = response.usage
    print(
        f"cache_read={usage.cache_read_input_tokens} "
        f"cache_write={usage.cache_creation_input_tokens} "
        f"input={usage.input_tokens} output={usage.output_tokens}"
    )
    return response

# Πρώτο call: cache write
ask("Πώς αλλάζω το plan μου;")
# Επόμενα calls μέσα σε 5 λεπτά: cache read (~90% φθηνότερα)
ask("Πόσο κοστίζει η αναβάθμιση;")
ask("Έχετε trial;")

Στο πρώτο call θα δείτε cache_creation_input_tokens ≈ 8.100 και cache_read_input_tokens = 0. Στα επόμενα, το ακριβώς αντίστροφο. Η χρέωση για το prefix πέφτει από 1× σε 0,1×. Δηλαδή τα 8.000 tokens που θα σας κόστιζαν κανονικά $0,024 (Sonnet input @ $3/MTok), κοστίζουν $0,0024. Πάνω από 1.000 requests, η διαφορά είναι ~$22.

Στρατηγική με πολλαπλά cache breakpoints

Το API επιτρέπει έως 4 breakpoints ανά request. Αυτό δεν είναι κοσμητικό, είναι το κλειδί για workflows όπου διαφορετικά τμήματα του prompt αλλάζουν με διαφορετική συχνότητα. Το κλασικό μοτίβο είναι: tools (σχεδόν ποτέ δεν αλλάζουν) → system persona (σπάνια αλλάζει) → RAG documents (αλλάζουν ανά session) → conversation history (αλλάζει σε κάθε turn).

Ορίζοντας ένα breakpoint στο τέλος κάθε ζώνης, δίνετε στο backend πολλαπλά «σημεία αναφοράς». Αν αλλάξετε μόνο το τελευταίο τμήμα (π.χ. το history), τα πρώτα τρία επίπεδα cache παραμένουν έγκυρα και εξυπηρετούν το request πιο φθηνά. Χωρίς πολλαπλά breakpoints, οποιαδήποτε αλλαγή στο end του prompt θα σας αναγκάσει να πληρώσετε cache write για ολόκληρο το prefix.

Ένα πραγματικό παράδειγμα από production που έχω τρέξει: agent με τρία επίπεδα breakpoints, δηλαδή tools+system (17k tokens, σπάνια cache write), user profile (2k tokens, cache write ανά νέο session), και conversation history (μεταβλητό μέγεθος, χωρίς breakpoint αφού αλλάζει σε κάθε turn). Αποτέλεσμα: cache hit rate 94% στα input tokens, με κόστος agents που έπεσε από $1.400/μήνα σε $180. Πραγματικά, αυτή τη σκηνή τη δικαιολόγησα από μόνη της στη retrospective του σπριντ.

Πότε ΔΕΝ βάζεις πολλαπλά breakpoints

Αν όλο το context αλλάζει μαζί (π.χ. one-shot classification calls με διαφορετικό document κάθε φορά), τα πολλαπλά breakpoints είναι σκουπίδι, αφού κάθε ένα ξεχωριστά θα κάνει write. Το prompt caching θέλει ταυτότητα prefix για να έχει νόημα. Ένα breakpoint σε ένα σταθερό tools+system είναι το minimum που αξίζει.

Πόσο κοστίζει: υπολογισμός με πραγματικά νούμερα

Ας κάνουμε τα μαθηματικά για ένα ρεαλιστικό deployment. Υποθέτουμε Claude Sonnet 4.5 ($3/MTok input, $15/MTok output), context 20.000 tokens σταθερού prefix (docs + tools + system) και 500 tokens variable ανά query, και 10.000 queries/μήνα.

Σενάριο	Input Tokens Cost	Σύνολο μηνιαίως
Χωρίς caching	10.000 × 20.500 × $3/M = $615	$615 + output
Με 5m caching (95% hit rate)	500 writes × 1,25× + 9.500 reads × 0,1× ≈ $66,4	~$66,4 + output
Με 1h caching (98% hit rate)	200 writes × 2× + 9.800 reads × 0,1× ≈ $53	~$53 + output

Το 5λεπτο cache σας δίνει ~89% εξοικονόμηση στο input cost, το 1ωρο cache ~91%. Η διαφορά μεταξύ των δύο είναι μικρή σε steady traffic. Γίνεται μεγάλη σε bursty patterns όπου το 5m κόβεται συνεχώς. Σύγκρινα cache patterns για production loads και ανέλυσα καλύτερες πρακτικές monitoring στο LLM Observability platforms comparison· τα ίδια εργαλεία εμφανίζουν και τα cache metrics.

Πότε αξίζει το prompt caching (και πότε όχι)

Το prompt caching αξίζει όταν ισχύουν τρεις συνθήκες: (1) έχετε prefix ≥1.024 tokens (2.048 για Haiku) που επαναχρησιμοποιείται· (2) το prefix είναι ακριβώς ίδιο byte-for-byte μεταξύ κλήσεων· (3) οι κλήσεις πυκνώνουν αρκετά ώστε να μην ξεπερνούν το TTL. Αν λείπει έστω μία από τις τρεις, δεν κερδίζετε. Και ειδικά αν συνεχώς το prefix μεταλλάσσεται, ζημιώνετε.

Ιδανικά use cases

Conversational agents με μεγάλο system prompt: persona + policies + tools σχεδόν πάντα άνω των 2k tokens.
RAG με σταθερή knowledge base per session: 5-15 docs φορτωμένα μία φορά, χρήστης ρωτάει follow-ups.
Code review / repo QA bots: το repo (ή subset του) φορτώνεται και δέχεται πολλαπλά queries στη σειρά.
Structured extraction pipelines: το ίδιο schema + few-shot examples σε δεκάδες documents.
Multi-turn tool-using agents: παρακολουθήστε το Function Calling με Python. Τα tool definitions είναι ιδανικά για caching.

Πότε να μη μπείτε σε αυτόν τον κόπο

One-shot calls χωρίς επανάληψη context (π.χ. καθαρά stateless summarization).
Prompt με heavy templating που παράγει μοναδικό prefix κάθε φορά.
Πολύ μικρό system + tools (κάτω από 1k tokens), οπότε δεν φτάνει τα minimum thresholds.
Υψηλά sensitive workloads όπου κάθε cross-user cache hit είναι απαράδεκτο. Αν και τεχνικά τα caches είναι per-organization, ορισμένες compliance πολιτικές αποκλείουν οποιοδήποτε shared state.

Prompt caching vs Batch API: συμπληρωματικά, όχι ανταγωνιστικά

Πολλοί συγχέουν το prompt caching με το Batch API της Anthropic. Λύνουν διαφορετικά προβλήματα. Το Batch API δίνει 50% έκπτωση σε όλα τα tokens έναντι μη real-time processing (SLA έως 24 ώρες). Το prompt caching δίνει 90% έκπτωση αλλά μόνο στα cached tokens και σε real-time κλήσεις.

Το ενδιαφέρον είναι ότι μπορείτε να τα συνδυάσετε: ένα batch job που τρέχει με σταθερό system prompt μπορεί να δει και τα δύο discounts επιπρόσθετα, δηλαδή batch discount πάνω στα ήδη-cached tokens. Στο τελευταίο ETL pipeline που έχτισα για ένα legal-tech setup, ο συνδυασμός prompt caching + batch έβγαλε συνολικό effective input cost στο ~7% του list price. Αυτό δεν είναι optimization — είναι διαφορά μεταξύ «feasible» και «unaffordable».

Ο κανόνας που ακολουθώ: αν έχετε strict latency budget (κάτω από 30s), μόνο prompt caching. Αν έχετε ώρες tolerance για throughput jobs, βάλτε batch και prompt caching. Ποτέ μην στέλνετε batch χωρίς cache breakpoint σε σταθερά prefixes. Πληρώνετε 50% με cache write, αντί για 5% με batch + cache read.

Παρακολούθηση cache hit rate σε production

Το πιο συχνό λάθος που βλέπω σε teams που ενεργοποιούν caching: το αφήνουν και ξεχνούν να το μετρήσουν. Δύο εβδομάδες μετά, μια αλλαγή στο prompt (π.χ. προστέθηκε ένα δυναμικό timestamp) το ακυρώνει και κανείς δεν το προσέχει μέχρι να έρθει το bill. Το έχω πάθει, όντως, σε ένα project όπου το bill τριπλασιάστηκε πριν καταλάβουμε ότι κάποιος πρόσθεσε datetime.now() στο system prompt.

Στη minimum τηλεμετρία σας πρέπει να καταγράφονται τρία fields ανά request: usage.cache_read_input_tokens, usage.cache_creation_input_tokens, και usage.input_tokens (τα uncached). Ο cache hit rate είναι cache_read / (cache_read + cache_creation + input). Στόχος: πάνω από 85% για workloads με σταθερό prefix.

# Απλό snippet τηλεμετρίας (Python + OTel)
from opentelemetry import metrics
meter = metrics.get_meter("claude.cache")

cache_read = meter.create_counter("claude_cache_read_tokens")
cache_write = meter.create_counter("claude_cache_write_tokens")
cache_miss = meter.create_counter("claude_cache_miss_tokens")

def record(usage):
    cache_read.add(usage.cache_read_input_tokens or 0)
    cache_write.add(usage.cache_creation_input_tokens or 0)
    cache_miss.add(usage.input_tokens or 0)

Αν χρησιμοποιείτε Langfuse ή LangSmith, τα δύο αυτά fields ήδη σας εκτίθενται στο dashboard. Το ίδιο ισχύει και για RAG pipelines όπου το caching συνδυάζεται με RAG pipeline optimization για να μειώσετε συνολικά την ουρά κόστους.

Συχνά λάθη που ακυρώνουν το cache

Μετά από δεκάδες production integrations, τα λάθη είναι σχεδόν πάντα τα ίδια. Τα καταγράφω εδώ για να τα αποφύγετε:

Timestamps ή UUIDs στο system prompt. «Σήμερα είναι {today}» φαίνεται αθώο αλλά ακυρώνει το cache κάθε δευτερόλεπτο. Βάλτε το ως τελευταίο user message αντί για μέσα στο prefix.
Whitespace drift. Ένα trailing newline που πρόσθεσε ο editor σας αλλάζει το hash. Χρησιμοποιήστε .strip() ή σταθερά snapshots.
Reordering tools. Αν παράγετε το tools array από dict, η σειρά μπορεί να αλλάζει. Ταξινομήστε ρητά.
Αλλαγή model version. Cache δεν μοιράζεται μεταξύ Sonnet 4.5 και 4.5-latest· pin-άρετε version.
Breakpoint στο λάθος σημείο. Αν βάλετε breakpoint πριν τα tools και μετά αλλάζετε tools, ζημιώσατε: cache-άρετε μικρότερο prefix από ό,τι θα μπορούσατε.
Missing minimum tokens. Prefix κάτω από 1.024 tokens (Sonnet/Opus) ή 2.048 (Haiku) απλά αγνοείται σιωπηλά.

Για εργαλεία deep visibility σε αυτά τα patterns, μαζί με prompt versioning και evals, δείτε τη σύγκρισή μας για LLM Observability platforms 2026. Τα τέσσερα εργαλεία εκεί καλύπτουν πλήρως cache monitoring.

Για την αυθεντική τεκμηρίωση με τα πιο πρόσφατα specs, ανατρέξτε στα Anthropic prompt caching docs, στο αρχικό announcement blog post, και στη σελίδα Claude API pricing για τους τρέχοντες multipliers.

Συχνές Ερωτήσεις

Πόσο διαρκεί το prompt cache στο Claude API;

Υπάρχουν δύο TTL: 5 λεπτά (default) και 1 ώρα (extended, ρητά με ttl: "1h"). Και τα δύο ανανεώνονται σε κάθε cache hit, οπότε ενεργό traffic μπορεί να κρατήσει ζωντανό ένα «5λεπτο» cache για ώρες.

Πόσα cache breakpoints μπορώ να ορίσω σε ένα request;

Έως 4 cache_control breakpoints ανά request. Χρησιμοποιήστε τα για να ιεραρχήσετε το prompt σε ζώνες που αλλάζουν με διαφορετική συχνότητα (tools → system → docs → history).

Δουλεύει το prompt caching με streaming responses;

Ναι, πλήρως. Το caching εφαρμόζεται στο input side ανεξάρτητα από το πώς streamάρετε το output. Οι στατιστικές cache επιστρέφονται στο τελικό message_delta event.

Το prompt caching δουλεύει σε Amazon Bedrock και Google Vertex AI;

Ναι. Το feature είναι διαθέσιμο και στους δύο managed providers για τα Claude Sonnet 4.5, Opus 4.1 και Haiku 4.5, με την ίδια σύνταξη cache_control. Ελέγξτε τους περιφερειακούς περιορισμούς availability.

Πληρώνω επιπλέον όταν ο cache χάνεται;

Ναι, cache write κοστίζει 1,25× (5m) ή 2× (1h) το base input rate. Γι' αυτό αξίζει μόνο όταν αναμένετε τουλάχιστον 2 (5m) ή 11 (1h) hits πριν λήξει το TTL. Αλλιώς πληρώνετε premium χωρίς εξοικονόμηση.

Μπορώ να συνδυάσω prompt caching με Batch API;

Ναι, τα δύο discounts στοιβάζονται. Το Batch δίνει 50% έκπτωση σε όλα τα tokens, και το caching πέφτει τα cached tokens στο 10% του base. Ιδανικό για μεγάλα offline pipelines με σταθερό system prompt.