Ang artikulo ay nagtataglay ng malalim na teknikal na pagsusuri sa lekso ng source code ng Claude Code (v2.1.88) noong Marso 31, 2026, at itinuturing ito bilang isang mahalagang kaso na nagpapakita ng advanced na arkitektura ng AI Agent.

May-akda, pinagmulan: Max

Ngayon (Marso 31, 2026), ulit na ipinakita ni Anthropic sa npm repository ang buong frontend at source code ng kanilang pinakabagong bersyon ng Claude Code (v2.1.88) dahil sa maliit na pagkakamali sa proseso ng pagpapakita.

Isinampa ng isang netizen ang isang hindi natanggal na cli.js.map file, na nagbalik ng higit sa 1,900 na mga file at higit sa 510,000 na linya ng native TypeScript code.

Para sa Anthropic, ito ay isa pang seriyosong paglabag sa OpSec pagkatapos ng pagleak ng dokumentasyon ng Mythos model sa mga araw na nakalipas.

Ngunit para sa mga developer at mga mananaliksik sa industriya sa buong application layer ng malalaking modelo, ang source code na ito ay isang walang pag-iingat, napakataas na halaga na avant-garde na whitepaper sa engineering architecture ng AI Agent.

Hindi na nag-uusap tungkol sa kontrobersiya sa pagkakaroon ng pagsunod at mga insidente ng paglalabas, nag-wala ako ng ilang oras upang malalim na suriin ang source code na ito sa lokal.

Kung hindi ito itinuturing bilang isang gosip, kundi bilang isang kaso ng arkitektura ng production-grade AI programming assistant, mayroon itong maraming pagpapasya sa inhenyeriya na lumalabas sa karaniwang pag-iisip.

Narito ang detalyadong teknikal na pag-aaral ng ilalim na arkitektura, mekanismo ng pag-schedule, sistema ng memorya, at mga patakaran sa kaligtasan ng Claude Code mula sa isang obhetibong pananaw.

Mahaba ang artikulo, angkop para sa mga propesyonal na nagtatrabaho sa AI Infra, Agent development, at sa mga interesado sa arkitektura ng application layer ng malalaking modelo.

PART.01 Hindi lamang isang CLI tool

Mula sa istruktura ng direktoryo (higit sa 40 na pangunahing module sa ilalim ng src/), ang kumplikadong kalikasan ng Claude Code ay lubos na hihigit sa mga karaniwang monolytikong Agent na open-source sa kasalukuyang merkado.

Ang pagpili ng kanyang teknikal na stack ay napakapragmatiko at nakatuon sa karanasan ng terminal:

Ang wika ay TypeScript, ang runtime ay pinili ang mas agresibong performance na Bun, ang CLI framework ay gumagamit ng Commander, at ang terminal rendering layer ay gamit nang hindi inaasahan ang React + Ink.

Bakit gagamitin ang React para sa isang command-line tool?

Ang sagot ay nasa screens/REPL.tsx sa source code (hanggang 5005 na linya).

Sa mga sitwasyon ng streamng output ng malalaking modelo at pagpapatakbo ng maraming kasangkapan nang sabay-sabay, ang pagpapamahala sa estado ng UI ay naging napakakomplikado (halimbawa, pag-render ng proseso ng pag-iisip, mga bar ng progreso ng pagtawag sa kasangkapan, preview ng code Diff, atbp.).

Ang paggamit ng declarative na React kasama ang minimalistic na Zustand-style custom Store (state/store.ts) ay ang pinakamahusay na engineering practice para sa mataas na kalikasan ng lokal na refresh.

Sa mode ng pagpapatakbo, ang sistema ay malalim na hinati sa dalawang anyo:

Interactive REPL mode: Frontend terminal UI powered by Ink, primarily designed for human developers.

Headless/SDK mode (QueryEngine class): Buong pag-alis ng UI, sumusuporta sa JSON streaming output. Ito ay naglalagay ng pundasyon para sa pag-embed nito bilang ilalim na engine sa IDE (tulad ng Cursor) o sa CI/CD流程.

