Telemetry ya coding agent: nini hutumwa nje?

Telemetry ya wakala wa uandishi wa msimbo inahusu nini hasa

Telemetry ya wakala wa uandishi wa msimbo (coding agent) inajumuisha mitiririko minne tofauti ya data inayotumia neno moja, na kila mtiririko una udhibiti wake. Model inference hubeba maelekezo (prompts) yako na msimbo wako kwa yeyote anayetoa huduma ya model hiyo, na hakuna mpangilio wowote unaoweza kuzima jambo hili. Product analytics na ripoti za hitilafu (crash reports) huenda kwa muuzaji, na mara nyingi huenda kwa kampuni ya kuhifadhi kumbukumbu (logging company) inayolipwa na muuzaji huyo. Uhifadhi wa data kwa ajili ya mafunzo (retention for training) ni suala la mkataba badala ya suala la mtandao. Mtiririko wa nne ndio watu wengi huukosa: kila integration unayoongeza inaweza kufungua muunganisho kwa host ambayo hukuichagua kamwe.

Orodha ya mipangilio chaguo-msingi ya wauzaji wa sasa ndiyo sehemu ya mada hii inayopitwa na wakati haraka zaidi. Toleo jipya (release) linaweza kubadilisha chaguo-msingi, na kipengele kipya kinaweza kuongeza sehemu ya kuelekea data (destination) ambayo hakuna swichi yoyote iliyopo inayoweza kuizuia. Kwa hiyo, ujuzi wa kudumu ni kufanya ukaguzi (audit) unaoweza kuurudia dhidi ya wakala yeyote: soma kile ambacho muuzaji amekiandika kwenye nyaraka, angalia ni configuration ipi iliyotumika kweli kwenye mashine hii, fuatilia mchakato huo kutoka kwenye mashine yenyewe, kisha chagua vidhibiti ambavyo uko tayari kuvigharamikia. Kila amri iliyo hapa chini ni ile unayoendesha kwenye mashine yako mwenyewe, dhidi ya trafiki yako mwenyewe.

Kategoria nne, na kwa nini zinahitaji vidhibiti tofauti

Trafiki ya model inference haiwezi kuepukika. Wakala hutuma prompt yako, faili ilizosoma, matokeo ya amri ilizoendesha, na maandishi yenyewe iliyozalisha kwenda kwenye endpoint ya model. Hiyo ndiyo kazi ya bidhaa yenyewe. Uamuzi pekee wa kweli ni nani anayepokea data hiyo: API inayoendeshwa na mtu mwingine, au model unayoijiendeshea mwenyewe. Akaunti ya wingu ya kampuni (Bedrock, Vertex, Foundry) inabadilisha mpokeaji, haiondoi mtiririko huo. Hakuna kitu kingine katika chapisho hili kinachopunguza trafiki ya inference, kwa hivyo iweke kando katika akili yako tofauti na zile kategoria nyingine tatu.

Uchambuzi wa bidhaa na kuripoti hitilafu (crash reporting) ni mtiririko tofauti kwenda kwa host tofauti. Vihesabio vya matumizi, namba za latency, utafutaji wa feature-flag, na stack traces kwa kawaida huenda kwenye majina ya host (hostnames) ambayo hayana uhusiano wowote na API ya model, na mara nyingi huenda kwa mtoa huduma wa tatu wa kufuatilia hitilafu. Wauzaji kwa kawaida huandika haya kama "metrics" na "error reports" na mara nyingi hukupa environment variable moja kwa kila kategoria. Kiasi chake ni kidogo sana, kwa hivyo hesabu ya byte haitawahi kuigundua. Unatafuta majina ya host, si bandwidth.

Uhifadhi na mafunzo (retention and training) ni sera, si pakiti za data. Kama mtoa huduma anahifadhi prompt zako, kwa muda gani, na kama anazitumia kufunza model ya baadaye, yote yameandikwa katika sheria na masharti yaliyoambatishwa kwenye mpango wako. Mipango ya watumiaji binafsi na mipango ya kibiashara kwa kawaida hutofautiana, na makubaliano ya kutohifadhi data (zero-retention) kwa kawaida ni mkataba tofauti. Huwezi kuthibitisha lolote kati ya haya kwa kutumia tcpdump, kwa sababu pakiti ya data inaonekana sawa kabisa kwa njia zote mbili. Soma sheria na masharti, na ikiwa ni muhimu kwa mwajiri wako, yapate kwa maandishi.

