MSO Foundations

Screen 1: What you will be able to do by the end

MODULE 1 ORIENTATION · 2 MIN Wat je aan het einde kunt doen

Voordat je code schrijft voor Claude, helpt het om te weten wat de woorden betekenen.

Deze module introduceert de modelfundamenten en de technische basis die de rest van de Developer-cursus al aanneemt dat je hebt.

Aan het einde van deze module kun je: 1 Uitleggen wat een token is, hoe de context window als vaste begroting werkt, waarom sampling ervoor zorgt dat outputs variëren, en wat non-determinisme betekent voor testen en evals. 2 De Claude-modelfamilie en de capabilitytiers beschrijven, en onderscheid maken tussen het kiezen van een model en het inschakelen van een reasoning mode zoals extended thinking. 3 Kiezen tussen zero-shot, one-shot en multi-shot prompting, en de kosten- en kwaliteitstrade-off van het toevoegen van voorbeelden afwegen. 4 Beschrijven hoe een developer Claude benadert: SDK versus raw REST, synchrone versus streaming responses, en asynchrone patronen voor werk met groot volume. DISCLAIMER / NOTICE FOR EDUCATIONAL CONTENT

We hebben deze Developer-cursus Module 1: MSO Foundations gebouwd om je echt werk met Claude te laten doen. Behandel het als educatief materiaal. Het vormt geen juridisch, financieel of ander professioneel advies, dus pas wat je leert aan op je eigen situatie. Onze producten en services evolueren snel, dus bepaalde inhoud kan fouten bevatten of verouderd zijn; vergeet niet om te verifiëren op de website of docs van Anthropic. Voorbeelden en scenario's die in de cursus worden gebruikt, zijn illustratief en vaak fictief. Als het cursusmateriaal een bedrijf of product noemt, betekent dit niet dat Anthropic ze aanbeveelt, zij Anthropic aanbevelen, of dat we geaffilieerd zijn. Houd er ook rekening mee dat je gebruik van Anthropic-producten en -services wordt gedekt door onze voorwaarden, beleid en documentatie; als iets in deze cursus daarmee in conflict is, hebben zij voorrang.

Screen 2: How LLMs behave: tokens, context, sampling, non-determinism

TeachingHoe LLM's zich gedragen·12 min Hoe LLM's zich gedragen: tokens, context, sampling, non-determinism

Tokens Context Window Sampling Non-determinisme

Tokens: de eenheid van input, output en kosten Claude leest niet rechtstreeks tekens of woorden. Het leest tokens, en het gemiddelde aantal tekens per token hangt af van de tokenizer van het betreffende model en verschilt tussen modelgeneraties. Behandel elke vuistregel voor tekens per token als modelafhankelijk en bevestig het huidige tokenizer-gedrag op bouwmoment. Alles wat het model verwerkt, wordt in tokens geteld: je prompt, de gespreksgeschiedenis, tool-definities, tool-resultaten en de response die het model genereert. Tokens zijn zowel de eenheid van prijsstelling als van begroting, dus wanneer je inschat wat een feature kost of of een input past, tel je tokens, niet woorden. Een nuttige gewoonte is om in tokens te denken, omdat dat de eenheid is waarin de API factureert en waarin de context window wordt gemeten.

De context window: een vaste begroting De context window is het totale aantal tokens dat het model voor één verzoek kan verwerken. Het bevat alles tegelijk: de systeemprompt, het volledige gesprek tot nu toe, alle documenten die je injecteert, elk tool-resultaat en de modeloutput. Het is een vaste begroting met twee verschillende randgedragingen. Een verzoek waarvan de input al groter is dan het window, wordt afgewezen met een validatiefout voordat generatie begint. Een verzoek dat op input past, kan nog steeds het plafond bereiken tijdens generatie. Huidige modellen stoppen dan en retourneren de tot nu toe gegenereerde output met een model_context_window_exceeded stop reason in plaats van een fout op te werpen. In beide gevallen vereist het uitvoeren van een lange sessie dat de applicatie de geschiedenis voor elke aanroep bijsnijdt of samenvat. In ontwikkeling wordt het window zelden vol omdat test-inputs kort zijn. In productie daarentegen vullen langere inputs en meer beurten het window sneller. Dit is de fout die Module 2 in detail onderzoekt.