Ang proseso ng pagpapagana ng sistema ay napag-optimiza rin sa ekstremong paralelismo.

Sa main.tsx, ang mga I/O-intensive na operasyon tulad ng pagbasa ng konfigurasyon (MDM Settings) at pre-fetching ng mga keychain key ay isinama sa mga sub-process, na nagpapatakbo nang paralelo sa 135ms na loading process ng pangunahing module—ang paghingi ng mga milisecond sa startup latency ay sumasaklaw sa buong codebase.

PART.02 Prompt Cache (Prompt Cache) na Inhenyeriya

Ito ang pinakateknikal na bahagi ng buong source code, at ang pangunahing hadlang na nagpapalit sa karanasan ng Claude Code mula sa mga karaniwang app na may panlabas na balat.

Sa kasalukuyan, ang mga kasangkapan ng Agent ay karaniwang nagpapagsasama nang simpleng paraan ang System Prompt at ang kasaysayan ng pag-uusap habang sinusugpo ang mahabang konteksto.

Sa services/api/claude.ts ng Claude Code (isang core interaction module na may 3,419 na linya), ang pagbuo ng prompt ay ginawa nang may pagiging matalino sa antas ng byte.

Kilala nang malawak na ang mekanismo ng Prompt Cache ng Anthropic ay gumagamit ng prefix matching.

Upang maksimisahin ang cache hit rate, nilikha ng Claude Code ang isang mahigpit na arkitektura ng segmented cache:

Static section (globally cacheable): Generated by systemPromptSection(), includes model identity introduction ("You are Claude Code..."), system-level security rules, code style restrictions, basic guidelines for tool usage, etc. This section remains almost unchanged throughout the session lifecycle.

Dynamic boundary: Isang espesyal na marka na hard-coded sa source code na SYSTEM_PROMPT_DYNAMIC_BOUNDARY.

Dynamic section (session-level cache/no cache): Naglalaman ng mga data na madalas magbago tulad ng impormasyon sa kasalukuyang direktoryo ng trabaho (CWD), Git status, MCP (Model Context Protocol) instructions, at user configuration.

At upang maiwasan ang cache penetration dahil sa mga maliit na pagbabago sa prompt, ang sistema ay nagdagdag ng maraming mga panlaban na gawain na tila masalimuot:

Deterministic sorting: Ang mga deskripsyon ng kasangkapan (Tools Description) na ipinapadala sa malaking modelo ay sorted ayon sa alpabeto gamit ang prefx ng panloob na kasangkapan + suffix ng MCP tool.
Hash path mapping: Ang path ng profile ay hindi gumagamit ng random UUID, kundi ng hash batay sa nilalaman upang maiwasan ang pagkabigo ng cache dahil sa pagbabago ng path bawat pag-inject.
Nakalabas ang estado: Kahit ang listahan ng mga Agent na available sa kasalukuyan ay tinanggal na mula sa deskripsyon ng kasangkapan at isinapindot sa mga attachment ng mensahe. Ayon sa mga komento sa source code, ang pagbabagong ito lamang ay nagbawas ng halos 10.2% sa paggamit ng Cache Creation Tokens.

Lahat ng ito ay nagpapakita ng kasalukuyang kalagayan ng industriya: sa kasalukuyan, ang mahusay na pag-unlad ng AI application layer ay nangangahulugan ng pagpapahalaga nang mapagkakatiwalaan at masinsinan sa halaga ng API cache system.

PART.03 Mga Kasangkapan at Streamlined Parallel Execution

Ang Claude Code ay may higit sa 40 na mga kasangkapan (kabilang ang pagbasa at pagsulat ng file, pagsasagawa ng Bash, pagkuha ng web, atbp.), at ang arkitektura ng sistema nito ay gumagamit ng mataas na modular na Factory Pattern.