Integrations huongeza hatua ya ziada kimyakimya. Seva ya MCP (model context protocol), soko la plugin, ukaguzi wa auto-update, zana ya kutafutia kwenye wavuti, ukaguzi wa usalama unaotatua URL kabla ya kuipakua: kila moja ni ombi kwenda kwa host ambayo si endpoint ya model. Hapa ndipo mshangao ulipo, kwa sababu harness inaweza kuelekeza kazi uliyodhani ni ya ndani kupitia huduma yake yenyewe, na release inaweza kuanza kufanya hivyo bila kubadilisha hata mstari mmoja wa configuration yako. Ichukulie kila zana unayoongeza kama sehemu mpya ya kuelekea (destination) hadi utakapokuwa umeifuatilia kwenye mtandao.

Hatua ya 1: Je, muuzaji anaandika nini kwenye nyaraka?

Fungua marejeleo ya mipangilio na ukurasa wa matumizi ya data kwa ajili ya agent wako, kisha uyasome ukiwa na orodha ya maneno haya: metrics, analytics, error reporting, crash, feedback, survey, update check, safety check, marketplace. Kila moja ya maneno hayo kwa kawaida ni swichi tofauti. Andika majina kamili ya variable, kwa sababu hatua ya 2 itatumia grep kuyatafuta.

Neno moja litakupotosha. Katika agents kadhaa, "telemetry" kwenye nyaraka inamaanisha OpenTelemetry export unayosanidi ili kutuma metrics kwa collector unayoiendesha, jambo ambalo ni kinyume cha data kwenda kwa muuzaji. Claude Code ni mmoja wapo: kuweka CLAUDE_CODE_ENABLE_TELEMETRY=1 huanzisha export kwenda kwenye endpoint unayoitaja katika OTEL_EXPORTER_OTLP_ENDPOINT, na haina uhusiano na analytics za muuzaji mwenyewe, ambazo zina utaratibu tofauti wa kujiondoa (opt-out). Tambua mwelekeo wa mtiririko wa data kabla ya kuweka mipangilio yoyote.

Tarajia kuwepo kwa swichi kuu (master switch), na tarajia iwe na mapungufu. Kufikia Agosti 2026, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ya Claude Code huzima metrics, ripoti za makosa, amri ya feedback na tafiti za session kwa pamoja, na nyaraka hizo hizo zinasema haijumuishi ukaguzi wa usalama wa domain ya WebFetch, ambayo hutuma hostname unayotaka kuifikia kwa API ya muuzaji na ina mpangilio wake tofauti. Hii si malalamiko dhidi ya bidhaa moja. Hii ndiyo hali halisi ya tatizo kila mahali: swichi kuu inashughulikia kategoria zilizokuwepo wakati ilipoandikwa.

Tarajia kuwa kujiondoa (opt-out) kutakugharimu kitu fulani pia. Nyaraka hizo hizo zinaeleza kuwa kuzima telemetry pia huzima tathmini ya feature-flag ambayo baadhi ya vipengele hutegemea, kwa hivyo swichi iliyowekwa kwa ajili ya faragha inaweza kuzima kipengele unachokitumia, bila ujumbe wowote wa kosa unaounganisha mambo hayo mawili. Soma sentensi iliyo karibu na flag, si jina la flag pekee.

Hatua ya 2: ni usanidi upi uliotumika kihalisi?

Usanidi uliouandika si lazima uwe ndio uliotumika. Mawakala (agents) huunganisha usanidi kutoka faili kadhaa, na mojawapo inapatikana ndani ya hazina (repository) uliyoiiga kutoka kwa mtu mwingine. Anza na mazingira ya shell yako mwenyewe.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

Kisha chapisha kila faili ya usanidi inayosomwa na zana hiyo, kwa mpangilio uliotolewa kwenye nyaraka. Kwa Claude Code, kufikia Agosti 2026, hizo ni faili ya mtumiaji, faili mbili za mradi, na saraka ya sera iliyosimamiwa kwenye Linux.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