Sampling: waarom dezelfde prompt verschillende antwoorden kan geven Een taalmodel kiest niet één vast volgende token. Bij elke stap produceert het een waarschijnlijkheidsverdeling over mogelijke volgende tokens en steekproeven daaruit. Instellingen, zoals temperature, vormen die verdeling: een lagere temperature concentreert waarschijnlijkheid op de meest waarschijnlijke tokens en maakt output herhaalbaar, terwijl een hogere temperature het verspreidt en output meer gevarieerd maakt. Omdat de keuze wordt bemonsterd in plaats van vast te staan, kan dezelfde prompt twee keer uitgevoerd verschillende formulering retourneren, zelfs wanneer beide antwoorden correct zijn. Dit is een eigenschap van hoe het model genereert. Opmerking: sampling-controles zijn modelafhankelijk: de nieuwste Claude-modellen accepteren geen niet-standaard sampling-parameters. Het instellen van temperature, top_p of top_k retourneert een 400-fout, en gedrag op die modellen wordt in plaats daarvan gestuurd via prompting. Zelfs waar temperature wordt geaccepteerd, maakt temperature 0 outputs herhaalbaar maar garandeert niet identieke outputs over aanroepen heen. Bevestig de huidige parameterondersteuning in de API-referentie op bouwmoment.

Non-determinisme: wat het betekent voor testen en evals Non-determinisme is de primaire gevolg van sampling: identieke inputs garanderen geen identieke outputs. Dat verandert hoe je een Claude-feature test. Een test die de exacte tekst van een response stelt, zal inconsistent zijn, omdat het model hetzelfde juiste antwoord op veel manieren kan uitdrukken. Stel in plaats daarvan in op de eigenschap die moet gelden: een vereist veld is aanwezig, een waarde is in bereik, de structuur parseert. Wanneer je betekenis in plaats van structuur moet beoordelen, gebruik je een eval met een model-graded judge. Dit is waarom de cursus evals als standaard behandelt voor het weten dat een feature correct is, en waarom Module 3 die mogelijkheid opbouwt.

Screen 3: Model options and reasoning modes

TeachingModellen & Reasoning·10 min Modelopties en reasoning modes

De Modelfamilie Reasoning Modes Hoe ze samenwerken

De Claude-modelfamilie Claude is een familie van modellen die momenteel vier tiers omvat: Fable, Opus, Sonnet en Haiku. Elk model vertegenwoordigt een ander compromis tussen kosten, latentie en mogelijkheden. Sonnet is de evenwichtige standaard voor de meeste productiewerklasten. Haiku is gebouwd voor snelheid en kostenefficiëntie op taken die in zijn capabilitybereik passen. Opus handelt veeleisend werk boven het Sonnet-bereik af, en Fable is de meest capabele tier, gebouwd voor het meest veeleisende reasoning, codering en agentic werk waar maximale intelligentie prioriteit is. De praktische standaard is om te beginnen met Sonnet, alleen naar een hogere tier te gaan wanneer een eval aantoont dat de huidige tier je kwaliteitsnorm mist, en alleen naar Haiku te gaan wanneer een eval aantoont dat de kwaliteitsdaling acceptabel is voor de taak. Bevestig de huidige modellijst en identifiers tegen platform. claude. com/docs op bouwmoment, omdat de Claude-familie evolueert.