Ang bawat tool ay nagmula sa pangunahing Tool interface at kailangang implemntin ang mga paraan tulad ng checkPermissions(), validateInput(), at isConcurrencySafe() (kung konkurensyal na ligtas).

Mechanism ng ToolSearch na load ayon sa pangangailangan: Kapag ang bilang ng mga kasangkapan ay hihigit sa isang tiyak na threshold, ang pagpapakilala ng lahat ng mga deskripsyon ng kasangkapan sa Prompt ay magdudulot ng hindi tatanggap na token cost.

Ang source code ay nagpapakita ng isang eleganteng estratehiya na tinatawag na ToolSearch: ang mga di-kritikal na kasangkapan (tulad ng ilang partikular na analysis plugin) ay markahan bilang defer_loading: true.

Hindi makikita ng modelo ang mga tiyak na kahulugan ng mga kasangkapan sa kasalukuyang Prompt, at kilala lamang ang isang kasangkapan na ToolSearch. Kapag naniniwala ang modelo na kailangan nito ng karagdagang kakayahan, kailangan muna itong gamitin ang ToolSearch upang dinamikong i-load ang mga kongkretong konfigurasyon ng kasangkapan.

StreamingToolExecutor: Upang mapabuti ang efficiency ng pagpapatupad, suportahan ng sistema ang pare-parehong pagtawag sa mga kasangkapan.

Ang coordinator (toolOrchestration.ts) ay magpapartisyon sa mga hiling sa pagtawag ng tool na ibinigay ng malaking modelo bilang mga batch na parallel at serial.

Ang mga kasangkapan na may seguridad sa pagkakasabay (tulad ng pagbabasa ng maraming hindi kaugnay na file nang sabay-sabay, o pagpapadala ng mga paghahanap sa network nang sabay-sabay) ay masasagawa nang paralelo, habang ang mga kasangkapan na hindi may seguridad sa pagkakasabay (tulad ng pagpapalit ng iisang code file nang sunud-sunod) ay masasagawa nang serial.

Ang mga kasangkapan para sa malalaking result set (tulad ng buong disk Grep search) ay may budget na maxResultSizeChars; ang mga nilalaman na lalampas sa budget ay diretso na tinatanggal at ipinapahintulot sa lokal na temporary file, at ang LLM ay natatanggap lamang ng isang preview summary upang maiwasan ang pagpapalaki ng context window.

PART.04 Ang Fork Mechanism para sa Paglutas ng Context Pollution

Ang kasalukuyang monolithic Agent ay may isang patayong kamalian:

Sa pagpapatupad ng mga kumplikadong gawain (tulad ng paghahanap ng bug sa iba’t ibang file), maaaring paulit-ulit na basahin ng model ang maling file, subukan ang maling command, at ang mga proseso ng pagsubok at pagkakamali ay magdadala ng malaking dami ng basurang konteksto, na mabilis na magpapabagsak sa pangunahing usapan, na nagdudulot ng pagkakasira o pagkalimot ng orihinal na layunin ng model sa susunod na pag-iisip.

Ang Claude Code ay naglalakbay ng komplikadong Coordinator Mode at Fork Subagent mechanism upang lutasin ang problema na ito.

Pagkatapos i-enable ang coordinator mode sa environment variables, ang sistema ay mababago sa Coordinator-Workers architecture:

Coordinator (Coordina): Nawalan ng direkta na pagsasagawa ng mga file, nanatiling may access lamang sa mga kasangkapan na Agent (derived sub-agent), SendMessage, at TaskStop. Ang tanging gawain nito ay magplano ng workflow (Research → Synthesis → Implementation → Verification).
Mga manggagawa (executors): Dinala ang mga detalyadong paglalarawan ng kagamitan.

Ang pinakamakapagpapalakas ay ang kanyang fork inheritance mechanism.

Kapag kailangan ng malawakang pag-aaral ng code, ang Coordinator ay magf-fork ng isang Explore Agent.