Faili ya mradi iliyokuja na git clone ni usanidi ulioandikwa na mtu mwingine, na inaweza kuwasha upya kile ambacho faili yako ya mtumiaji ilizima. Ikiwa wakala ana amri ya hali (status command) inayoorodhesha vyanzo vilivyopakiwa, hiyo ndiyo njia ya haraka zaidi ya kupata ukweli: Claude Code huchapisha vyanzo vya usanidi vilivyopakiwa katika /status.

Ukaguzi thabiti zaidi husoma mchakato unaoendelea (running process) badala ya faili yoyote. Mpe wakala akaunti yake ya mtumiaji wa Linux kwanza, jambo linalofanya kila amri katika chapisho hili kuwa fupi, kisha soma mazingira ambayo mchakato huo ulianzishwa nayo.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

/proc/<pid>/environ huonyesha vigezo (variables) ambavyo mchakato ulikuwa navyo wakati wa utekelezaji (exec time), hivyo hunasa hali ambapo .bashrc export yako haikufika kwenye huduma iliyoanzishwa na systemd. Ikiwa kigezo ulichoweka hakipo hapa, hakikuwahi kufanya kazi, bila kujali kile ambacho faili zako za dotfiles zinasema.

Hatua ya 3: inaunganishwa na host zipi?

Anza na socket zilizo wazi, zilizochujwa kulingana na akaunti inayotumika kuendesha agent.

sudo ss -tnpe state established

-e huongeza uwanja wa uid: kwenye kila mstari, ili uweze kutenganisha miunganisho ya agent na ile ya kivinjari chako bila kusoma majina ya mchakato. Kumbuka anwani za mbali, kisha pata majina yaliyo nyuma yake. Chanzo safi zaidi cha majina ni TLS (transport layer security) handshake, kwa sababu kila muunganisho mpya huanza na ClientHello inayobeba uwanja wa SNI (server name indication), ambao ni hostname iliyoombwa na mteja.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

Unapata mstari mmoja kwa kila muunganisho mpya, ambayo ndiyo orodha kamili unayohitaji: API ya modeli, seva ya masasisho, host ya analytics, kifuatiliaji cha makosa, na chochote kilichoongezwa na integration. Safu wima ya jina ikiwa tupu inamaanisha mteja huyo alitumia ECH (encrypted client hello), kwa hivyo hostname haionekani kwenye mtandao, na unalazimika kutumia anwani ya IP ya lengo, reverse lookup, au proxy katika hatua ya 4.

Mtazamo wa DNS (domain name system) ni njia muhimu ya kuhakiki, kwa sababu unaonyesha majina ambayo agent aliyafuata hata kwa miunganisho ambayo haikukamilika.

sudo tcpdump -ni any -l 'udp port 53'

Kila mstari wa query huishia na aina ya rekodi na jina, katika mfumo wa A? host.example.net. (39). Nasa kwenye any badala ya interface ya nje, kwa sababu kwa systemd-resolved programu huwasiliana na stub listener ya ndani kwenye 127.0.0.53 na stub pekee ndiyo huwasiliana na nje. Ikiwa huoni trafiki yoyote ya DNS wakati agent anafanya kazi waziwazi, runtime hiyo inafanya DNS over HTTPS yenyewe, na hatua ya 4 pekee ndiyo itakupa majina.

Nasa trafiki wakati agent anafanya kazi halisi. Anzisha session, iambie isome faili, iambie iendeshe amri, iambie ifeli kwenye kitu fulani. Trafiki inayotokea mara moja wakati wa kuanza, au tu wakati exception inapotupwa, haionekani kamwe kwenye capture ya hali ya kutofanya kazi (idle), na capture ya aina hiyo ndiyo njia ya kawaida inayofanya ukaguzi kufikia jibu lisilo sahihi lakini linaloonekana kuwa sawa.

Hatua ya 4: ni nini kilichomo ndani ya maombi?