Reasoning modes zijn een aparte instelling van modelkeuze Het kiezen welk model je uitvoert, is één beslissing. Of het model voor het antwoord nadenkt, is een aparte beslissing die je per aanroep maakt. Op huidige modellen is de reasoning mode adaptive thinking: het model beslist wanneer en hoeveel het nadenkt, en je stelt diepte in met een effort-instelling in plaats van een vaste token-begroting (de oudere budget_tokens-controle is verouderd en retourneert op de nieuwste modelgeneraties een 400-fout). Thinking-inhoud wordt standaard weggelaten uit responses op de nieuwste modellen. Vraag samengevatte weergave aan wanneer je het moet tonen. Reasoning verdient zijn kosten op moeilijke, multi-stap problemen en wordt verspild op lookups en classificatie. Het belangrijkste punt voor deze module is dat de twee hefbomen samenstellen: modelkeuze kiest het familielid, terwijl de reasoning mode per verzoek wordt geconfigureerd. Per-model standaardwaarden verschillen (sommige van de nieuwste modellen denken standaard adaptief of altijd), dus bevestig de huidige thinking-standaardwaarden voor je model op bouwmoment.

Hoe de twee samenwerken Omdat modelkeuze en reasoning mode onafhankelijk zijn, kan elk afzonderlijk worden ingesteld. Een capabel model met reasoning uit is snel en direct, terwijl een kleiner model met reasoning aan meer tokens besteedt aan nadenken. De meest veeleisende taken koppelen een capabel model met een hogere effort-instelling. Module 2 leert de mechanica van het inschakelen van reasoning en het verwerken van de thinking blocks die het retourneert. De beslissing welk model je uitvoert, afgewogen tegen kosten, latentie en kwaliteit, wordt behandeld in Module 4.

Screen 4: Prompting modes: zero-shot, one-shot, multi-shot

TeachingPrompting Modes·8 min Prompting modes: zero-shot, one-shot, multi-shot

De drie modes Kosten- & kwaliteitstrade-off Mode & modelkeuze

De drie modes Apart van hoe je een prompt formuleert, staat hoeveel uitgewerkte voorbeelden je het model in de prompt geeft. Zero-shot geeft de instructie en geen voorbeelden: je beschrijft de taak en vraagt om het resultaat. One-shot voegt één voorbeeld van de input gekoppeld aan de gewenste output toe. Multi-shot, ook wel few-shot genoemd, bevat meerdere dergelijke voorbeelden. De voorbeelden zijn geen trainingsgegevens; ze zitten in de prompt en tonen het model de exacte vorm van het antwoord dat je wilt, wat een beschrijving alleen vaak niet kan bepalen.

De kosten- en kwaliteitstrade-off Elk voorbeeld dat je toevoegt, kost tokens bij elke aanroep en verbruikt context-begroting, dus de keuze verhandelt kwaliteit tegen kosten. Grijp naar zero-shot wanneer de taak eenvoudig is en de outputvorm duidelijk. Ga naar one-shot of multi-shot wanneer de output een specifieke structuur, kapitalisatie of randgeval heeft dat een beschrijving blijft missen. Vaak fixeren één of twee juiste voorbeelden het probleem sneller dan nog een alinea instructies. De algemene discipline, die Module 2 versterkt, is om de kleinste hoeveelheid prompt toe te voegen die een betrouwbaar resultaat oplevert.

Modekeuze werkt samen met modelkeuze Prompting mode en modelkeuze zijn gerelateerde hefbomen. Een capabeler model slaagt vaak zero-shot op een taak waar een kleiner model een paar voorbeelden nodig heeft om de structuur te matchen, dus het toevoegen van voorbeelden kan een goedkoper model het werk laten doen. De twee beslissingen zijn het waard om samen te nemen: probeer het eenvoudigste model en de minste voorbeelden die je eval ontmoeten, en voeg mogelijkheden of voorbeelden alleen toe waar je eval zegt dat je ze nodig hebt.

Screen 5: The technical substrate: SDKs, REST, streaming, async

TeachingTechnische substraat·12 min De technische substraat: SDKs, REST, streaming, async

SDK versus REST Sync, Streaming & Real-time Async voor werk met groot volume