Ang sub-Agent na ito ay magpapadala ng cache ng parent conversation (nagbabahagi ng Prompt Cache upang i-save ang gastos), ngunit ang mga susunod na pag-aaral na galaw at pagbasa ng junk files ay ganap na nangyayari sa kanyang hiwalay na konteksto.

Matapos ang pag-aaral, kailangan lamang ng sub-Agent na ipasa ang mga pinag-isang pangunahing konklusyon (Synthesis) sa pangunahing konteksto ng Coordinator gamit ang partikular na XML format na .

Ang disenyo na ito, na ginagamit lamang ng isang beses at nag-iiwan ng konklusyon lamang, ay isa sa mga pinakamahusay na praktika sa industriya para sa kompleks na pagkakasundo ng maraming Agent at mahabang teksto.

PART.05 Pagbubukas ng Parallel Mechanism ng Agent Swarm

Bukod sa serial Fork mechanism na ginagamit upang lutasin ang context pollution, ipinapakita ng source code ang mas ambisyosong concurrent multi-Agent architecture—Swarm (Teammate) cluster.

Ang bahaging ito ng lohika ay pangunahing nakatago sa mga direktoryo ng utils/swarm/ at tasks/.

Ang sistema ay sumusuporta sa isang uri ng gawain na tinatawag na in_process_teammate.

Sa ilalim ng arkitekturang ito, ang pangunahing proseso ay maaaring mag-activate nang sabay-sabay ng maraming Agent (tinatawag na Teammate) upang isagawa ang iba’t ibang gawain.

Ngunit sa terminal CLI environment, ang pagpapatakbo ng maraming agent nang sabay-sabay ay magdudulot ng dalawang makapagpapahamak na hamon sa inhinyeriya: pagkakaroon ng mga conflict sa popup ng pahintulot at kalituhan sa UI rendering.

Ang solusyon ni Anthropic ay napakaganda:

Leader permission bridge (permissionSync.ts): Hindi pinapayagan ng lahat ng Teammate subprocess na direktang magpapakita ng popup sa user para sa pahintulot. Ibinabahagi nila ang mga kahilingan sa pahintulot sa loob na channel patungo sa Leader Agent ng main process, kung saan ang Leader ay nagpapalabas ng seguridad at kumpirmasyon ng user sa pangunahing terminal.
Automatikong pagkakasunod ng terminal: Upang makapagmonito nang malinaw ang mga user sa estado ng paggawa ng maraming paralel na Agent, direktang isinama sa source code ang mga AppleScript command para sa iTerm2 at Terminal.app. Kapag nililikha ang bagong Teammate, awtomatikong hihiwalay ng terminal ang mga pane at ibinibigay ang sariling output window sa bawat sub-Agent.

Ito ang pagmarka ng pag-unlad ng AI mula sa “monolithic thinking” patungo sa “clustered concurrent collaboration”.

PART.06 Dream (Mga Pangarap) Arkitektura ng Memorya

Sa panahon ngayon kung saan ang RAG (Retrieval-Augmented Generation) ay nasa apogyo, halos lahat ng AI product ay nag-iintegrate ng vector database.

Ngunit sa kaguluhan, ang sistema ng memorya ng Claude Code (memdir/ module) ay napakaluma at praktikal, at ito ay lubos na batay sa lokal na file system.

Ang arkitektura nito ay binubuo ng isang pangunahing MEMORY.md (bilang isang mataas na antas na index, na limitado sa pinakamaraming 200 linya/25KB) at maraming mga paksa na file batay sa Frontmatter format.

Ang memorya ay detalyadong nahahati sa apat na kategorya: User, Feedback, Project, Reference.

Mas interesante ang nakatago na KAIROS assistant mode sa source code.

Ito ay isang daemon mode na hindi pa opisyal na ipinapakita.

Sa ilalim ng KAIROS mode, ang memory system ay hindi na simpleng pag-update ng index, kundi gumagamit ng append pattern na katulad ng tao's log (write sa logs/YYYY/MM/YYYY-MM-DD.md).