Majina ya host (hostnames) hukuambia ni nani. Ili kuona ni nini, weka proxy unayoimiliki mbele ya agent na uiamini certificate authority (CA) yake kwa ajili ya runtime hiyo pekee. mitmproxy ndiyo zana ya kawaida. Mradi huu unapendekeza binaries zinazojitegemea kutoka mitmproxy.org, na kuandika uv tool install mitmproxy kama njia ya kifurushi cha Python.

mitmdump -w /tmp/agent-flows.mitm

Uendeshaji wa kwanza huandika CA ndani ya ~/.mitmproxy/, ambapo mitmproxy-ca-cert.pem ni cheti chenyewe. Katika shell utakayotumia kuzindua agent, elekeza client kwenye proxy hiyo na kwenye cheti hicho.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

CLI nyingi za agent ni programu za Node, na Node husoma NODE_EXTRA_CA_CERTS wakati mchakato unapoanza, kwa hivyo i-export kabla ya kuzindua agent na si katika terminal nyingine baadaye. Clients za Python husoma REQUESTS_CA_BUNDLE au SSL_CERT_FILE, na binary ya Go inayotumia standard library husoma SSL_CERT_FILE kwenye Linux. Thibitisha kuwa njia hiyo inafanya kazi kwa curl kabla ya kuilaumu agent.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Proxy inayofanya kazi huchapisha 200 na ombi linaonekana katika matokeo ya mitmdump. CA isiyoaminika hutoa curl: (60) SSL certificate problem: self-signed certificate in certificate chain, na ujumbe sawa na huo kutoka kwa agent ya Node ni kosa lenye msimbo SELF_SIGNED_CERT_IN_CHAIN. Soma flows zilizohifadhiwa baadaye kwa kutumia console viewer, ambapo unaweza kufungua ombi moja na kusoma headers na body yake.

mitmproxy -r /tmp/agent-flows.mitm

Kuna matokeo manne yanayostahili kutajwa. Unaona maombi, katika hali hiyo yasome na uamue. Agent inakataa kuanza kwa kosa la cheti, ambalo ni tatizo la uaminifu katika runtime hiyo na si ugunduzi kuhusu muuzaji. Unaona API ya model pekee, ambayo inamaanisha kategoria nyingine zimezimwa, au zinawaka kwenye tukio ambalo hukulianzisha. Au huoni chochote wakati agent inafanya kazi waziwazi, ambayo inamaanisha client inapuuza vigezo vya mazingira (environment variables) vya proxy au inafunga (pins) vyeti vyake, na hakuna mpangilio wa programu unaoweza kuaminiwa kukuambia ukweli. Matokeo hayo ya mwisho ndiyo muhimu zaidi, na yanakurudisha kwenye hatua ya 3, kwa sababu packet capture haiwezi kushawishiwa kutokuona muunganisho.

Vidhibiti, kutoka dhaifu hadi imara

Mipangilio ya opt-out. Hii ndiyo ya bei nafuu na dhaifu zaidi, kwa sababu inategemea muuzaji kuiheshimu na inashughulikia kategoria iliyokuwepo awali. Iweke mahali ambapo itadumu baada ya reboot na terminal mpya, kwenye faili ya mipangilio ya mtumiaji au kwenye shell profile yako. Ongeza DO_NOT_TRACK=1 wakati uko hapo: ni mkataba ambao zana nyingi za mstari wa amri (command line) huheshimu, ikiwemo baadhi ya mawakala, na haigharimu chochote. Kisha endesha hatua ya 3 tena baada ya update inayofuata, kwa sababu huo ndio wakati ambapo upeo wa ulinzi hubadilika.

Kizuizi cha egress. Hapa unaacha kuomba na kuanza kutekeleza. Endesha wakala kama mtumiaji wake mwenyewe, kisha ruhusu mtumiaji huyo kutumia loopback na DNS na ufunge mengine yote. Hii huongeza jedwali lake lenyewe, kwa hivyo haigusi sheria zozote za firewall zilizopo.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

