---
title: "Am măsurat 30 de sesiuni de Claude Code. Scrierea codului nu e problema, așteptarea e"
description: "Am cronometrat fiecare apel de unealtă din 30 de sesiuni reale de Claude Code. Cifrele arată că partea de scris cod costă sub 2% din timp. Restul e altceva."
canonical_url: https://dmaster.ro/blog/unde-se-duce-timpul-claude-code-masurat
language: ro
type: article
last_updated: 2026-08-13
---

# Am măsurat 30 de sesiuni de Claude Code. Scrierea codului nu e problema, așteptarea e

- AI
- 9 min citire
- 13 august 2026

5.752 de apeluri de unealtă, 16 ore de lucru măsurate secundă cu secundă. 1.864 de operații pe fișiere au durat 11 minute. 55 de așteptări au durat 4 ore și 21 de minute.

**Sanda Sorin Catalin**

Marketing digital, automatizari si dezvoltare web. Ajut afaceri mici sa creasca online cu strategie, nu cu noroc.

[Servicii](https://dmaster.ro/servicii)

Toată lumea discută despre cât de repede scrie AI-ul cod. Nimeni nu măsoară.

Mi-am scris o unealtă care parcurge transcripturile sesiunilor de Claude Code de pe disc și cronometrează fiecare apel, de la momentul în care agentul cere ceva până când primește răspunsul. Am rulat-o pe ultimele 30 de sesiuni de lucru real, pe proiecte de client și pe proiecte proprii.

5.752 de apeluri. 967 de minute petrecute în unelte, adică 16 ore și 7 minute. Cam 32 de minute de unealtă pură pentru fiecare sesiune.

Rezultatul m-a pus pe gânduri, fiindcă nu seamănă deloc cu discuția publică despre subiect.

**Pe scurt**

- 30 de sesiuni, 5.752 de apeluri de unealtă, 967 de minute cronometrate.
- Citit, scris și editat fișiere: 1.864 de apeluri în 11 minute, adică 1,2% din timp.
- Așteptare după om și după sarcini în fundal: 55 de apeluri în 261 de minute, adică 27%.
- Toate cele 12 citiri de sarcină în fundal au atins plafonul de 10 minute. Fiecare.
- Comenzile de shell înseamnă 69% din timp, dar mediana lor e 0,6 secunde. Media e trasă de o coadă lungă.
- Măsurătoarea cronometrează timpul real, deci include și minutele în care eu nu eram la tastatură.

## Ce am măsurat, exact

Claude Code lasă pe disc un transcript pentru fiecare sesiune, în format JSONL. Fiecare apel de unealtă apare de două ori: o dată când agentul îl cere, o dată când sosește rezultatul. Diferența dintre cele două marcaje de timp e durata reală.

Unealta mea împerechează cele două intrări după identificatorul apelului și adună. Nu estimează nimic, nu extrapolează. Dacă un apel a durat 47 de secunde, se numără 47 de secunde.

Am rulat-o pe 30 de sesiuni, pe Windows 11, în august 2026. Proiectele sunt reale: aplicații Next.js, agenți Python, automatizări. Nu sunt teste de laborator.

## Tabelul complet

| Unealtă | Apeluri | Total | Median | p90 | % din timp |
|---|---|---|---|---|---|
| Bash | 3.111 | 517m49s | 0,6s | 30,5s | 53,5% |
| AskUserQuestion | 43 | 156m46s | 1m12s | 9m45s | 16,2% |
| PowerShell | 357 | 149m01s | 3,5s | 55,0s | 15,4% |
| TaskOutput | 12 | 104m07s | 10m00s | 10m00s | 10,8% |
| Subagent | 2 | 17m57s | | | 1,9% |
| Edit | 926 | 7m42s | 0,3s | 1,1s | 0,8% |
| WebFetch | 26 | 4m09s | 5,0s | 15,6s | 0,4% |
| Write | 409 | 2m09s | 0,2s | 0,5s | 0,2% |
| WebSearch | 15 | 1m35s | 6,2s | 8,7s | 0,2% |
| Read | 529 | 1m25s | 0,0s | 0,2s | 0,1% |
| Grep | 31 | 1m04s | 0,1s | 5,4s | 0,1% |

Citește tabelul de jos în sus. Acolo e povestea.

## Partea cu scrisul codului e practic gratis

Citit, scris și editat fișiere înseamnă 1.864 de apeluri. Timpul total al celor 1.864 de apeluri: **11 minute și 16 secunde.** Adică 1,2% din tot.

Mediana la citire e sub o zecime de secundă. Mediana la editare e trei zecimi. Un fișier deschis, citit, modificat și salvat costă mai puțin decât o clipire.

Asta contrazice frontal imaginea populară, în care lucrul cu un agent înseamnă că stai și te uiți cum apare textul pe ecran. Nu stai. Partea aia s-a terminat înainte să apuci să te uiți.

Dacă ai impresia că un agent de cod e lent, aproape sigur nu din cauza asta.

## Unde se duc, de fapt, orele

Două unelte adună 261 de minute din 55 de apeluri. Patru ore și 21 de minute, din 55 de momente.

**AskUserQuestion, 43 de apeluri, 156 de minute.** Asta e agentul care se oprește și mă întreabă ceva. Mediana e un minut și 12 secunde, dar percentila 90 sare la 9 minute și 45. Adică una din zece întrebări m-a găsit plecat de la birou.

**TaskOutput, 12 apeluri, 104 minute.** Aici e cifra care doare. Mediana e 10 minute fix. Percentila 90 e tot 10 minute fix. Ăsta e plafonul uneltei. Fiecare dintre cele 12 apeluri a lovit plafonul, fără excepție. Nu am așteptat un rezultat, am așteptat un cronometru.

Diferența dintre cele două e importantă. Cele 156 de minute de la AskUserQuestion sunt, în bună parte, vina mea: agentul a întrebat, eu nu eram acolo. Cele 104 minute de la TaskOutput sunt un tipar prost de lucru: agentul a pornit ceva în fundal și apoi s-a blocat uitându-se la el, în loc să lanseze și să continue.

Prima se rezolvă cu disciplină de om. A doua se rezolvă cu o regulă scrisă.

## Shell-ul: 69% din timp, dar mediana e 0,6 secunde

Bash și PowerShell adună 3.468 de apeluri și 667 de minute, adică 69% din tot timpul. Pare copleșitor până te uiți la mediană.

Mediana la Bash e 0,6 secunde. La PowerShell, 3,5 secunde. Dar percentila 90 sare la 30,5 și respectiv 55 de secunde.

Traducere: cele mai multe comenzi sunt instantanee, iar totalul e tras în sus de o coadă lungă de comenzi grele. Suite de teste. Build-uri complete. Instalări de pachete. Lint pe tot proiectul.

Din istoric văd că suita completă de verificare a rulat de zeci de ori acolo unde ar fi fost de ajuns o verificare pe fișierele atinse. Fiecare rulare completă costă minute. Fiecare verificare punctuală costă secunde.

## Ce am schimbat după măsurătoare

Am scris cinci reguli în fișierul de instrucțiuni pe care agentul îl citește la fiecare pornire. Nu sugestii, reguli.

**Nu bloca niciodată pe o sarcină din fundal.** Lansezi și continui, aștepți notificarea de finalizare. Fără verificări în buclă. Regula asta singură atacă 104 minute.

**Verificările rulează întâi doar pe fișierele atinse.** Suita completă se rulează o dată, la final, în fundal.

**O singură întrebare, cu mai multe câmpuri**, în loc de trei întrebări pe rând. Fiecare rundă de întrebări oprește sesiunea până răspund.

**Fără invocatoare de pachete când binarul e local.** În același proiect, apelul direct din `node_modules/.bin` costă sub o secundă, varianta prin invocator costă peste patru.

**Fără pauze de așteptare.** Ori o condiție de așteptare reală, ori o notificare. Niciodată o pauză fixă pusă din burtă.

Regulile astea sunt scrise, versionate și citite automat. Nu sunt lucruri pe care mi le amintesc eu. Diferența dintre o regulă scrisă și o intenție bună e exact diferența dintre un sistem și un obicei. Am descris tot mecanismul, cu instrucțiuni, skill-uri, subagenți și servere MCP, în pagina despre [cum lucrez cu Claude Code](https://dmaster.ro/claude-code).

## Ce nu spune măsurătoarea asta

Trei lucruri, ca să nu tragi concluzii greșite.

**Nu măsoară timpul de gândire al modelului.** Cronometrez apelurile de unealtă, nu intervalele dintre ele. Timpul în care modelul se gândește ce să facă nu apare nicăieri în cifrele de mai sus.

**Include timpul meu mort.** Cele 156 de minute de la întrebări conțin minutele în care eram plecat de la birou. Unealta nu poate face diferența între o întrebare grea și un om care s-a dus după cafea.

**E setul meu de date, nu al tău.** Windows, proiectele mele, felul meu de a lucra. Dacă tu lucrezi pe un monorepo cu build de 20 de minute, distribuția ta va arăta complet diferit. Metoda se transferă, cifrele nu.

## Concluzia care rămâne

Am pornit măsurătoarea crezând că voi găsi ceva despre cât de repede scrie modelul. Am găsit că partea aia e sub 2% și nu merită discutată.

Timpul se duce în două locuri: în comenzi grele rulate mai des decât e nevoie, și în momente în care fluxul se oprește și așteaptă pe cineva. Amândouă se repară cu reguli, nu cu un model mai bun.

Dacă folosești un agent de cod și ai senzația că merge greu, măsoară înainte să schimbi ceva. Aproape sigur problema nu e unde crezi.

Dacă vrei fluxul ăsta aplicat pe un proiect real, construiesc [aplicații web](https://dmaster.ro/servicii/aplicatii-web) și [agenți AI](https://dmaster.ro/servicii/agenti-ai) exact așa.

**Intrebari frecvente**

### Cu ce ai măsurat timpul din Claude Code?

Cu un script propriu care parcurge fișierele de transcript ale sesiunilor de pe disc, în format JSONL. Fiecare apel de unealtă apare de două ori, la cerere și la răspuns, iar diferența dintre marcajele de timp e durata reală. Scriptul le împerechează după identificatorul apelului și adună.

### Cât din timp se duce efectiv în scrierea codului?

1,2%. Cele 1.864 de operații de citire, scriere și editare de fișiere din 30 de sesiuni au însumat 11 minute și 16 secunde. Mediana unei editări a fost de 0,3 secunde.

### De ce apar comenzile de shell ca fiind cel mai costisitor lucru?

Fiindcă totalul e tras în sus de o coadă lungă. Mediana unei comenzi Bash a fost 0,6 secunde, dar percentila 90 a fost 30,5 secunde. Comenzile scumpe sunt suitele de teste, build-urile complete și verificările rulate pe tot proiectul în loc de fișierele atinse.

### Ce înseamnă că toate cele 12 citiri de sarcină în fundal au atins plafonul?

Că mediana și percentila 90 au fost amândouă exact 10 minute, adică limita uneltei. Nu s-a așteptat un rezultat, s-a așteptat expirarea unui cronometru. Reparația e să lansezi sarcina în fundal și să continui, apoi să reacționezi la notificarea de finalizare.

### Cifrele astea se aplică și la mine?

Metoda da, cifrele nu. Măsurătoarea e făcută pe Windows, pe proiectele mele și pe felul meu de a lucra. Pe un proiect cu build lung sau cu altă structură, distribuția arată diferit. Ideea e să măsori înainte să optimizezi.

### Măsurătoarea include și timpul de gândire al modelului?

Nu. Sunt cronometrate doar apelurile de unealtă, de la cerere până la răspuns. Intervalele dintre apeluri, în care modelul decide ce face mai departe, nu apar în cifre.

**Vrei să aplicăm asta în businessul tău?**

Programează o discuție de 30 de minute. Analizăm situația ta concretă și îți spun exact ce pași ai de făcut. Gratuit, fără obligații.

[Trimite cerere](https://dmaster.ro/cerere)

**Articole similare**

- AI
  [Voice agent AI în 2026: prețuri Bland AI și Vapi, cum sună în română și ce cere AI Act](https://dmaster.ro/blog/voice-agents-bland-ai-vapi-afaceri-mici-2026): Grila de prețuri s-a schimbat la ambele platforme. Cât costă real un agent telefonic AI, cum sună în română și ce ai voie să faci cu el legal.
- AI
  [Ce sunt automatizările AI și cum funcționează, pe înțelesul tuturor](https://dmaster.ro/blog/ce-sunt-automatizarile-ai): O automatizare AI e un sistem care preia sarcini repetitive și ia decizii de context în locul tău. Afli cum funcționează, ce tipuri există și prin ce diferă de automatizarea clasică, cu exemple simple.
- AI
  [AI Agents în 2026: de ce automatizările „clasice" nu mai sunt suficiente](https://dmaster.ro/blog/ai-agents-in-2026-de-ce-automatizarile-clasice-nu-mai-sunt-suficiente): Zapier Agents, Make Maia, n8n 2.0: în 2026 marketingul a trecut de la workflow-uri pe reguli la agenți AI care decid singuri. Ce se schimbă, ce platformă alegi și de unde începi concret.

---

Pagina HTML: https://dmaster.ro/blog/unde-se-duce-timpul-claude-code-masurat

Index complet: https://dmaster.ro/llms.txt

- D MASTER
- Sanda Sorin-Cătălin Persoană Fizică Autorizată
- CUI: 54245670 · ONRC: F2026013705006
- Sat Giroc, Com. Giroc, Bd. Soarelui nr. 10, Et. 1, Ap. 6, jud. Timiș
- office@dmaster.ro
- (0750) 722 541
- Timișoara, România