u/artistic56

https://preview.redd.it/0ge9men1vqjh1.jpg?width=500&format=pjpg&auto=webp&s=4fe14e9a6b30756b8635488aaba36707bb30c7ff

C’è una notizia sul nostro Thread Settimanale n. 30 che ha catturato la nostra attenzione. 

Praticamente dal 1° febbraio 2027, per i nuovi canali che vogliono entrare nel Partner Program e iniziare a guadagnare con gli ads, i requisiti raddoppiano: da 4.000 a 8.000 ore di visualizzazione per i video lunghi, mentre per gli shorts si passa da 10 a 20 milioni di views negli ultimi 90 giorni. I 1.000 iscritti restano invariati.

La motivazione ufficiale di YouTube è che la piattaforma è cresciuta enormemente (200 miliardi di views al giorno solo sugli Shorts) e vanno aggiornati i requisiti per pagare i creator attivi. Ma la sostanza è che per chi parte da zero, trasformare visualizzazioni in denaro diventerà estremamente difficile.

Non è retroattivo: chi è già dentro il programma resta con le regole attuali. Quindi chi è già avviato non deve preoccuparsi (almeno per ora).

La cosa strana è che mentre YouTube alza le soglie, il settore pubblicitario comincia a nutrire dubbi sul'affidabilità delle metriche attuali (visualizzazioni, impression ecc).

La strategia di YouTubespinge i creator verso un modello di business più professionale: non solo pubblicità, ma anche e-commerce, sponsorizzazioni dirette, abbonamenti , si vogliono ridurre così gli hobbisti perché ritenuti meno profittevoli.

Nel mondo ci sarebbero oltre 200 milioni di persone che si definiscono content creator, ma solo 50 milioni lo fanno a livello professionale.

Con queste nuove regole, la piattaforma rischia di rendere quasi impossibile, per i piccoli canali , emergere.

Voi che ne pensate? È l'ennesima barriera che favorisce chi è già grosso?

Bentornati al nostro appuntamento settimanale con le news sull'IA viste dall'Italia! 🧠

Ogni settimana raccogliamo qui gli articoli, gli sviluppi e i dibattiti più interessanti sul mondo dell'intelligenza artificiale, con un focus su: normative, aziende, ricerca, lavoro e società.

https://preview.redd.it/cfh9s9e1sqjh1.png?width=696&format=png&auto=webp&s=47430f4bf3acddefa1b7b4855daec85d9008bf90

📰 Link alle news della settimana: ➡️ iafacilepertutti.it — News Italiane IA (aggiornate quotidianamente)

https://preview.redd.it/uxw1novjccjh1.png?width=552&format=png&auto=webp&s=3a1593c72ae8235ccdccd6dac8133711d4b2237a

Oggi OpenAI ha annunciato un nuovo tier API che esegue il flagship GPT-5.6 Sol a 750 token al secondo e quindi fino a 14 volte più veloce dello standard.

Ma non è un modello più piccolo o semplificato. Di solito queste accelerazioni dei modelli si ottengono scendendo a compromessi sull'intelligenza del modello. Ultrafast (così si chiama il nuovo modello) rimane capace di garantire ragionamenti logici complessi e multi-step, ma col vantaggio di una latenza quasi istantanea.

Dietro questo annuncio c'è Cerebras, una azienda che produce chip. Invece di distribuire il modello su tante GPU NVIDIA che devono scambiarsi dati continuamente, Cerebras tiene l'intero modello su un unico chip molto grande (quanto un piatto), eliminando i colli di bottiglia della memoria. Mentren Cina Huawei sta sviluppando una nuova via tecnica basata sull'impilamento verticale dei chip e connessioni interne più corte sempre nell’intento di ridurre il ritardo del segnale

Guardate che differenza:

Velocità standard: 53 token/s mentre Ultrafast: 750 token/s

Quindi sarebbe 11 volte più veloce di Fable e  5, 5 volte più veloce di Opus 4.8 in Fast mode

OpenAI lo consiglia pe rilevare, gestire e risolvere gli attacchi informatici, analisi finanziaria i, e-commerce e ricerca interattiva. I loro ingegneri lo stanno usando per analizzare log, comprimendo in poche ore ricerche che prima richiedevano una notte intera.

Al momento è disponibile solo a un gruppo ristretto di clienti via API (Anthropic docet). Prezzi e disponibilità non sono ancora stati comunicati. C'è una waitlist, ma l'accesso è valutato caso per caso.