Itekeleze kwa sudo nft -f /etc/nftables.d/agent.nft, fuatilia kaunta kwa sudo nft list table inet agentegress, na usome matukio ya kufungwa (drops) kwa sudo journalctl -k -g agent-egress-drop. Kaunta ya drop inayopanda yenye hostname ambayo hukutarajia ndiyo lengo kuu la zoezi hili. Kuna mipaka miwili ya kweli. meta skuid inalingana na mtumiaji anayemiliki socket, kwa hivyo inafanya kazi tu wakati akaunti hiyo haiwezi kuwa mtumiaji mwingine: sudo isiyo na nenosiri kwa wakala huifanya sheria hii kuwa pendekezo tu. Na kuacha UDP 53 wazi kwa seva yoyote huacha njia inayoweza kutoa data nje kupitia majina ya query, kwa hivyo ifunge pia ikiwa mfano wako wa vitisho unahitaji hivyo, kwa kuelekeza resolver ya wakala kwenye host unayoiendesha wewe. Orodha za kuruhusu hostname (allowlists) ni bora ziwe kwenye proxy badala ya nftables, kwa sababu API endpoints ziko nyuma ya content delivery networks ambazo anwani zake za IP hubadilika mara kwa mara. Gharama ya kidhibiti hiki ni kukatika kwa huduma na matengenezo: usakinishaji wa vifurushi, git kupitia SSH na ukaguzi wa update wa wakala wenyewe vyote vitafeli hadi utakapoviruhusu, na orodha hiyo sasa ni jukumu lako kuitunza. Ikiwa unaweka hii kwenye seva badala ya laptop, akaunti hiyo hiyo na mpangilio wa firewall ndio msingi wa kuendesha Claude Code kwa usalama kwenye VPS.

Mashine ya muda (disposable machine). Mpe wakala virtual machine (VM) ambayo haina vitambulisho vyovyote unavyojali na inayofutwa mwishoni mwa kazi. Hii haipunguzi kile wakala anachotuma, inapunguza kile wakala anachoweza kufikia ili kutuma, ambayo kwa kawaida ndiyo hatari unayojali. Iunganishe na sheria za egress hapo juu, kwa sababu VM mpya yenye ufikiaji wa Internet usio na kikomo bado inaweza kufikia kila host katika capture yako. Mbinu hii, na hali unayopaswa kujenga upya kila wakati, zimefafanuliwa katika kuendesha mawakala wa coding kwenye VM ya muda, na swali la ukubwa wa rasilimali katika kuendesha wakala wa coding kwenye VPS.

Kujiendeshea model mwenyewe (self-hosting). Hiki ndicho kidhibiti pekee kinachoondoa mtiririko wa inference, kwa sababu prompt haitoki kamwe kwenye vifaa vyako. Gharama yake ni ya kweli: huwezi kujiendeshea model iliyofungwa (closed model), kwa hivyo hii inamaanisha kuchagua open weights na kukubali pengo la uwezo katika kazi ngumu, pamoja na vifaa vya kuiendesha. Biashara hii ya kubadilishana (trade-off) imechambuliwa katika kama unaweza kujiendeshea Claude, na tofauti za uwezo kati ya mawakala wakuu katika jinsi Claude Code, Cursor, Codex na Copilot wanavyotofautiana.

Hakuna hata moja ya vidhibiti hivi vinne inayobadilisha kile wakala anachoruhusiwa kusoma kwenye diski, na trafiki ya inference hubeba chochote anachokisoma. Ikiwa faili ya .env iko kwenye saraka ya kazi, itatumwa kwa model wakati wakala anapofanya grep ya jina la variable. Kuweka nyenzo hizo mbali na ufikiaji ni kazi tofauti, iliyofafanuliwa katika kuweka siri nje ya muktadha wa wakala wa AI.

Mambo ya kukagua baada ya kila update

1. Linganisha kurasa za mipangilio na matumizi ya data za mtoa huduma na zile ulizorekodi mara ya mwisho, ukitafuta swichi mpya na huduma mpya zilizopewa majina.
2. Soma tena mazingira ya mchakato (process environment) kutoka /proc/<pid>/environ ili kuthibitisha kuwa chaguzi zako za kujiondoa (opt-outs) bado zinatumika kwenye mchakato unaoendelea.
3. Chapisha tena faili za mipangilio ya mradi, kwa sababu git pull inaweza kuleta faili ya usanidi ambayo mwenzako ameibadilisha.
4. Endesha ukamataji wa SNI kwa kipindi kimoja kamili cha kazi halisi na ulinganishe orodha ya hostname na ile ya awali.
5. Angalia kaunta ya firewall ya kuzuia (drop counter), kwa sababu lengo jipya kwa kawaida huonekana hapo kabla hujaliona mahali pengine popote.