Hoe een developer Claude bereikt: SDK versus raw REST Claude wordt in de kern bereikt via een HTTP REST API: je code stuurt een verzoek naar een endpoint met je API-sleutel en een JSON-body, en leest een JSON-response terug. Je kunt dat endpoint rechtstreeks aanroepen met elke HTTP-client. Vaker gebruik je een officiële SDK, beschikbaar voor Python en TypeScript onder andere, wat een dunne gemakslaag over dezelfde REST API is. Het handelt authenticatie, verzoekconstructie, herhalingen en response-parsing af, zodat je minder boilerplate schrijft. De SDK en raw REST bereiken dezelfde API en hetzelfde model. De SDK bespaart je van het handmatig samenstellen van verzoeken. Module 2 bouwt tegen de SDK en de Messages API, die op dezelfde basis rust.

Synchrone, streaming en real-time responses Een synchrone verzoek is het eenvoudigste patroon: je stuurt het verzoek en wacht tot de volledige response in één stuk terugkomt, en handelt het dan af. Dat is prima voor korte responses en backend-jobs waar niemand wacht. Wanneer een response lang is of een gebruiker kijkt, stuurt streaming de response in stukken terwijl het model het genereert. Output verschijnt onmiddellijk in plaats van na een leeg scherm wachten, en je code stelt de stukken samen tot het uiteindelijke bericht. Claude stelt streaming bloot over dezelfde HTTP-verbinding met behulp van server-sent events. Module 2 leert hoe je een stream veilig consumeert en herstelt wanneer deze wordt onderbroken.

Asynchrone patronen voor werk met groot volume Twee patronen adresseren werk met groot volume, en ze lossen verschillende problemen op. De Python SDK stelt een async-client bloot (AsyncAnthropic) die non-blocking async/await gebruikt om API-aanroepen te doen zonder je applicatiethread vast te zetten. In de TypeScript SDK is de standaard Anthropic-client Promise-gebaseerd, dus je awaitet aanroepen rechtstreeks. Er is geen aparte async-clientklasse. In beide gevallen keert het verzoek nog steeds in real-time terug, maar je applicatie kan ander werk verwerken terwijl het wacht. Dit is het juiste patroon wanneer je gelijktijdigheid zonder blokkering nodig hebt. De Message Batches API is een apart patroon voor bulk offline-werklasten. Je dient een grote set verzoeken in één aanroep in, ontvangt een identifier en peilt op voltooiing. Batch-jobs kunnen tot 24 uur duren en draaien tegen lagere per-token kosten in ruil voor die latentie. Dit past bij offline-pijplijnen, evaluatieruns en bulk-jobs waar geen gebruiker op elk resultaat wacht en kosten meer uitmaken dan omlooptijd.

Screen 6: Module quiz

QuizModule 1·5 min Module quiz Probeer het nu. Hier zijn enkele meerkeuzevragen om je begrip van de cursus tot nu toe te testen. Vraag 1Een teamgenoot zegt dat twee identieke prompts identieke tekst moeten retourneren. Wat is het meest nauwkeurige antwoord? AJuist, het model is deterministisch. BNiet noodzakelijk, het model steekproeven elk volgende token uit een waarschijnlijkheidsverdeling, dus formulering kan variëren zelfs wanneer beide antwoorden correct zijn. CDat is alleen waar als streaming uit staat. DDat is alleen waar op het grootste model. Vraag 2Welke stelling scheidt modelkeuze het best van reasoning mode? AZe zijn dezelfde instelling. BExtended thinking is een ander model. CModelkeuze kiest welk familielid draait; extended thinking is een per-aanroep-instelling die elk ondersteunend model aan of uit kan hebben. DReasoning mode is vast per account. Vraag 3Een korte, goed gespecificeerde classificatietaak retourneert het juiste antwoord zero-shot. Wat doet het toevoegen van drie voorbeelden waarschijnlijk? AVerbetert nauwkeurigheid aanzienlijk. BVoegt token-kosten toe bij elke aanroep voor weinig of geen winst. CVerandert het model dat wordt gebruikt. DSchakelt sampling uit. Vraag 4Je moet duizenden inputs offline verwerken tegen de laagste kosten. Welke vorm past? AAsynchrone aanroepen in een lus. BStreaming. CIndiening van batch met polling. DEen groter context window.

