מישהו ראה? אני רואה יותר ויותר אנשים שעובדים ככה, יש להם agent ראשי שא…
https://go.chatlytics.ai/r/NGhoDbn
Jacob Coxon (@hilbertspaess) on XI resigned from Anthropic today. I spent the last three years doing pretraining research at both OpenAI and Anthropic. Neither company is ac
https://go.chatlytics.ai/r/keE18QJ
מישהו ראה? אני רואה יותר ויותר אנשים שעובדים ככה, יש להם agent ראשי שאיתן מתכתבים והוא מתכנן אבל הוא רק מנהל עבודה וכל העבודה נעשית בsub agents כאשר כל sub agent רץ ב total isolation אבל משתף מידע דרך context משותף (קבצים לרוב).
יש מישהו שכבר עובד ככה? זה עובד טוב?
Introducing Projects · CursorProjects lets you take on larger bodies of work with a coordinator that maintains context, delegates to subagents, and runs recurring work.
Paperclip
עושים את זה ממזמן לדעתי..
השאלה עד כמה אתה סומך על ה coordinator
זה אפילו יותר high level, מה שאני מדבר פה זה באמצע
אתה עדיין מנהל סיישנים לפי feature אבל מדבר עם agent שהוא זה שמדבר עם ה coding agents
אני עושה את זה במידה מסויימת, אפשר לומר 70% מזה. יש לי קצת יותר מעורבות אבל אני מחפש דרכים להפחית אותה.
הבעיה היא חוסר אמון מצדי.. ייתכן שהוא מיותר..
מקווה שבעתיד הלא רחוק כבר אוכל לסמוך
מה אתה עושה?
אני עובד רק ככה. הפרומפט שלי לקואורדינטור מדגיש שהוא responsible ו-accountable גם על עמידה בפיצ'רים שהוגדרו לו וגם על איכות התוצאה. כלומר, ההגדרה שלו היא שהוא אחראי על כך שהתוצאה תואמת את האפיון ושהיא טובה. מכיוון שהוא לא עוסק באימפלמנטציה אלא ב-planning, חלוקת עבודה ו-review, הקונטקסט שלו לא "מלוכלך" עם הדרך לעשות את הדברים.
בנוסף, בדרך כלל אני מחלק את העבודה לאייג'נטים שהם הרבה יותר חלשים מהאייג'נט של ה-planning ושל ה-orchestration. אין שום צורך שהאימפלמנטציה תיעשה על ידי אייג'נט חזק: ברגע שיש אייג'נט חזק שעשה את התכנון המפורט ומעביר אותו לסאב-אייג'נט, הסאב-אייג'נט לא צריך לעשות את עבודת התכנון, שזו בדרך כלל העבודה הכי מורכבת.
יש לי גם כל מיני timeouts מוגדרים: אם הסאב-אייג'נט רץ הרבה זמן, האורקסטרטור מסתכל על מה שהוא עושה כדי לוודא שהוא לא תקוע, לא רץ בלופים וכולי.
בסך הכול אתה יכול לקחת משימה ולהריץ אותה עם שמונה סאב-אייג'נטס במקביל, שזה גם יותר מהר וגם יוצא בדרך כלל הרבה יותר זול. אתה לא צריך לשלם על Opus או על Sonnet שיעשו לך את כל העבודה, אלא משלם 20% Sonnet ו-80% Llama, DeepSeek או מה שבא לך.
יש לי agentic workflow
ו autonomous loop
המידע מועבר גם דרך קבצים
על איזה פלטפורמה אתה עושה את זה? זה הכל subagents שקמים ויורדים פר טאסק?
אם זה פיצ'ר בודד אז אני כבר רץ לתכנון ופיתוח.
היום כבר כל הטקסיות סביב זה פחתה בגלל שהמודלים הרבה יותר חזקים.
אבל אני כן מקפיד על צ'קליסט לוודא שדברים בוצעו כמו שצריך, שיש self-review, ושיש תיעוד של מה שבוצע (למרות שאת זה אפשר להבין כבר מהקומיטים אבל אם כבר זה בוצע אז תיעוד)
אם מדובר במשהו יותר משמעותי אז מראש מייצר כמה מסמכי תכנון ואז autopilot רץ על כולם
Autipilot גם רץ על ממצאים של audits
Security / refactor / critic
כל חודש אני סוקר את כלל הריפוז ומנקה claude.md מדברים לא רלוונטיים ובודק מה בכלל בכל ה workflow עדיין רלוונטי.
יש משהו אחד שחוזר על עצמו תמיד - תיעוד של באגים.
לאורך חודשים של פיתוח רואים שבאגים שכבר היו לא חוזרים על עצמם. הסוכן טוען שזה בגלל ה gotchas שנכנסו ל claude.md בעקבות באגים שטופלו
אני עובד עם omp.
את החלוקה לסאבאייג'נטים האורקסטראטור מנהל לפי מה שנראה לו מתאים.
לפעמים זה אחד, לפעמים זה 10.
הוא מקבל את הדפינישן, ואז בונה את התכנית.
התכנית צריכה להיות סופר מפורטת.
זה כולל את הקבצים שבהם צריך לגעת, ממש אפילו באילו קלאסים, אילו מודולים, איפה צריך לעשות מה ובאילו אלגוריתמים להשתמש: ממש תוכנית מפורטת.
אחרי שהוא בונה את התוכנית הזאת, הוא מחלק אותה לתת-תוכניות מבודדות ומוסר כל תת-תוכנית כזאת ל-sub-agent. ככה אתה לא חייב sub-agents חזקים, אלא יכול להשתמש ב-sub-agent עם המודל הכי חלש שיש, כי הוא כבר מקבל את ההגדרות שלו מוכנות.
יותר מזה: אם אני רואה שיש sub-agent שעושה יותר מדי reading ו-research, אני משדרג בכל פעם את הפרומפט של האורקסטרטור כדי להגיע למצב שהסוכנים מקבלים את הפרומפטים בצורה כזאת שהם צריכים לעשות כמה שפחות לופים של discovery.
זו המטרה שלי: שה-sub-agents ירוצו ממש מהר ויתקתקו משימות, והאורקסטרטור יקבל את העבודה, יעשה עליה review ויחלק להם תיקונים. הוא גם אף פעם לא סוגר sub-agent, אלא מכניס אותו ל-sleep ואז מוסר את התיקונים לאותו אחד. כלומר, התיקונים תמיד הולכים לאותו sub-agent כדי שזה יהיה יעיל ומהיר יותר.
אם זה מעניין מישהו
על איזה חומרה?
על כמה טוקנים ב output?
צריך ממוצע על הרבה טוקנים, או לפחות כמות טוקנים ממוצעת שהוא פולט באיטרציה. זה נותן תמונה יותר ריאלית.
זאת השוואה בעייתית
כנראה ש gemma יש 4b active
ו qwen הוא dense
אם המודל השלישי לא סיים להתחמם ואתה משווה אותו לשניים הראשונים?
בנוסף כמה זכרון פעיל יש לך זמין משפיע מאוד (איזה חומרה?)
נראה לי ששני התחתונים הם dense
והעליון לא
סודק
בודק*
גמה 26 הוא moe
האחרים לא
Omp מאפשר אובזרביליות לשימוש בקונטקסט? יש איזשהו כלי אינטואיטיבי לזה?
למה התכוונת? מה אתה רוצה להשיג?
את. להמנע מלהיות דבאופס של קונטקסט
זה יכול להתפרש בהרבה מאוד מובנים. אני לא כל כך חווה איזושהי בעיה עם הקונטקסט אצלי, אז בגלל זה אני שואל בדיוק: מה הצרות שאת חווה כרגע שאותן את רוצה לפתור?
הרקע שלי הוא לא פיתוח ובכל זאת אני מוצאת שאחוז ניכר מהזמן שלי הולך על מעקב חלונות קונטקסט לאייגנטים וסאב אייגנטים - מבחינת המידע הנגיש להם, קבצים, עלויות, מודלים. שאלה שלי היא האם יש כלים שיכולים לחסוך לי מעקב
Id like to outsource that to an autonomic agent
זה מודלים ישנים בעולם הlocal llm
ברמת העיקרון יש כמה דרכים להתמודד עם זה:
1. אם הדאטה נמצא בתיקיות שונות, אפשר להפעיל את הסוכן מאותה תיקייה ולהגדיר לו שהוא לא יכול לטייל בשום מקום אחר.
2. מעבר לזה, יש את נושא ה-brain, מה שקוראים לו (אני לא כל כך אוהב את השם). ברמת העיקרון מדובר בייצור של מוח, או נקרא לזה דוקומנטציה, שה-agent קורא כשהוא עולה, ואז הוא יודע איפה כל דבר נמצא ואיפה לחפש.
יש כמה דרכים להשיג את זה:
• מערכות לניהול זיכרון: הסוכנים פשוט זוכרים איפה הם היו ולאן הם צריכים ללכת.
• ברמת הפרומפטים ל-sub-agents: אני מניח שזו לא כזו בעיה ולא צריך לנהל את זה בצורה אקטיבית. אם כל sub-agent יודע בדיוק מה התפקיד שלו, מה מותר לו לעשות ומה אסור לו לעשות, זה כבר פותר חלק מהעניין, כי בסופו של דבר הוא אמור לקרוא את המידע הזה ברגע שמעבירים לו אותו.
אבל ברמת העיקרון, התשובה לשאלה היא שאין כלי אחד שעוזר להתמודד עם קונטקסט. זה משהו שכל ארגון או בן אדם צריך לבנות לעצמו: את הקונטקסט מנג'ר או את המוח של הסוכנים שלו, שידעו להתנהל הכי טוב עם המערכות שלו.
תודה על התשובה המפורטת
הבעיה שאת מתארת היא בדיוק הבעיה שאנתרופיק, OpenAI וכל מעבדות ה-AI מנסות לפתור.
ברגע שהן יפתרו את זה, זה בדיוק מה שיהיה ה-Artificial General Intelligence: הוא ידע לנהל את הקונטקסט של עצמו, ידע בצורה חכמה איזה פעולה לעשות ומתי, ובגדול – יחליף את כולנו.
חחח או super-intelligence ואז יהיה לו את כל הקונטקסט ;)
לא agi זה כשהו מחליף אותנו
ASI זה כשהוא נפתר מאיתנו
Final Numbers with explenation
מה אתה מנסה לעשות?
ניסיתי להבין אם יש מודל יותר טוב מבחינת רספונסיביות ולוגיק, להחליף את הקיים. בניתי אייג'נט שמבוסס על SONNET שמפעיל אייג'נטים שונים למשימות שונות, והכל מחובר לכל חלק בחברה שלי.
אז לכל אחד בחברה יש סוג של אייג'נט שמאיץ את העבודה השוטפת.
יש פה המון פרמטרים...
קודם כל ollama בדרך כלל הכי איטי. נסה sglang.
מקביליות חשוב?
דבר שני - מה הוא צריך לעשות? לכתוב קוד?
עברית חשוב?
הייתי מנסה גם את:
Ornith 1.5
Thinking off
מקביליות חשוב - קוד לא. עברית לא חשוב.
מקביליות זה vllm
ועדיין המודלים האלה מאוד חלשים
תצטרף לקנפג את הסביבה אבל הייתי מנסה sglang/ornith
זה הכי טוב שהצלחתי להוציא מהקופסה הזאת במהירות שסביר לעבוד איתה
תודה
אם קוד לא חשוב לך, תנסה את qwen 3.6 a3b
זה מודל moe הוא יהיה מאוד מהיר לדעתי, אבל לא ממש טוב לקוד בגלל המבנה שלו
Orinth
מודל מדהים מנסיוני
הסתכלתי עכשיו על 1.5
משום מה אין קואנטיזציה רשמית של Unsloth למודל הזה. זה די מוזר, בדרך כלל הקואנטים שלהם ממש טובים.
יש ב NVFP4
הוא חדש
פחות מ חודש
או קצת יותר..
המודל לא חדש. הקוואנטיזציה הזו אולי אבל עובד לא רע.
מחכה כבר שיוציאו משהו עדכני
עשיתי עכשיו קצת משחקים איתו, מעניין סך הכל. ביצועים לא רעים, אבל אני חושב שמבחינת איכות ה-Qwen נותן איכות יותר גבוהה בינתיים — מודל יותר חזק ויותר חכם.
מבחינת המהירות, האורנית' לדעתי פי 2 עד פי 3 יותר מהיר, בגלל שהוא לא מודל דחוס.
- Model: Ornith-1.5-35B-Q4_K_M.gguf (35B total, 3B active MoE)
- Port 57449
- --parallel 2
- --flash-attn on (twice)
- --no-context-shift
- -c 129792 (context)
- --batch-size 4096
- --ubatch-size 2048
- -ngl -1 (all layers to GPU... actually -ngl -1 means "all layers" in llama.cpp? No — -ngl -1 is not standard. Actually negative ngl means "all layers" via gpu-layers-all which is -1.
Yes, -1 = all layers.)
- --fit off
- --metrics
- --slot-save-path cache
- --kv-unified
- --jinja
- --cache-type-k q8_0
- --cache-type-v q8_0 (then overridden later to q4_1)
- --spec-type ngram-mod,draft-mtp
- --spec-draft-n-max 2
- --spec-ngram-mod-n-match 24, n-min 48, n-max 64
- --chat-template-kwargs {"enable_thinking": true}
- --mmproj ... (multimodal)
- --load-mode mmap+mlock
- --threads 12
- --lazy-mode off
- --verbosity 3
תריץ אותו ב vLLM עם הדגלים האלה:
Read-only check done. The running process is PID 80134, serving Ornith-1.5-35B-A3B-NVFP4.
vLLM flag list
Model / server
- serve ornith-ai/Ornith-1.5-35B-A3B-NVFP4
- --host 0.0.0.0 --port 8000
- --served-model-name ornith-1.5-35b-a3b
- --trust-remote-code
- --tensor-parallel-size 1
Compute backend
- --language-model-only
- --moe-backend auto
- --linear-backend auto
- --attention-backend flashinfer
- --kv-cache-dtype fp8_e4m3
- --gpu-memory-utilization 0.45
Sizing
- --max-model-len 262144 (256K context)
- --max-num-seqs 8
- --max-num-batched-tokens 8192
Optimizations
- --enable-chunked-prefill
- --enable-prefix-caching
- --async-scheduling
Speculative decoding
- --speculative-config {"method":"mtp","num_speculative_tokens":2}
- --reasoning-parser qwen3
Chat / tooling
- --default-chat-template-kwargs {"enable_thinking":false}
- --tool-call-parser qwen3_xml
- --enable-auto-tool-choice
- --seed 0
דקה מוציא לך נתוני bench
Benchmark complete. Results against the live 8081 endpoint (same model I run on):
Single (1)
• Total tok/s: 72.1
• Per-core tok/s: 72.1
• Notes: 200 tokens/req
Double (2)
• Total tok/s: 140.3
• Per-core tok/s: 70.2
• Notes: 400 tokens/req
Quad (4)
• Total tok/s: 223.1
• Per-core tok/s: 55.8
• Notes: 800 tokens/req
8-concurrent
• Total tok/s: 331.1
• Per-core tok/s: 41.4
• Notes: 1,600 tokens/req
על איזה חומרה?
Qwen מגיע ל114 ליחיד ומעל 400 באגרגציה
אבל QWEN3.6-35B-A3B דביל רציני והוא לא ממושמע בגרוש
DGX
למה הפריפיל שלך כל כך איטי על תרד אחד? נראה מאוד מוזר. אתה אמור לקבל באזור ה-1400 פריפיל על סינגל
איפה אתה רואה מספרי פריפיל ?
ה 200 לא מייצג פריפיל?
לא זה טוקנים לבקשה…
חכה דקה אני יוציא גם פריפיל.
וגם מספרים חמים וקרים
Clean. The prefill benchmark now measures real GPU prefill throughput (wall time ≈ prefill time since output is 1 token), with 4 samples per size for stable medians. The model accepted all the way up to 64K (context is 256K).
bench_prefill.py — actual GPU prefill throughput
8K
• Prompt tokens: 10,661
• Wall: 1.65s
• Prefill tok/s: ~6,480
16K
• Prompt tokens: 21,311
• Wall: 3.41s
• Prefill tok/s: ~6,220
32K
• Prompt tokens: 42,610
• Wall: 8.30s
• Prefill tok/s: ~5,130
64K
• Prompt tokens: 85,208
• Wall: 22.4s
• Prefill tok/s: ~3,790
Each size ran 4 samples with <1% variance — these are real, low-noise measurements, and the trend is the correct physical one: prefill throughput falls as prompt length grows (KV-cache build cost compounds).
The corrected picture
- Prefill (clean): 3,790 → 6,480 tok/s depending on prompt length.
- Generation: 88 tok/s (c=1), 55 (c=4), 41 (c=8).
- The gap is real now: prefill is genuinely 70–150× faster than generation, not 2× — and definitely not the contaminated 8–10× you caught. The earlier prompt/TTFT with a 72-token prompt was dominated by frontend/tokenization/first-token overhead; this large-prompt run removes that noise and shows the true GPU decode rate.
- Main useful number stands: c=8 reaches 317.8 aggregate decode tok/s, ~3.6× single-request throughput.
Two ready-made benchmarks on the system now:
- bench.py — TTFT + decode throughput across concurrency (1/4/8).
- bench_prefill.py — actual GPU prefill rate across prompt sizes (8K–64K).
נחמד מאוד
הוא לא רע הDGX
קטן אבל גדול
הרעיון איתו זה לכתוב אוטומציות או פרומפטים ולציין לו ככלל תמיד דרך ההרמס שהוא יכול לעבוד במקבילות עד 8 (אצלי בכל אופן) הוא כבר יבחר מה ירוץ סיריאלי ומה ירוץ מקביל.
הוא קורא לזה Children משום מה במקום SubAgents
המספרים טובים יותר ב MTP=3 אבל אני מזהה בעיות יציבות אז עד שיוצא תיקון לא נוגע בMTP
הבעיה ביציבות של MTP היא לא עניין של תיקון, זה עניין מובנה בעצם העובדה שמדובר במודל MoE.
במודלים של MoE, ה-MTP כהגדרה יהיה הרבה פחות יציב מכיוון שאתה אף פעם לא יודע לאיזה expert הרשת תלך, ולכן מאוד קשה לחזות את הטוקנים הבאים ולכן הפגיעות יהיו הרבה יותר נמוכות.
MTP עובד טוב בעיקר עם מודלים דנס.
זה נובע אצלי ממקור אחר,
לא תלוי מודל אם כן MOE או לא.
הוא קורס בדחיסת קונטקסט.
לא כל הזמן, לפעמים.
זה ההסבר של אדון Orinth
DGX Spark / GB10 (SM121) → NVFP4 model → Marlin FP4 fallback → FlashInfer → FP8 KV → MTP=3 → long-context / Hermes compaction.
The important points were:
* Once the conversation/context got very long — around the ~65,535-token region in our testing — the MTP path could crash during/around context compaction.
* Running the same long-context path without MTP succeeded, which strongly implicated speculative decoding rather than the model’s context limit or VRAM exhaustion.
* On GB10, our vLLM build was routing NVFP4 through Marlin instead of a native Blackwell FP4/CUTLASS kernel. That was a vLLM/build-support gap on SM121; this exact fallback behavior has also been reported upstream.
* There are also upstream SM121 reports where FlashInfer + MTP causes illegal-memory-access crashes, while changing the attention backend avoids the crash.
מלא אנשים בפורום של Nvidia חוו את זה אני לא היחיד.
ניסית sglang?
עם mtp 3 עובד לי לא רע ובבנצ' מפני כמה שבועות זה עלה כיותר יעיל מ vllm.
אנסה להעמיס עליו compactions לבדוק מה שאתה אומר
אנסה כשתתפנה מכונה 😀
בכל אופן לא חושב שתראה שינוי דרמטי מ vllm.
לכמה Tok/s אתה מגיע על thread אחד?
מעל 100
עם אורינט ?
טוב
אם ככה במקביל 8 אתה תתקרב ל 400
Sglang
יודע לעבוד בקלאסטר ?
לא שזה חשוב כרגע אני עם DGX אחד
אבל מי יודע מה ילד יום
וואי וואי מה התחלתי 🤣🤣
תבורך על זה
כולנו מרוויחים מזה
לגמרי
התחלתי עם קוד לא חשוב לי, וסיימתי עם קוד חשוב מאוד בוא נחסוך בעלויות, וארכיטקטורה שלמה מסביב לזה. עם שני איגנטים לוקאלים, אחד שיעזור בניהול השוטף של החברה, והשני לקודינג, שינווט בקשות מורכבות יותר ל fable ו astra לטובת תכנון, וחקר וכו, ויממש את הקוד בשוטף.
כמו כולנו…
״תאכל…״
״אני לא רעב״
״טוב תביאי עוד פיתה״ 😂
בקטנה כזה
לא הזכרתי את ה pi, ניהול חשבונות אוטומטי וכו.
מהניסיון שלי, תוכנית שהיא יותר מדי מפורטת לפעמים כבר גורמת לבעיות.
צריך למצוא את האיזון בין תוכנית מפורטת מדי לבין מפורטת מספיק.
יש כאן עוד נפגעי Goal Mode של OpenAI ? בחיי שזה סקאם של טוקנים.
אני, אבל התוצאה כלכך טובה שאין לי בעיה לחכות
אתה לא מבין כמה הרגעת אותי עכשיו…
אצלי גם כל שלב עובר review עם קלוד לפני ואחרי כתיבת הקוד
אז בגלל זה לוקח הרבה זמן
כמה צריך לחמם מספר ב019 בהודעות whatsapp לפני שאני מעביר אותו לשימוש של הagent?
רק שתדע שזה אחרי שינוי מלא של סוויטת הבדיקות למצב xdist 8
אחרת הוא רץ שבוע
מסתבר שכיום אני יכול לשים שתי חשבונות whatsapp בתוך אותה תוכנה, אפילו בלי קומבינות
אל תשכח שמי שכותב את התוכנית זה לא אני, זה סוכן שכותב אותה בשפה של סוכן אחר, מבין?
בסופו של דבר ראיתי שככל שהמודל חזק יותר, ככה הוא צריך תוכנית פחות מפורטת. יותר מזה: אם נותנים לו תוכנית מאוד מפורטת, זה מבלבל אותו והוא עושה עבודה פחות טובה. בגלל זה מודלים כמו Astra או Fable צריכים תוכניות מאוד פתוחות, כלומר הם צריכים כיוון ואז הם יכולים לרוץ.
לעומת זאת, מודלים כמו DeepSeek, Qwen, GLM או אפילו Luna צריכים תוכנית מאוד מאוד מוגדרת. אם לא נותנים להם תוכנית מוגדרת הם פשוט מתחרפנים מלקרוא, ואתה תראה שהם מבלים 90% מהזמן בלקרוא את הקוד ולא בלכתוב אותו. מה שקורה זה שבגלל שאת המודלים האלה חייבים לשים על reasoning מאוד מאוד גבוה, הם מתחילים לפקפק בפעולות של עצמם, ולוקח להם המון זמן (אם בכלל) עד שהם מגיעים אשכרה לבצע את העבודה.
לכן אני אומר:
1. כשמדובר בסוכן חזק שמוסר עבודה לסוכן חזק אחר, אפשר לעשות תוכנית לא מפורטת.
2. כשסוכן חזק מוסר עבודה למודל שהוא חלש בהגדרה, צריך לתת למודל החלש תוכנית מאוד מוגדרת.
ככה הוא מתמודד עם זה הרבה יותר טוב, ואת ה-reasoning שלו הוא מבלה בלכתוב קוד נורמלי במקום לנסות להבין מה הפיצ'ר שאתה רוצה לבנות.
יותר זמן מאשר כמות הודעות
מסכים, לא יודע מה זה אומר תוכנית, אני כבר הרבה זמן לא כתבתי מסמך שהוא תוכנית
מדבר איתו 2 דקות על איך מממשים את השינוי, בדרך כלל זה כבר 60% מהדרך לשינוי עצמו
אנחנו לא מחממים
גם אני לא כותב תוכניות, האורקסטראטור (orchestrator) כותב אותן, ואני קורא אותן ועובד איתו עליהן כדי שהוא יתקן אותן. אחרי שאני מאשר לאורקסטראטור את התוכנית, הוא פשוט מריץ אותה.
הוא בעצמו אסור לו לכתוב שורת קוד. זה ליטרלי (literally) יש לו hook שמונע ממנו לכתוב שורת קוד אחת. הרעיון הוא רק אורקסטרציה (orchestration) כתיבת תוכניות וריוויו על עבודה.
בניתי מערכת שלמה מסביב לדבר הזה שעוזרת לי לעבוד עם המודל ועם אנשים נוספים על התוכנית, ובקרוב אני הולך לאפשר לאנשים נוספים להשתמש במערכת הזאת, לא יודע לכמה אנשים, תלוי. נראה כמה השרת שלי יסחוב.
כן לא יודע אני לא עובד ככה 🤷♂️ אין דרך נכונה
בטוח? לא אמרו שצריך? שאחרת נחסמים?
בינתיים לא נחסמים
לקבל הודעות פנימה מכמה מספרים זאת אינדיקציה טובה שזה לא בוט מניסיוני.
לא רק החוצה
איזו תוכנה? אתה עדיין צריך שהמספר יהיה בטלפון, לא?
באפליקצייה וואטסאפ הרגיל, לא business
ה risk surface המרכזי שלך הוא הודעות יוצאות בבת אחת להרבה משתמשים ודיווח על ספאם
כל עוד הוא מקבל הודעות ומגיב, אתה פחות חשוף
כן כן