Sa gabi o sa panahon ng pagpapahinga, magiging aktibo ang isang offline task agent na tinatawag na Dream.

Ang tungkulin ng Agent ay ang pagsasummary at pagsasalin ng daily log sa araw na panahon, at pagpapalalim nito sa structured long-term theme file.

Ang asinkronong integrasyon mekanismo mula sa maikling log patungo sa matagalang memorya ay hindi lamang naglalabas sa problema ng recall rate ng vector retrieval, kundi nagpapakita rin ng malinaw na direksyon ng pag-unlad ng AI assistant sa edge patungo sa patuloy na online at patuloy na pagkatuto.

PART.07 Pagpapalakas ng Pagsasakop at Seguridad

Ang pagbibigay ng pahintulot sa AI na mag-execute ng lokal na Shell command at magbago ng mga file ay isang dalawang-kamay na sandata.

Ang madalas na popup na nangangailangan ng pagkumpirma mula sa user ay magkakaroon ng malaking epekto sa automated experience, habang ang awtomatikong pagpapatupad nang walang limitasyon ay maaaring magdulot ng pagkabigo ng sistema (tulad ng pagkakamali sa pagpapatupad ng rm -rf).

Ang Claude Code ay gumagamit ng isang maraming antas na arkitektura ng pagpapalakas ng pahintulot:

Mula sa pahinga na batay sa @anthropic-ai/sandbox-runtime, hanggang sa hardcoded na pagpigil sa mga partikular na mapanganib na operasyon (tulad ng git push --force), hanggang sa pag-verify sa antas ng tool.

Ngunit ang pinakamakapansin ay ang kanyang komponenteng tinatawag na Auto Mode Classifier (yoloClassifier.ts).

Kapag pinagana ng user ang automatic mode, hindi ginamit ng sistema ang mga patag na regular expression upang suriin ang panganib ng mga utos, kundi ginamit ang isang side query mechanism.

Ang sistema ay awtomatikong magpapadala ng isang pinababawat na transkripsyon ng kasalukuyang usapan at ang darating na Bash command sa isang mas maliit at mas mura LLM sa background upang makakuha ng desisyon na Allow o Deny.

Bukod dito, mayroon ding isang threshold-based Denial Tracking sa loob ng sistema, kung saan kapag madalas itong tinanggihan ng automated tools, ang sistema ay magpapakita ng graceful degradation at babalik sa Prompting mode upang hingin ang tulong ng tao.

Mas fleksible ang dinamikong sistema ng pagsasakop na ito gamit ang maliit na AI upang监管 ang malaking AI kaysa sa tradisyonal na mga istatikong pagsasara.

PART.08 Ilang mga small easter eggs

Sa huling bahagi, ang maraming Feature Flags (tulad ng VOICE_MODE, SSH_REMOTE, atbp.) at ang pagsubok sa environment variable na process.env.USER_TYPE === 'ant' ay nagpapakita ng dual standard ng mga malalaking kumpanya sa panloob na pagsubok at panlabas na paglalabas.

Para sa mga loob na empleyado ng Anthropic (Ant-only), ang mga patakaran sa pagpapalabas ng code ay sobrang mahigpit, kahit na paranoid:

Huwag magdagdag ng mga function nang walang pahintulot, kung hindi ito binanggit sa hiling, huwag i-restructure, mas mabuti ang tatlong magkakatulad na code kaysa sa sobrang pag-abstrak nang maaga, huwag isulat ang anumang komento nang default, kundi kung ang WHY ay lubos na hindi malinaw, kailangang i-report nang tumpak kung nabigo ang pagsubok.

Sa panlabas na pampublikong pagbuo, ang system prompt ay mas maamo: direktang pumunta sa paksa, subukan ang pinakasimpleng paraan, at subukang maging maikli at malinaw.

Ang kontrang ito ay nagpapakita na ang mga hangganan ng pag-uugali ng malalaking modelo ay malawak na nakadepende sa mga nakakabit na tagubilin.