Quiz indienen Nu overslaan

Screen 7: Exercise: predict the behavior

ExerciseVoorspel het gedrag·6 min Exercise: voorspel het gedrag Probeer het nu. Elk scenario hieronder presenteert een configuratie uit een van de vier fundamenten van deze module: sampling, prompting mode, verzoeksvorm en de context-begroting. Selecteer voor elk scenario het antwoord dat het juiste gedrag voorspelt en de reden identificeert. Gedeeltelijk krediet is beschikbaar wanneer je drie van vier correct beantwoordt. Scenario 1Beschouw een classificatietaak uitgevoerd bij temperature 0 versus dezelfde taak uitgevoerd bij hoge temperature. Voorspel hoe de outputs verschillen over herhaalde runs. ABij lage temperature concentreert het model waarschijnlijkheid op de meest waarschijnlijke tokens, dus herhaalde runs retourneren hetzelfde label veel consistenter, hoewel nooit met gegarandeerde determinisme, zelfs niet bij temperature 0. Bij hoge temperature verspreidt de verdeling zich, dus formulering en zelfs het gekozen label kunnen variëren. Voor een classifier wil je het lage-temperature, herhaalbare gedrag. BBeiden configuraties retourneren identieke output elke run, omdat temperature alleen de antwoordlengte beïnvloedt, niet welke tokens worden gekozen. CThe high-temperature run is nauwkeuriger, omdat het verspreiden van de verdeling het model meer juiste antwoorden laat overwegen. DTemperature heeft geen effect op een classificatietaak, omdat classificatie altijd een vast label retourneert ongeacht sampling. Scenario 2Beschouw een taak die output in de verkeerde structuur blijft retourneren onder een zero-shot prompt. Voorspel wat verandert als je naar multi-shot schakelt. ASchakelen naar multi-shot trainen het model opnieuw op de nieuwe structuur, dus de verandering is permanent over elke toekomstige aanroep zodra de voorbeelden zijn verzonden. BHet toevoegen van twee of drie juiste input-output voorbeelden toont het model de exacte structuur om te matchen, wat meestal een structuurprobleem fixeert dat meer instructietekst niet deed. De kosten zijn extra tokens bij elke aanroep, dus voeg de minste voorbeelden toe die de output betrouwbaar maken. CMulti-shot helpt niet bij een structuurprobleem; alleen het verhogen van de temperature verandert de vorm van de output. DMulti-shot verlaagt de token-kosten per aanroep, omdat voorbeelden het model kortere responses laten produceren. Scenario 3Beschouw een pijplijn die 50. 000 documenten 's nachts moet verwerken zonder gebruiker die wacht. Voorspel welke verzoeksvorm past en waarom. AEen synchrone lus past het best, omdat het aanroepen van de API eenmaal per document het eenvoudigste patroon is en de overhead van het indienen van een batch vermijdt. BStreaming past het best, omdat het sturen van de response in stukken de pijplijn laat beginnen elk document sneller te verwerken. CDe batch-patroon past: dien de verzoeken in een batch in en peil op voltooiing, accepterend langere latentie voor lagere per-token kosten. Een synchrone lus zou rate limits raken en de applicatie vastleggen, en streaming biedt niets omdat geen gebruiker kijkt. DEen groter context window past het best, omdat het passen van alle 50. 000 documenten in één verzoek herhaalde aanroepen vermijdt. Scenario 4Beschouw een lange multi-turn agent-sessie waarvan de context window blijft vullen. Voorspel de symptomen en noem de begroting die schuldig is. AHet model laat de oudste beurten stilzwijgend vallen om ruimte te maken, dus de sessie gaat door maar verliest stilzwijgend vroege context zonder enige fout. BDe context window is een vaste token-begroting; terwijl geschiedenis en tool-resultaten zich ophopen, vult het. Een input die al oversized is, wordt afgewezen met een fout voordat generatie, terwijl een verzoek dat op input past maar het plafond mid-generatie bereikt, terugkomt met afgekapte output en een model_context_window_exceeded stop reason. Het symptoom is een sessie die prima in testen draaide maar faalt zodra inputs groeien, daarom moet de applicatie geschiedenis bijsnijden of samenvatten. CDe symptoom is langzamer sampling, en de begroting schuldig is de temperature-instelling, die moet worden verlaagd naarmate de sessie groeit. DDer is geen vaste begroting; het window breidt zich automatisch uit om welke geschiedenis dan ook vast te houden, dus een lange sessie faalt nooit om deze reden.