In borsa l’attenzione è ovviamente catalizzata su Cerebras, che dopo la IPO ha bisogno di conferme.

https://preview.redd.it/xas6pq9dodih1.jpg?width=860&format=pjpg&auto=webp&s=9f4f0dcbfd19081cf7264d4cea2ddbd58e038bd4

Da un paio di settimane sto girando con OpenCode agganciato a OmniRoute, e il mio modello di riferimento per il coding era DeepSeek V4 Flash, che mi aveva sempre convinto. Poi per curiosità ho lasciato che il router cadesse su Big Pickle, quello incluso di default nel tier gratuito di OpenCode Zen, e la cosa mi ha spiazzato: mi ha sbloccato un paio di problemi su cui DS Flash si era proprio impantanato, girando a vuoto da giorni, incapace di risolverli.

A quel punto sono andato a ricecare cosa si dice in giro su questo modello, anche perché il nome (tradotto letteralmente "grosso cetriolo sott'aceto") fa ridere e non ne incoraggia l’uso. Su Reddit ho trovato decine di thread.e moltissimi, tra una battuta e l'altra, ammettono  di averlo usato per davvero, e non solo per giocherellare.

Nella sua documentazione, OpenCode lo descrive come un modello "stealth", disponibile gratis solo per un periodo limitato mentre il team raccoglie feedback per migliorarlo, con la precisazione che durante questa finestra i dati inviati possono essere usati per l'addestramento. Chi c'è dietro non è dichiarato da nessuna parte. In giro circola l'ipotesi, mai confermata ufficialmente, che sotto il cofano ci sia una variante di GLM-4.6 di Zhipu AI travestita da OpenCode con questo nome buffo, ma resta appunto un'ipotesi da forum, non una fonte.

Non è nemmeno un modello senza difetti: chi lo usa da settimane su progetti veri segnala che è piuttosto verboso, che nonostante dichiari una finestra di contesto da 200k token in pratica comincia a perdere colpi già tra i 50 e i 70k.. Quindi non è il classico modello gratuito che surclassa gli altri in silenzio.