Hii inachukua takriban dakika kumi na ndiyo sehemu pekee ya mchakato ambayo haipitwi na wakati. Mipangilio chaguomsingi uliyothibitisha mnamo Agosti 2026 ni ukweli kuhusu Agosti 2026. Ukamataji wa data ni ukweli kuhusu leo.

FAQ

Je, ninaweza kuzuia wakala wangu wa uandishi wa msimbo (coding agent) kutuma msimbo wangu kwenye modeli?

Hapana, na mpangilio wowote unaodai kufanya hivyo unamaanisha kitu kingine. Kutuma maelekezo yako (prompt), faili ambazo wakala amesoma, na matokeo ya amri alizoendesha kwenye endpoint ya modeli ndiyo njia ambayo inference hufanya kazi, kwa hivyo kigezo pekee ni nani anayepokea data hizo. Unaweza kubadilisha mpokeaji kwa kuelekeza wakala kwenye akaunti ya wingu ya kampuni au kwenye modeli unayojiendeshea mwenyewe, na unaweza kupunguza kile kinachotumwa kwa kuzuia kile anachoruhusiwa kusoma. Kuzima analytics na ripoti za makosa hakugusi mtiririko huu hata kidogo.

Ninawezaje kuona ni seva zipi wakala wangu wa uandishi wa msimbo huunganisha?

Endesha wakala kama mtumiaji wake wa kipekee wa Linux, kisha nasa TLS ClientHello ya kila muunganisho mpya wakati unautumia: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. Mstari mmoja huonekana kwa kila muunganisho, ukiwa na anwani ya lengwa na hostname iliyoombwa. Linganisha majina na sudo tcpdump -ni any 'udp port 53', ukikamata kwenye any kwa sababu resolver stub ya ndani kwenye 127.0.0.53 hushughulikia ombi hilo kwanza. Fanya ukamataji huo wakati wakala anafanya kazi halisi, kwa sababu pings za kuanza na ripoti za ajali hazionekani katika ukamataji wa wakati wa kutofanya kazi (idle).

Proxy yangu haionyeshi trafiki wakati wakala anafanya kazi. Nini kimeharibika?

Aidha mteja anapuuza HTTP_PROXY na HTTPS_PROXY, au anafunga (pin) vyeti vyake na kukataa CA yako. Jaribu njia hiyo na curl kwanza: ikiwa curl inafika kwenye Internet kupitia proxy na wakala haonekani kwenye orodha ya mtiririko, wakala hatumii vigezo vya mazingira (environment variables) vya proxy. Runtimes zingine zinahitaji CA ipewe kwa njia maalum, na Node hasa husoma NODE_EXTRA_CA_CERTS wakati wa kuanza kwa mchakato pekee, kwa hivyo ku-export baada ya kuzindua wakala hakufanyi kazi yoyote. Wakati proxy haiwezi kuona trafiki, tumia ukamataji wa pakiti (packet capture), ambao hakuna mpangilio wa programu unaoweza kuukwepa.

Je, kuzima telemetry kunazuia msimbo wangu kutumika kwa mafunzo?

Hapana. Analytics na ripoti za ajali ni mtiririko tofauti na inference, kwa hivyo kuzizima huondoa kaunta za matumizi na stack traces, na huacha kila prompt ikielekea kwenye modeli kama ilivyokuwa awali. Ikiwa prompts hizo zinahifadhiwa, na ikiwa zinafunza modeli ya baadaye, huwekwa na masharti ya mpango wako, na mipango ya watumiaji binafsi na mipango ya kibiashara kwa kawaida hutofautiana. Huo ni mkataba wa kusoma badala ya pakiti ya kukamata, kwa hivyo angalia ukurasa wa matumizi ya data kwa mpango wako na, pale inapohitajika, panga mkataba wa kibiashara au wa kutohifadhi data (zero-retention) kabla ya kikao cha kwanza.