Indienen Nu overslaan

Screen 8: Recap: five takeaways

RecapVijf belangrijkste punten·2 min Recap: vijf belangrijkste punten

1 Tokens zijn de eenheid van input, output en kosten. Denk en budget in tokens in plaats van woorden, omdat dat is wat de API meet en de context window meet.

2 De context window is een vaste token-begroting die het hele verzoek tegelijk bevat. Een oversized input geeft een fout voordat generatie, terwijl het plafond mid-generatie bereiken afgekapte output met een model_context_window_exceeded stop reason retourneert, dus het beheren van geschiedenis is de taak van de applicatie.

3 Sampling maakt generatie non-deterministisch. Dezelfde prompt kan verschillende formulering bij elke run retourneren, dus testen op exacte tekst is onbetrouwbaar. Dit is waarvoor evals zijn gebouwd.

4 Modelkeuze en reasoning mode zijn aparte, samengestelde hefbomen. Kies het kleinste model en de eenvoudigste reasoning en prompting die je eval en voeg mogelijkheden alleen toe waar je eval zegt dat je ze nodig hebt.

5 Een developer bereikt Claude via een REST API, meestal via een SDK. Kies tussen synchrone, streaming, async/await of batch op basis van of een gebruiker wacht en of de werklas real-time of bulk offline is.

Wat komt volgende: Module 2 zet deze fundamenten in praktijk over prompting craft, tool schemas, streaming, context engineering en agent construction.

Bronnen Claude 101 (Skilljar), Building with the Claude API (Skilljar), AI Fluency: Framework & Foundations (Skilljar), platform. claude. com/docs. Verifieer productspecificaties op publicatietijd.

Je kunt nu de gedeelde woordenschat van de Developer-cursus spreken. Tokens, context, sampling, model tiers, prompting modes en de transportmechanica van de API hebben nu namen, dus de rest van de cursus kan er rechtstreeks op voortbouwen.

Screen 9: Congrats! You've successfully completed this module.

Module CompleetDeveloper Path·2 min Gefeliciteerd! Je hebt deze module met succes voltooid. Je kunt nu tokens, de context window, sampling en non-determinisme uitleggen, onderscheid maken tussen modelkeuze en reasoning mode, de juiste prompting mode voor de taak kiezen, en beschrijven hoe een developer Claude bereikt via SDKs, REST, streaming en async patronen. Deze fundamenten zijn de gedeelde woordenschat waarop de rest van de Developer-cursus voortbouwt.

0 van ? checkpoints geslaagd

M1

MSO Foundations Tokens, context, sampling, model tiers, prompting modes en de technische substraat.

Je bent hier

M2

Production-Grade Prompting, Agents & Tool-use Prompting craft, extended thinking, tool schemas, streaming, context engineering en agent construction.

Volgende

M3

Claude Code, MCP & Integration Permission modes, durable project context, plugin packaging en MCP integration zonder credentials te lekken.

M4

Production Engineering, Evals en Security Evals, tracing, failure handling, cost en orchestration budgets en security boundaries die in productie standhouden.

M5

Accelerators en IP Contribution Package accelerators, bereid verifieerbare bijdragen voor, kies deployment platforms en markeer trust boundaries.

Module beoordelen Opnieuw beginnen Start Module 2 → Terug naar cursushuis

Module 1 voltooid.