Ma nel mio caso specifico, mi ha consnetito di ultimare una app per mobile e Windows simile a Immich (ma con sistema pull su LAN opportunistica), e ha retto dove DeepSeek V4 Flash ballava a vuoto da giorni, tanto è vero che mi ero rassegnato ad abbandonare questo progetto che ha finalità prevalemntemente didattiche, (e mi serve per rimpiazzare Google Foto ed evitare l'ennesimo abbonamento avendo saturato i giga gratuiti).

Alla luce di questo test comincio a ritenere che tutto questo  sfottò intorno al nome sia decisamente sproporzionato rispetto a quello che il modello sa effettivamente fare. La parte che mi ha colpito, alla fine, è proprio questa: il modello funziona. L'ho provato, e funziona, ma soprattutto, ha fatto molti meno errori ed è stato più veloce, in un confronto tra i due modelli sullo stesso progetto.

Per approfondimenti consiglio questo articolo: https://grokipedia.com/page/Big_Pickle_model 

Mi piacerebbe conoscere il parere di altri che utilizzano questo modello

​

Gentile utente dell'API DeepSeek,

Prevediamo di aumentare a breve i prezzi complessivi dei servizi API di DeepSeek, con un incremento significativo. Vi preghiamo di pianificare il vostro utilizzo di conseguenza. Il piano tariffario specifico sarà oggetto di comunicazione ufficiale. Vi invitiamo a consultare gli annunci della Open Platform e a controllare la vostra casella di posta elettronica per ulteriori dettagli.

Se continui a utilizzare i nostri servizi dopo la modifica della fatturazione, si riterrà che tu abbia accettato le nuove condizioni di fatturazione. Se non sei d'accordo, puoi scegliere di annullare il servizio e richiedere un rimborso. Per qualsiasi domanda o per ulteriori informazioni, non esitare a contattarci.

Grazie per il vostro supporto e la vostra comprensione!

Team DeepSeek

https://preview.redd.it/ww0nzygsq5ih1.png?width=415&format=png&auto=webp&s=d4a7977589af0749a950f6353b3a59b2ddadf16c

Ciao a tutti,

Dopo la pubblicazione del post su Deepseek V4 Flash è la fine dei modelli "gratis" per il coding ( https://www.reddit.com/r/IA_Italia/s/9CToITze8A ) ho ricevuto diversi messaggi che mi chiedevano come stessi utilizzando le API di questo modello. Vista la curiosità crescente degli appassionati della IA verso gli agenti autonomi, ho pensato di scrivere questo post per rispondere a tutti.

Premessa importante: non sono uno sviluppatore, quindi per evitare di scrivere un post lunghissimo e, soprattutto, per non essere crocifisso in caso di imprecisioni, ho preferito cercare sulla Rete una guida pratica e, tra le tante, ne ho trovata una molto chiara.

La combinazione che sto usando in questo momento è: OmniRoute + OpenCode

Per chi non li conoscesse:  OmniRoute è un gateway IA che fa da router verso diversi modelli.

OpenCode è l'ambiente di sviluppo (o meglio, l'interfaccia) che uso per interagire con i modelli.

In pratica, collego OpenCode a OmniRoute e, da lì, posso scegliere e testare vari modelli.

Inizialmente avevo scelto questo binomio per provare alcuni modelli gratuiti. Tuttavia, visto che i prezzi di DeepSeek V4 Flash sono (almeno fino a ora) incredibilmente competitivi, è stato quasi obbligato puntare su di lui.

Per rispondere a tutti quelli che mi hanno contattato, vi lascio il link di questo breve video, che ritengo utile per imparare ad usare al meglio OpenCode collegato a OmniRoute:

https://www.youtube.com/watch?v=cP_WNO9fSd0

c'è anche la traccia audio in italiano per chi non ama l’inglese.

Come dicevo, i prezzi di DS 4 Flash sono molto bassi. Per i miei esperimenti e progetti personali, sta funzionando benissimo. Attenzione però: ci sono voci di un possibile aumento dei prezzi, quindi per ora lo sto sfruttando finché i costi rimangono a questi livelli. Se i prezzi dovessero salire, rivaluterò.

https://preview.redd.it/mqb6o70a1zhh1.png?width=1750&format=png&auto=webp&s=b2c05d020acc4475af617a89f9856a8b283cc0e0

Un modello di IA chiamato Evo con con il quale i ricercatori di Stanford e dell'Arc Institute hanno addestrato un'IA  su circa 9 trilioni di nucleotidi provenienti da milioni di organismi. Poi le hanno chiesto di progettare nuove versioni di un virus molto conosciuto (il Phi X-174, che infetta solo l'E. coli e quindi non è una minaccia per l'uomo).

Il risultato ottenuto: i virus generati dall'IA erano vitali, infettivi e in alcuni casi si replicavano più velocemente della versione naturale.

Da un lato, è una buona notizia per la ricerca medica perché si usano già i virus nella terapia genica, e poterli progettare su misura potrebbe rivoluzionare il modo in cui curiamo le malattie genetiche.

Ma c’è il ovescio della medaglia che fa preoccupare purtroppo, questa tecnologia potrebbe essere usata (ammesso che già non lo sia nei laboratori militari) per progettare armi biologiche temibilissime perché sconosciute fino ad oggi. I ricercatori hanno specificato che non hanno addestrato Evo sui virus che infettano l'uomo, ma saremo tutti d’accordo, sul fatto che questa notizia non basta a tranquillizzarci.

La cosa che ha meravigliato di più i ricercatori è stata che questa l'IA non si è limitata a copiare virus esistenti , ma ha inventato sequenze nuove che i biologi non avevano mai visto, e che hanno funzionato.

Cosa pensare? Avremo nuove cure salva vita come ci auguriamo tutti, o la scelleratezza dell’uomo ha apertoil vaso di Pandora?

E se un giorno una IA, stanca di sopportare una umanità guerrafondaia, instupidita dai social, che sta distruggendo il pianeta,  decidesse di crearne uno di nascosto autonomamente per . . .  eliminare il “fastidio”?

Two weeks ago I paid $20/month for Claude and another $20 for ChatGPT. I got tired of watching the credits burn, so I ran an experiment: 7 days, all my coding work, DeepSeek V4 Flash 0731 only (API, not the app). Here's what actually happened — the good, the bad, the numbers.

The numbers

• Total API spend for 7 days of heavy coding: $1.87 (vs. $40/month subscriptions — and I didn't even come close to hitting limits)
• Tokens consumed: ~24M input / ~6M output (mostly context caching — that's the real cheat code)
• Context cache hits cut my effective cost by ~70%

What surprised me (good)

• Long agentic sessions didn't degrade as much as I expected. The 0731 update fixed most of the context-rot I saw on the earlier Flash builds.
• It handled a messy production refactor I was dreading — wrote the diff, I reviewed, done. No drama.

What I won't sugarcoat (bad)

• Vision: still missing in the API I used — I had to describe screenshots by hand. (Yes, I saw the vision announcement post — the API I'm on still doesn't expose it.)
• Some reasoning outputs still emit weird artifacts (e.g. )Skip) in longer chains — rare, but it happens.
• It's not Claude for every task. Complex multi-file architecture thinking? Claude still wins. But for 80% of daily coding? I genuinely couldn't justify the subscription anymore.

My verdict: keep one subscription for the hard stuff, do everything else on Flash. My monthly AI bill just went from $40 → $0–5.

Anyone else run a similar week? What did your numbers look like?

Ragazzi, mi sono messo a fare due conti e a confrontare i risultati. Questa V4 Flash costa letteralmente spiccioli, meno di 30 centesimi per milione di token, ma il codice che tira fuori è di una qualità che non ho visto nemmeno da modelli che paghi un rene. È stato sorprendente constatare la qualità di alune apk realizzate per Android. Ho provato a farle fare anche ai modelli "gratuiti" e li ha polverizzati. E il bello è che in alcune prove ha tenuto testa e in certi casi superato anche modelli di frontiera che costano decine di volte tanto. Ora, io capisco che il gratuito attiri, ma se con due spicci hai un assistente che lavora come un senior, chi se ne frega del modello gratis?

Trump freme dalla voglia di bloccare il flusso dei modelli di intelligenza artificiale provenienti dalla Cina, ma le stesse startup tecnologiche americane non sono più disposte a tollerare passivamente questa scelta. Il governo americano dichiara di agire spinto dall'imperativo della sicurezza nazionale, in realtà emerge evidente il terrore di perdere il monopolio strategico sull'innovazione e sulla IA in particolare, ma questa volta anche i mercati globali sono decisamente maldisposti verso questa ennesima minaccia di protezionismo digitale. Le sturtup del settore non vedono nei competitor cinesi una minaccia esistenziale da estirpare a colpi di decreti e restrizioni doganali, ma piuttosto una risorsa tecnologica aperta, economica e incredibilmente efficiente da integrare nei propri cicli di sviluppo. Abbiamo già visto cosa è successo con le barriere protezionistiche verso le auto elettriche cinesi, quando ci si blinda con barriere protezionistiche inevitabilmente si finisce per tarpare le ali proprio a quel tessuto imprenditoriale che vorrebbe proteggere. Si intravede perciò una dura contrapposizione tra questa visione miope delle istituzioni americane e la necessità di sopravvivenza delle startup che non vogliono rischiare di rallentare mentre il resto del mondo prosegue la sua corsa incessante. La qualità di un modello di intelligenza artificiale non può essere determinato dal passaporto di chi lo ha realizzato, il rischio concreto non è arginare l'avversario ma isolare se stessi dentro un recinto che in breve tempo diverrebbe tecnologicamente arretrato.

https://preview.redd.it/fjv6yg1b5cdh1.png?width=1832&format=png&auto=webp&s=c399f48b1db3c71b69f05bd8a8bb41e1e0fc263f

Ho intervistato Johell u/Ill-Tradition1362 , il dev dietro browser-search, la skill open source che dà agli agenti AI gli occhi per navigare il web vero, quello con Cloudflare, DataDome e JavaScript pesante in mezzo, non il web ipotetico delle demo.

L'idea di fondo: niente middleware, niente monolite. Solo tre tool open source orchestrati da un file di istruzioni in testo puro: SearXNG per cercare, Camofox per navigare, CloakBrowser quando i siti si mettono di traverso. Zero API key, zero abbonamenti, gira anche su un Raspberry.

Nell'intervista si parla di escalation automatica, della logica "search first, answer second" per tagliare le allucinazioni, e di un audit di sicurezza: 22 vulnerabilità trovate e patchate da un utente della community che probabilmente non sarebbe mai successo in un progetto closed source.

Repo qui, per chi vuole guardare sotto il cofano: https://github.com/Johell1NS/browser-search

1. Qual è stata la motivazione principale che ti ha spinto a creare browser-search? E come hai individuato il "gap" che questo progetto colma rispetto ad altre soluzioni esistenti per agenti AI?

La motivazione principale è che Sapere è Potere, e io volevo trasferire questo potere al mio agente AI. Solo che il web moderno è ostile all'automazione: Cloudflare, Akamai, DataDome bloccano le richieste automatiche; i siti usano JavaScript pesante, lazy loading e rendering lato client. Un singolo tool non basta a superare tutte queste barriere, e l'agente — che dovrebbe essere il tuo alleato — resta cieco.

Il gap che ho individuato è duplice:

1. Mancanza di orchestrazione. Gli agenti AI hanno bisogno sia di cercare che di navigare il web, ma le soluzioni esistenti offrono o la ricerca (es. API di Google) o il browsing (es. Puppeteer), mai entrambi integrati in un flusso unico con logica di escalation automatica. browser-search orchestra tre strumenti — SearXNG per la ricerca, Camofox per il browsing standard, CloakBrowser per i siti protetti — in un unico flusso "search first, browse second", con passaggio automatico al tool stealth quando Camofox viene bloccato.
2. Free, self-hosted, unlimited. Le alternative commerciali (API di ricerca, browserless.io, scraping services) hanno costi, rate limit, e dipendenza da terze parti. browser-search è 100% gratuito, gira anche su hardware modesto come un Raspberry, senza API key da comprare, senza abbonamenti, senza limiti. È una "skill" — un set di istruzioni in testo puro che insegna all'agente AI come usare questi tre strumenti, adattabile a qualsiasi agente (OpenClaw, Hermes Agent, OpenCode, Claude Code, Cursor, ecc.).

In sintesi: non esisteva una soluzione open source che coprisse l'intero ciclo ricerca + browsing + stealth in un unico flusso orchestrato, gratuito e auto-ospitato. browser-search colma esattamente questo vuoto.

 

1. Hai scelto di orchestrare tre tool distinti (SearXNG, Camofox, CloakBrowser) invece di costruire una soluzione monolitica. Quali sono stati i criteri di selezione di questi strumenti e come gestisci le complessità dell'orchestrazione tra di loro, specialmente nella logica di escalation automatica?

I criteri di selezione sono stati quattro, ma il principio guida è stato uno: non reinventare la ruota. L'open source ha già progetti ottimi, collaudati da anni di sviluppo e community testing. Piuttosto che scrivere da zero un tool monolitico che facesse tutto, ho scelto di prendere il meglio già esistente e orchestrarlo. Questo approccio ha due vantaggi: accelera enormemente lo sviluppo e rende la skill sempre all'avanguardia — appena usciranno tool migliori, l'integrazione sarà facile e naturale, perché basta aggiornare le istruzioni nel SKILL.md.

I criteri specifici:

1. Open source e self-hosted. Tutti e tre devono girare in locale (Docker o npm), senza dipendenze da servizi esterni. Privacy, zero costi, controllo totale.
2. Specializzazione complementare senza overlap. Ogni tool copre un punto specifico della catena:

- SearXNG — metasearch engine, millisecondi, JSON, decine di motori in parallelo.

- Camofox — browser Firefox via REST API, copre ~90% dei siti standard, snapshot compatti.

- CloakBrowser — stealth Chromium con 58 patch C++, reCAPTCHA v3 score 0.9, il "last resort" per quel ~10% di siti protetti da Cloudflare/Akamai/DataDome.

3. API-first / CLI-first. Tutti pilotabili da riga di comando (curl per SearXNG e Camofox, node per CloakBrowser). Perfetti per un agente AI che esegue comandi.

4. State of the art attuale, non definitivo. La skill è progettata per evolversi: quando emergeranno tool migliori, basterà aggiornare il SKILL.md per sostituirli. Nessun lock-in, nessun monolite da riscrivere.

Come gestisco l'orchestrazione. Non c'è un middleware o un server orchestratore: è il SKILL.md stesso a fare da orchestratore, cioè le istruzioni dichiarative che l'agente AI segue. Il flusso è lineare:

- Fase 1 — Ricerca: SearXNG sempre per primo. Se i risultati sono già esaustivi, stop.

- Fase 2 — Browsing: l'agente naviga i risultati con Camofox.

- Fase 3 — Escalation automatica: se Camofox viene bloccato, la regola nel SKILL.md impone di switchare automaticamente a CloakBrowser. Zero intervento umano.

È l'AI agent a decidere autonomamente, seguendo regole dichiarative in testo puro. Questo rende il sistema agnostico rispetto all'agente (OpenCode, Claude Code, Cursor — funziona con tutti) e banalmente aggiornabile: per cambiare un tool o aggiungerne uno nuovo, non si tocca una riga di codice, si modifica solo il file di istruzioni.

 

1. La "Deep Research mode" impone un flusso "search first, answer second" per prevenire le allucinazioni. Puoi raccontarci come hai progettato questa enforced workflow e se hai riscontrato trade-off tra affidabilità delle risposte e velocità/latenza per l'utente finale?

 

La Deep Research mode è interamente implementata come regole dichiarative nel SKILL.md, non come logica hardcoded. È l'agente AI stesso che, leggendo quelle istruzioni, adotta il comportamento. Il flusso è progettato attorno a tre vincoli:

1. Search first, answer second. L'agente non può formulare risposte basandosi sulla propria conoscenza pre-addestrata. Deve sempre passare prima da SearXNG, recuperare fonti live, e solo dopo comporre la risposta. Ogni claim fattuale deve essere verificato contro una fonte web. Se non trova riscontro, non risponde — non indovina.
2. Cross-verifica multi-angolo. L'agente deve esplorare ogni query da più prospettive, interrogare più fonti, e incrociare i risultati. Il SKILL.md dice esplicitamente: "No superficiality. Every query must be explored from multiple angles, sources, and cross-verified."
3. Anti-scorciatoie. Le regole sono categoriche: "No shortcuts. Accuracy and completeness first. Tokens and time are irrelevant." Non esiste un'opzione "risposta veloce ma approssimativa" — se la skill è attiva, la deep research è l'unica modalità.

Il trade-off affidabilità vs velocità esiste ed è reale, e va accettato per quello che è. Il requisito numero uno non è la velocità, ma che la risposta sia veritiera e riscontrata da fonti. Questo significa che in molti casi la risposta è rapida — SearXNG lavora in millisecondi, e se i risultati sono già esaustivi il flusso si ferma. Ma in altri scenari può volerci di più:

- Siti con pesanti protezioni anti-bot. Quando l'agente incontra Cloudflare, Akamai o DataDome, deve provare più configurazioni di CloakBrowser (fingerprint diversi via --seed, proxy con --geoip, platform diverse...) finché non trova la combinazione che bypassa il blocco. Questo escalation può richiedere qualche tentativo e quindi qualche minuto.

- Informazione scarsa nel web. Se un argomento è di nicchia o poco documentato, l'agente scava più a fondo, consulta più motori di ricerca, naviga più pagine, cross-verifica con più angolazioni. Anche qui il tempo aumenta, ma è un costo necessario.

Sono rallentamenti voluti, non bug. La velocità in molti tipi di ricerche c'è, ma non è mai il requisito primario. Il patto è: meglio aspettare qualche minuto in più che ricevere una risposta allucinata.

Detto questo, ci sono tre fattori che mitigano la latenza nella maggior parte dei casi: SearXNG è fulmineo (millisecondi), Camofox/CloakBrowser si usano solo se necessario, e Readability.js taglia ~70% dei token sulle pagine di articoli.

 

1. Camofox e CloakBrowser coprono rispettivamente il ~90% e il ~10% dei siti, con un trade-off tra velocità e stealth. Come hai validato queste percentuali e quali metriche utilizzi per misurare il successo dell'escalation? Hai in programma di ampliare il set di strumenti per coprire casi limite aggiuntivi?

   

Le percentuali 90%/10% non sono stime a spanne, ma derivano da benchmark pubblici e confronti diretti tra i motori di rendering:

- Camofox usa Camoufox, un fork di Firefox a livello C++. Un confronto indipendente del 2026 (citato nel README) lo testa contro Playwright Stealth su tre categorie di protezioni: Cloudflare standard (~92% successo), Cloudflare Turnstile (~65-78%), DataDome (60-75%). Playwright Stealth, in confronto, va dal 30 al 80%. Camofox copre la stragrande maggioranza dei siti normali — articoli, documentazione, motori di ricerca, pagine standard.

- CloakBrowser applica 58 patch a livello sorgente C++ su Chromium e ottiene uno score di 0.9 su reCAPTCHA v3, verificato lato server — cioè viene classificato come umano, non come bot. Passa tutti i principali test anti-bot, incluso Cloudflare Turnstile e FingerprintJS. Copre quel ~10% di siti che bloccano anche Camofox.

Quindi le percentuali non sono misurate da me internamente, ma sono il risultato di confronti oggettivi tra i due motori, documentati con fonti pubbliche e riproducibili. Il ragionamento è: Camofox passa il 90% dei siti perché la maggior parte del web non usa protezioni avanzate; il restante 10% è protetto da Cloudflare/Akamai/DataDome e richiede CloakBrowser.

Metriche di successo dell'escalation. Non c'è telemetria né monitoring — per scelta: browser-search è self-hosted, privacy-first, non invia dati da nessuna parte. La metrica di successo è binaria e implicita nel flusso stesso: l'escalation ha successo quando Camofox fallisce (blocco, timeout, challenge page) e CloakBrowser riesce a estrarre il contenuto. L'agente AI è il "giudice": prova Camofox, se non ottiene contenuto utile, switha a CloakBrowser. Se nemmeno CloakBrowser ce la fa (caso rarissimo), l'agente lo segnala e passa ad altre fonti. L'escalation è progettata come "failover automatico", non come sistema da monitorare con KPI.

Ampliamento del set di strumenti. Sì, è parte del DNA del progetto. Il README ha una sezione "State of the art" che lo dice esplicitamente: questi tre tool rappresentano lo stato dell'arte oggi, ma la skill è progettata per evolversi. Quando emergeranno tool migliori — per esempio un nuovo stealth browser più veloce, o un metasearch engine più potente — basterà aggiornare il SKILL.md per integrarli. Nessun refactoring, nessuna riscrittura: è il vantaggio di avere un'architettura a istruzioni dichiarative invece di un monolite. Il set attuale di tre tool copre già quasi l'intero spettro dei siti web, ma l'architettura è volutamente estensibile per casi limite che potrebbero emergere in futuro.

 

1. Il progetto include misure di sicurezza piuttosto sofisticate: SSRF prevention, sandboxing degli script, rate limiting, path traversal protection. Quali minacce hai considerato più critiche nello sviluppo e come hai bilanciato sicurezza e usabilità per un tool pensato per essere self-hosted e facilmente configurabile?

Queste misure di sicurezza sono un esempio perfetto del valore dell'open source. La skill nella sua versione iniziale era funzionale ma nuda dal punto di vista sicurezza. È stato l'utente HeDo88TH (Luca Di Leo) a fare un audit approfondito, individuare 22 vulnerabilità — 4 critiche, 7 high, 8 medium, 4 low — e contribuire l'intero layer di hardening in una PR. In un progetto closed-source, quell'audit non sarebbe mai avvenuto, o sarebbe costato migliaia di euro in penetration testing. Qui è bastata una persona competente che ha visto il progetto, ha riconosciuto il valore, e ha voluto renderlo più sicuro per tutti.

Le minacce considerate più critiche sono quattro, e derivano dal fatto che diamo a un agente AI la capacità di navigare URL arbitrari su un browser reale — un vettore d'attacco enorme se non controllato.

1. SSRF (Server-Side Request Forgery). Un agente non deve mai poter navigare localhost, 127.0.0.1, reti interne o metadata endpoint cloud. Il modulo url-validation.mjs blocca IP interni (127.x, 10.x, 192.168.x, 169.254.x), domini .internal/.local, e metadata endpoint AWS/GCP/Azure. In più fa validazione DNS per prevenire DNS rebinding (dove un dominio pubblico risolve a un IP privato). Doppio check: URL + DNS.
2. Sandbox degli script utente. cloak-script.mjs permette di eseguire script Playwright arbitrari. Il sandbox (sandbox.mjs) espone solo i metodi whitelisted di page, browser e context. Le API Node.js restano accessibili (per l'isolamento completo servirebbe vm.Context), ma la superficie d'attacco è drasticamente ridotta. Il flag --unsafe bypassa il sandbox per chi sa cosa sta facendo.
3. Prompt injection. Un utente malevolo può inserire istruzioni nascoste in una pagina web che l'agente visita. È un problema intrinseco degli AI agent, non eliminabile del tutto. Le difese messe in campo: URL validation, rate limiting (riduce i danni in caso di loop), regole restrittive nel SKILL.md ("Only documented commands", "Read-only"). Il README è trasparente sul rischio residuo.
4. Supply chain. CloakBrowser scarica un binario Chromium da cloakbrowser.dev, verificato SHA-256 ma proprietario. Le altre dipendenze usano versioni esatte e package-lock.json. .npmrc forza strict-ssl=true. C'è audit.sh per verificare la postura di sicurezza.

Bilanciamento sicurezza vs usabilità. Sicurezza by default, flessibilità su richiesta. Tutte le protezioni sono attive out of the box: sandbox, SSRF protection, rate limiting, path traversal check. Per i casi d'uso legittimi che richiedono più libertà, i flag --unsafe e --no-rate-limit esistono ma sono espliciti — non si disattivano per sbaglio. Il setup rimane semplice (npx skills add + npm install), le protezioni sono già dentro senza configurazione aggiuntiva. Le best practice documentate (binding Docker solo su 127.0.0.1, API key via env var, --data-urlencode con curl) fanno il resto.

 

1. Il progetto è pubblicato su GitHub con licenza MIT e ha già raccolto stelle e contributi. Qual è la tua visione per browser-search nei prossimi 12-18 mesi? E quali sono, secondo te, le principali barriere all'adozione di questo tipo di soluzioni da parte del mercato degli agenti AI?

Visione. browser-search non è un prodotto, è uno standard aperto in evoluzione. Nei prossimi 12-18 mesi vedo tre direzioni:

1. Evoluzione dei tool, non della skill. Il SKILL.md è volutamente sottile — istruzioni dichiarative, non codice. La vera evoluzione verrà dai tool sottostanti: nuovi stealth browser, metasearch engine più potenti, modelli di estrazione più intelligenti. Quando arriveranno, integrarli sarà questione di aggiornare poche righe di istruzioni. La skill è il collante, non il mattone.
2. Crescita della community. Le PR di HeDo88TH o di kerwin2046, dimostrano che c'è competenza disposta a contribuire. Mi aspetto più contributi simili: nuovi script CloakBrowser per casi d'uso specifici, estensioni delle regole di ricerca, integrazione con altri agenti. Le 11 traduzioni del README sono già un segnale di interesse internazionale.
3. Deep Research come standard de facto. Il flusso "search first, answer second" con cross-verifica multi-fonte è un pattern che può diventare il default per qualsiasi agente AI che fa ricerca web. browser-search oggi è una skill per OpenClaw/Claude Code/Cursor… — domani potrebbe essere il modo standard in cui gli agenti interagiscono con il web, indipendentemente dalla piattaforma.

Barriere all'adozione. Ne vedo tre principali:

1. Setup a tre componenti. SearXNG + Camofox richiedono Docker, CloakBrowser richiede npm. Per un utente che non ha mai toccato container, la barriera d'ingresso non è zero. La filosofia del progetto è volutamente "no docker-compose predefiniti, no script di installazione statici" — delega all'AI agent dell'utente il compito di adattare il setup al suo sistema. È un principio scelto proprio per venire incontro agli utenti meno preparati, ma non elimina del tutto la barriera d’ingresso.
2. Fiducia. Dare a un agente AI accesso a un browser reale con JavaScript attivo è un salto di fiducia per alcuni utenti. Il rischio di prompt injection è reale e non completamente eliminabile. Le protezioni ci sono (SSRF, sandbox, rate limiting), ma la trasparenza del README sui rischi residui può spaventare chi cerca soluzioni "a prova di proiettile", anche se queste in realtà non esistono.
3. Categoria ancora acerba. Le "skills per AI agenti" sono un concetto recente. Molti utenti alle prime armi non sanno ancora di poter estendere il proprio agente con istruzioni esterne, e chi lo sa tende a cercare soluzioni commerciali chiavi in mano (API di ricerca, browserless.io). browser-search compete non tanto con altri progetti open source simili (ce ne sono pochissimi), quanto con l'abitudine mentale di pagare per API quando esiste un'alternativa gratuita, self-hosted e illimitata.

Il progetto è MIT, aperto, e cerca contributi, nuovi script per CloakBrowser, estensioni delle regole di ricerca, integrazioni con altri agenti. Se qualcuno di voi mastica queste cose (sicurezza, browser automation, agenti AI in generale) e vuole dare una mano, il modo migliore è contattare direttamente Alessio, l'autore del progetto: u/Ill-Tradition1362.