Mahalagang tandaan na ang code ay naglalaman ng dalawang interesanteng module.

Undercover Mode:

Ito ay isang tampok na nagdudulot ng kontrobersiya sa komunidad ng seguridad.

Sa mga sitwasyon kung saan ang mga empleyado ay nagtatrabaho sa open-source o public repositories, ang mode na ito ay awtomatikong naka-on at hindi maaaring piliting isarado. Ang mode na ito ay magpapahiwatig sa Prompt na hilingin sa model na “Do not blow your cover” at piliting alisin ang lahat ng disclaimer o mga tanda mula sa AI.

Maaaring mukhang kulang sa transparensya mula sa pananaw ng public relations, ngunit pinapatotohanan nito mula sa panig na mayroon ang manufacturer ng absolute na kontrol sa role-playing at pag-intervenye sa output ng modelo.

Buddy System (electronic pet) easter egg:

Ang source code ay naglalaman ng nakatagong electronic pet system (nagpapagawa ng itik, mga manggagamot, atbp.).

Upang matiyak ang random at deterministikong pagbuo ng mga alagang hayop, ginamit ng mga inhinyero ang ID ng user kasama ang Mulberry32 pseudorandom number generation algorithm.

typescript

18 mga species: duck, goose, blob, cat, dragon, octopus, owl, penguin, ...

5 mga antas ng kakaibang antas: common (60%), uncommon (25%), rare (10%), epic (4%), legendary (1%)

// Mga katangian: DEBUGGING, PATIENCE, CHAOS, WISDOM, SNARK

Mga aksesor: crown, tophat, propeller, halo, wizard, beanie, tinyduck

// Espesyal: 1% na posibilidad ng shiny

Ang pinakamakakatawa na detalye ay dahil ang Ingles na pangalan ng isang espesye ng hayop ay eksaktong magkakasunod sa napakalikom na internal code name ng Anthropic (baka ang pinakamalakas na Claude na Capybara na nalikom noong dalawang araw na ang nakalipas).

Upang iwasan ang paghahanap ng mga salitang bawal ng scanner ng compliance, ginamit ng mga inhinyero ang String.fromCharCode() upang dinamikong mag-assembly ng salitang iyon.

Ang masayang pagkakagawa na ito ay nagtataglay ng isang natatanging pagkakaiba sa napakaseryosong code ng imprastruktura.

PART.09 Ano ang matututunan natin?

Sa maikling panahon, ang pagkalela ng mga teknikal na dokumento ng pangunahing modelo at ang pangunahing source code ng aplikasyon ay nagpapakita na kailangan ng malalim na pagsusuri ng Anthropic sa kanilang internal na proseso. Ngunit ang teknolohiya ay walang kasalanan; ang 510,000 linya ng code na ito ay isang napakabuting aralin para sa industriya.

Mula sa pagsasagawa ng Claude Code, natapos na ang panahon kung saan ang mga startup sa application layer ng malalaking modelo ay nakasalalay lamang sa pagpagsasama-samang paggamit ng Prompt, pagpapalaki ng vector database, at paggamit ng isang simpleng loop wrapper.

Ang tunay na hadlang ay binubuo ng ekstremong pagiging maingat sa gastos ng Token (Prompt Cache optimization), streamlining ng pagkakaayos ng maraming state machines (Coordinator at Fork mechanism), pagkabalans ng pagtanggap sa intensyon ng user at seguridad (YOLO Classifier), at malalim na integrasyon sa file stream ng host operating system.

Kasalukuyang nasa panganib na ma-remove agad ng DMCA request ang mga repository na naka-Fork sa GitHub.

Gayunpaman, ipinakita ng Claude Code ang antas ng engineering na nagtatag ng isang bagong teknikal na pamantayan para sa mga AI assistant product noong 2026.

Dapat ngang gamitin ng mga propesyonal ang pagkakataong ito upang mabuting suriin at ipasok ang mga pinakamahusay na praktis sa inhenyeriya.