Mga Madalas Itanong

Oo. Nagbibigay ang WebBrain ng katulad na AI browser agent capabilities — pagbabasa ng mga pahina, pagkuha ng datos, pag-click sa mga button, pagpu-puno ng form, at pag-automate ng multi-step na workflow. Hindi tulad ng proprietary Claude browser plugin na nangangailangan ng Claude Pro subscription at gumagana lamang sa mga modelo ng Anthropic, ang WebBrain ay ganap na libre, open-source (MIT license), at sumusuporta sa maraming LLM provider kasama ang mga lokal na modelo na buong-buong tumatakbo sa iyong makina.

Magkaibang kategorya ng tool ang mga ito. Ang WebBrain ay isang browser extension — iinstall mo ito sa Chrome o Firefox at makikipag-usap sa side panel, walang coding na kinakailangan. Ang mga framework tulad ng OpenClaw at Browser-Use ay mga developer SDK para sa paggawa ng automated browser pipelines sa Python, kadalasang gumagamit ng headless browser at CDP. Isipin mo na lang: ang WebBrain ay para sa pang-araw-araw na pagba-browse kasama ang AI assistant; ang mga agent framework ay para sa paggawa ng scraping bot at test automation. Maaari mong gamitin ang dalawa — komplementaryo ang mga ito.

Oo. Mayroong WebBrain Chrome version (Manifest V3, gamit ang sidePanel API) at Firefox version (Manifest V2, gamit ang sidebar_action). Magkapareho ang mga tampok ng dalawang bersyon. Ang Firefox version ay maaaring i-load bilang temporary add-on para sa development, o i-publish sa addons.mozilla.org para sa permanenteng pag-install.

Buksan lang ang anumang web page, buksan ang WebBrain side panel, at tumanong gamit ang natural na wika: "Kunin ang lahat ng pangalan at presyo ng produkto sa pahinang ito", "Kunin ang lahat ng email address sa pahinang ito", o "Mag-summarize ng artikulong ito sa bullet points". Babasahin ng AI agent ang nilalaman ng pahina, mauunawaan ang istruktura, at ibabalik ang nakuhang datos. Para sa mas kumplikadong scraping, lumipat sa Mode ng Pagkilos at ang ahente ay maaaring mag-navigate sa pagitan ng mga pahina, mag-click sa mga pagination button, at mag-aggregate ng datos sa maraming pahina.

Sa 7.0.0, hindi pa. Ang dry-run mode ay planado at nasa roadmap na.

Talagang pwede! Naka-MIT license ang WebBrain at tumatanggap ng mga contribution. Tingnan ang GitHub repository para sa mga issue, feature request, at contribution guidelines.

Ang WebBrain Cloud ay kasalukuyang $5/buwan bawat profile ng device, mas mura kaysa Claude Pro sa ngayon. Kasalukuyang unlimited ang paggamit sa ilalim ng fair usage policy: ayos ang normal na personal na paggamit, pero hindi pinapayagan ang abuso, automated na sobrang paggamit, resale, o hindi pangkaraniwang mataas na volume.

Naka-link ang subscription sa device identifier na ginagawa ng extension para sa browser + OS GUID na iyon, hindi sa user account. Kung mawala ang identifier dahil ni-reset mo ang extension storage, binura ang browser profile, muling in-install ang browser, nagpalit ng browser/OS, o nawala ang device, hindi namin ito mare-retrieve o maililipat at walang refund para sa pagkawala na iyon.

Pamahalaan ang billing sa api.webbrain.one/account at mag-log in gamit ang iyong email.

Ang Cloud Sync ay opsyonal na feature para sa aktibong subscribers ng WebBrain Cloud. Sinisi-sync nito ang iyong WebBrain memories, Profile auto-fill text, at suportadong provider configuration, kasama ang API keys. Hindi nito sine-sync ang chat history, browser history, page screenshots, o legacy OAuth access at refresh tokens.

Ine-encrypt ng browser ang sync vault bago i-upload gamit ang password na pipiliin mo. Ang WebBrain Cloud ay nag-iimbak lang ng naka-encrypt na vault; hindi nito mababasa ang iyong memories, profile text, provider settings, o API keys, at hindi nito mababawi ang sync password para sa iyo.

Ang email field ay para sa WebBrain Cloud magic-link billing/subscription authentication. Hindi ito account password. Kung sinasabi ng UI na magpalit ng password sa Cloud Sync, ang ibig sabihin ay ang sync encryption password, hindi WebBrain account password.

Kung makalimutan mo ang sync password, hindi na maide-decrypt ang lumang naka-encrypt na cloud vault. Maaari mong i-reset ang cloud vault at mag-upload ng bagong naka-encrypt na kopya mula sa device na mayroon pa ring data nang lokal.

Tatlong magkakahiwalay na layer:

Mga screenshot na pinatipid sa tokens. Bago umalis sa iyong makina ang anumang larawan, binabago ng WebBrain ang sukat nito (may cap sa shorter side, pinapanatili ang aspect ratio) at iteratively na nila-JPEG-compress hanggang kasya ito sa per-turn image-token budget. Ang isang 2000×1200 na screenshot na gagastos ng ~1,500 input tokens sa GPT-4o ay napi-compress sa ~300–500 tokens na walang praktikal na pagkawala para sa mga gawaing nagbabasa ng pahina. Ipinatupad sa _fitImageDimensions kasama ang unit tests para sa budget math.

Matalinong context trimming. Ang kasaysayan ng usapan, output ng mga tool, at mga inline DOM dump ay limitado per turn at binabawasan na nag-uunang sa pinakamatandang kapag ang context window ng aktibong modelo ay malapit nang mapuno. Hindi mo makikita na ang isang run ay tahimik na lumaki mula 10k tokens patungong 100k dahil nagbalik ang read_page ng isang artikulong kasinghaba ng nobela.

Nakalaang vision model. Magsama ng murang text model (hal. GPT-4o-mini) para sa pagpaplano at tool calls sa isang hiwalay na vision-capable na modelo (hal. GPT-4o) para lang sa mga screenshot, kaya hindi mo babayaran ang presyo ng multimodal-model sa bawat turn. I-configure sa ilalim ng Settings → Vision.

Net result: mananatiling predictable ang mahahabang sesyon sa cloud providers. Para sa buong kontrol, gamitin ang llama.cpp nang lokal — zero ang cost per token.

Oo. Ang default na provider ng WebBrain ay ang llama.cpp na nagpapatakbo ng lokal na AI model sa iyong computer. Walang kailangang API key, walang kailangang internet para sa AI, at walang dataong umaalis sa iyong makina. Mag-download lang ng GGUF model, simulan ang llama-server, at meron ka nang isang ganap na pribadong AI browser agent. Maaari mo ring gamitin ang Ollama gamit ang OpenAI-compatible endpoint nito.

Sinusuportahan ng WebBrain ang apat na uri ng provider: llama.cpp (anumang lokal na GGUF model), OpenAI (GPT-4o, GPT-4, atbp.), Claude (Claude Opus, Sonnet, Haiku sa pamamagitan ng native API), at OpenRouter (access sa 100+ models mula sa iba't ibang provider). Anumang OpenAI-compatible na API endpoint ay gumagana, kaya magagamit mo rin ang mga serbisyong tulad ng Together AI, Groq, Mistral, o anumang lokal na server na may OpenAI-compatible interface.

Sa petsang Abril 21, 2026, ang nangungunang rekomendasyon ay ang Qwen 3.6 35B. Dahilan: sa aming vision benchmark (vision-model-shootout), nadaig nito ang Gemma 4 sa pag-unawa sa mga screenshot habang nananatiling praktikal para sa lokal na inference.

Para sa mga consumer GPU, perpekto ang RTX 5090, at madalas na pwede ang RTX 4090 gamit ang INT4 AutoRound quantization sa pamamagitan ng Intel/Qwen3.6-35B-A3B-int4-AutoRound.

Para sa max speed, inirerekomenda naming i-serve ito gamit ang vLLM. Halimbawang command:

python -u -m vllm.entrypoints.openai.api_server --model Intel/Qwen3.6-35B-A3B-int4-AutoRound --served-model-name qwen3.6-35b --quantization auto --dtype bfloat16 --max-model-len 65536 --max-num-batched-tokens 32768 --max-num-seqs 4 --host 0.0.0.0 --port 8000 --gpu-memory-utilization 0.92 --enable-prefix-caching --enable-chunked-prefill --limit-mm-per-prompt '{"image": 4, "video": 1}' --mm-processor-cache-type shm --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder --trust-remote-code --allowed-origins '["*"]' --speculative-config '{"method": "dflash", "model": "z-lab/Qwen3.6-35B-A3B-DFlash", "num_speculative_tokens": 15}' --attention-backend flash_attn

Opsyonal ang DFlash speculative decoding.

Dahil hindi pa namin itinuturing na sapat na mahusay ang in-browser WebGPU text inference para sa karamihan ng mga user, at ayaw naming pagtiisan ninyo ang mahinang karanasan. Kung gusto ninyong gamitin nang lokal ang parehong LFM2.5 2.6B model, patakbuhin ang inference sa inyong computer gamit ang llama.cpp o Ollama at ituro ang WebBrain sa lokal na endpoint na iyon sa halip na umasa sa WebGPU.

Available pa rin ang WebGPU vision fallback dahil mas maliit ang model nito at paminsan-minsan lang ginagamit ang fallback.

Kung ang iyong LLM server ay nasa ibang makina sa iyong lokal na network (hal. http://192.168.1.x:8000), hinaharangan ng Chrome ang request maliban kung magpadala ang server ng CORS headers. Ang ayos ay depende sa iyong server:

vLLM: Simulan gamit ang --allowed-origins '["*"]' (ang value ay dapat na JSON list).
Ollama: Itakda ang environment variable na OLLAMA_ORIGINS=* bago magsimula.
llama.cpp: Naka-enable ang CORS by default — walang kailangang baguhin.

Kung tumatakbo ang iyong server sa localhost (parehong makina ng browser), kadalasan ay hindi kinakailangan ang CORS. Ang isyu ay para lamang sa cross-machine na koneksyon sa lokal na network. Tiyaking nagtatapos sa /v1 ang base URL sa setting ng WebBrain (hal. http://192.168.1.47:8000/v1). Exception: Maaaring kailanganin pa rin ng Ollama na ginagamit mula sa browser extension ang OLLAMA_ORIGINS; tingnan ang Ollama FAQ sa ibaba.

Maaaring i-reject ng mga bagong bersyon ng Ollama ang mga request mula sa browser-extension origins kahit tumatakbo ang Ollama sa parehong makina. Nagpapadala ang extension ng Origin tulad ng chrome-extension://... o moz-extension://..., at maaaring sumagot ang Ollama ng 403 kung hindi pinapayagan ang mga origin na iyon.

Isara muna ang anumang Ollama desktop app na gumagamit na ng port 11434, pagkatapos ay simulan ang Ollama gamit ang isa sa mga command na ito:

OLLAMA_ORIGINS="*" ollama serve
OLLAMA_ORIGINS="chrome-extension://*,moz-extension://*" ollama serve

Panatilihing http://localhost:11434/v1 ang Ollama base URL sa WebBrain. Maaaring gumana pa rin ang mga curl check sa terminal kahit wala ang setting na ito dahil hindi sila nagpapadala ng browser-extension origin.

Oo. Ang read-only na network tools ng WebBrain — fetch_url at research_url — ay ipinapadala rin bilang standalone na LM Studio plugin sa webbrain/web-tools. I-install gamit ang lms clone webbrain/web-tools at i-on sa anumang LM Studio chat — anumang tool-capable na modelo ay maaaring tumawag sa dalawang tool na ito nang hindi mo kailangang i-install ang browser extension. Pure Node, walang headless browser. Source: lmstudio-plugin/.

Oo — ang sidebar ng Firefox ay nasa kaliwa by default, ngunit maaari mo itong i-flip. Mag-right-click kahit saan sa header ng sidebar at piliin ang Move Sidebar to Right (o gamitin ang View → Sidebar → Move Sidebar to Right mula sa menu bar). Mananatili ang posisyon kahit pagkatapos mag-restart. Ang sidePanel ng Chrome ay nasa kanan by default at hindi maililipat ng user mula sa panel mismo.

Oo. Hinaharang ng Vivaldi Web Panels ang mga native JavaScript dialog gaya ng confirm(), alert(), at prompt(). Hindi na umaasa sa mga dialog na ito ang paglipat sa Ask, Act, at Dev mode ng WebBrain, pero umaasa pa rin dito ang ilang secondary action.

Recording: Huwag munang gamitin ang /record sa Vivaldi. Kapag pumalya ang recording, maaaring itago ng Vivaldi ang error alert at walang maipakitang paliwanag.

Settings, History, Traces, at Ollama handoff: May native dialogs din ang mga page na ito, pero karaniwang binubuksan sila ng WebBrain bilang regular na tabs kung saan gumagana ang mga ito. Kung manu-mano mong inilagay ang isa sa Web Panel, buksan muna ito sa regular na tab bago gumamit ng action na umaasa sa dialog.

Kadalasan, oo — lalo na sa Ask mode para sa mga read-only na kahilingan gaya ng “Ibuod ang pahinang ito.” Maaari kang magpatuloy sa pag-scroll habang gumagana ang WebBrain.

Kailan ko ito dapat iwasan? Ang mga auto-screenshot ay nakabatay sa kasalukuyang viewport ng tab. Habang aktibong sinusuri o ginagamit ng WebBrain ang nakikitang content sa Act o Dev mode, maaaring mailipat ng pag-scroll ang target o mabago ang nakikita ng modelo. Hintaying matapos ang hakbang na iyon bago mag-scroll; sa labas ng mga sandaling iyon, maaari mong patuloy na gamitin ang pahina.

Oo. Simula sa bersyong 27.0.0, iniiwasan ng WebBrain na agawin ang focus sa mga browser na nakabatay sa Chromium at sa Firefox maliban kung talagang kailangan ang foreground access. Nananatiling nakatali ang run sa tab kung saan ito nagsimula, kaya ligtas kang makakapagtrabaho sa ibang tab.

Kung kailangan ng isang pambihirang hakbang na nasa harapan ang orihinal na tab, maaaring pansamantalang ituon dito ng WebBrain ang focus. Iwasang mag-click o mag-type sa parehong tab habang aktibong kumikilos dito ang WebBrain.

Cookie banners: Tinutukoy ng WebBrain ang consent banners mula sa mga karaniwang framework (OneTrust, Cookiebot, Didomi, Quantcast, Google Funding Choices, TrustArc) at isinasara ang mga ito bago mag-reason tungkol sa pahina. Ang priority ay "Reject all" / "Reject non-essential" / "Only necessary" kapag malinaw na nakikita; bumabalik ito sa "Accept all" sa halip na maglaho sa "Manage preferences" na maze.

Paywalls: Tapat na inulat ng WebBrain ang paywall at sasabihin sa iyo kung ano talaga ang nakita nito (headline, dek, mga unang talata). Hindi nito sinusubukang i-bypass ang mga paywall — walang archive.today, 12ft.io, pagtatanggal ng cookie, pag-disable ng JS, o reader-mode tricks. Kung gusto mo ang buong artikulo, mag-log in gamit ang subscription o hilingin sa WebBrain na maghanap ng libreng coverage ng parehong kwento.

May tatlong mode ang WebBrain. Ang mode ng Pagtatanong (default) ay read-only at hindi maaaring baguhin ang pahina. Ang mode ng Pagkilos ay nagpapahintulot ng browser actions gaya ng pag-click, pag-type, at pag-navigate, habang nagdaragdag ang Dev mode ng page-debugging tools. Ang mga action na may epekto ay nangangailangan ng approval by default; kapag pinatay ang permission gate na ito, nagpapakita ang WebBrain ng nakikitang warning banner. Maaari mong itigil ang ahente anumang oras gamit ang Stop button. Ang source code ng extension ay buong nakabukas sa GitHub para sa audit.

Para makakilos nang maaasahan sa isang pahina, ginagamit ng WebBrain ang Chrome DevTools Protocol (CDP) sa pamamagitan ng karaniwang extension API na chrome.debugger — iyon ang nagpapalabas ng banner ng Chrome na «WebBrain started debugging this browser». Sa pamamagitan ng CDP, nakakapag-click at nakakapag-type ang ahente gamit ang mga pinagkakatiwalaang input event na talagang tinatanggap ng mga makabagong site; ang mga synthetic na event mula sa content script ay tinatanggihan ng maraming site, ng Web Components, at ng mga field na kontrolado ng framework. Dito rin kumukuha ang WebBrain ng pixel-accurate na screenshot para sa vision fallback at umaabot sa cross-origin na iframe at shadow DOM na hindi nakikita ng mga content script.

Ang read-only na mode ng Pagtatanong ay hindi nangangailangan ng CDP — ang pagbabasa ng pahina at ng accessibility tree ay dumadaan sa karaniwang content script. Ang nangangailangan nito ay ang pagiging maaasahan ng mode ng Pagkilos at ang cross-origin na gawain, at sa isang Manifest V3 extension ay walang API na walang debugger para sa pinagkakatiwalaang input. Ikinakabit ng WebBrain ang debugger kapag kailangan lang ito ng isang aksyon, bawat tab, at open-source ang buong extension kaya maa-audit mo nang eksakto ang ginagawa ng session. Makapangyarihan ang CDP, kaya itinuturing naming dapat limitahan ang bakas nito (ikabit kapag kailangan, ilayo ang pagbabasa rito), at ang higit pang paghihigpit dito ay nasa aming security roadmap.

Ang mga prompt ng pag-apruba ay para sa iyong kaligtasan. Kahit sa mga site na pinagkakatiwalaan mo, maaaring gayahin ng mga mapaminsalang aktor ang mga tagubilin ng LLM o mag-inject ng content na sumusubok na ipagawa sa agent, sa ngalan mo, ang mga bagay na hindi mo aaprubahan. Kaya humihingi ang WebBrain ng pag-apruba bago ang mga consequential action. Kung ayaw mo pa ring dumaan sa mga prompt na ito, maaari mo itong i-disable: buksan ang side plugin, i-click ang icon na gulong sa header, pumunta sa tab na Permissions sa settings.html, at i-off ang opsyong Ask before consequential actions.

Bilang default, ang WebBrain ay palaging dumadaan sa nakikitang UI para sa anumang aksyon na gumagawa, nagbabago, nagtatanggal, nagpapadala, nagpo-post, o bumibili ng anuman. Magna-navigate ito sa pahina, magpu-puno ng form, at magki-click ng button — eksakto kung paano mo gagawin. Tumatanggi itong tumawag ng mga REST/GraphQL endpoint nang direkta sa pamamagitan ng background fetch() para sa mga mutation. Sadyang ginagawa ito: ang mga aksyon sa API ay hindi nakikita (hindi mo nakikita kung ano ang ipinapadala), madalas nangangailangan ng hiwalay na auth token na maaaring hindi mo nakonfigure, at may mas malaking blast radius kaysa sa isang nakikitang maling click. Ang UI-first ay nangangahulugang nasa screen ang lahat, sa normal na browser session mo, at maaaring ipahinto anumang oras.

Para sa pagbabasa ng datos — pagkuha ng README, pagtingin sa isang issue, paghahambing ng presyo sa iba't ibang site, pagtingin sa status page — malayang gumagamit ang WebBrain ng background HTTP requests sa pamamagitan ng fetch_url at research_url tools. Ang pagbabasa ay hindi pagkilos; hindi nito binabago ang anumang bagay sa remote service, kaya hindi nagagamit ang parehong concerns sa kaligtasan.

Kung partikular mong gustong payagan ang mga API mutation para sa isang partikular na gawain, mag-type ng /allow-api sa simula ng iyong mensahe (opsyonal na sundan ng maikling task description). Pinapayagan ng per-conversation override na ito ang WebBrain na bumalik sa mga API endpoint kapag tunay na hindi gumagana o hindi pwede ang UI, habang nananatiling iniprefer ang UI kapag gumagana ang UI. May isang sticky badge na nananatiling nakikita sa itaas ng input area habang aktibo ang override, at mati-clear ito kapag nag-reset ka ng conversation.

Ang Profile auto-fill ay isang opsyonal na tampok sa Settings → Profile. Maglalagay ka ng maikling bio — pangalan, work email, kumpanya, at isang isahang-gamit na password para sa mga low-stakes na signup — at i-on ito. Kapag naka-enable, idinaragdag ng WebBrain ang text na iyon sa system prompt ng ahente para makapag-puno ito ng signup forms nang hindi nagtatanong tuwing kailangan.

Ang text ay nakaimbak bilang plain text sa local storage ng iyong browser. Hindi ito ipinapadala sa proyektong WebBrain, ngunit ipinapadala ito sa kung anong LLM provider ang iyong na-configure sa bawat turn, bilang bahagi ng system prompt. Naka-off bilang default.

Huwag maglagay ng mga password para sa mahahalagang account (Google, Apple, iCloud, banking, work SSO, primary email) dito. Dapat gumamit ng 2FA ang mga account na iyon at hindi naman dapat ipinapasa sa isang ahente. Ang inilaang gamit ay isang isahang-gamit na password na ginagamit mo ulit para sa mga newsletter signup at libreng trial.

Hindi — binabawasan lang nito ang exposure, hindi ito garantiya. Kapag naka-enable (Settings → Multimodal → Screenshot redaction, naka-off bilang default), binuburahan ng WebBrain ang mga form field at tekstong mukhang email address o numero ng telepono sa bawat screenshot bago ito ipadala sa isang vision model. Tumatakbo ang detection nang buo sa iyong device gamit ang DOM heuristics; walang karagdagang ipinapadala.

Best-effort at fail-open ito. Kung hindi matakbo ang detector sa isang page — halimbawa, agad pagkatapos mag-navigate, sa mga PDF viewer, o sa mga restricted browser page — ipapadala pa rin ang screenshot nang hindi nabura sa halip na kanselahin ang iyong task. Puwede ring makalusot ang nilalamang hindi nakikita ng DOM heuristics (tekstong iginuhit sa canvas, personal na impormasyon sa loob ng mga larawan, hindi karaniwang widget). At sinasaklaw lang ng setting na ito ang mga screenshot: hindi binubura nito ang text ng page na ipinapadala sa model.

Para sa ganap na privacy sa vision, gumamit ng local model. Gamit ang offline provider tulad ng llama.cpp o Ollama, hindi kailanman aalis sa iyong device ang mga screenshot at text ng page, kaya wala talagang burahin sa umpisa pa lang — ito lang ang setup kung saan ganap na ginagarantiya ang privacy. Tingnan ang "Magagamit ko ba ang WebBrain nang ganap na offline?" sa itaas.

Walang device na kayang magpatakbo ng local model na may vision? Magandang gitnang solusyon ang paggamit ng maliit na local model para sa planning at pag-call ng tools (magaan na kayang tumakbo kahit sa ordinaryong CPU/GPU), kasama ang isang cloud provider para sa vision sub-calls, habang naka-on ang Screenshot redaction. Nananatili pa rin sa device mo ang iyong usapan at text ng page, at bawat screenshot na aalis papunta sa cloud vision ay bura na muna ang mga form field at nadetect na email/telepono — mas kaunting exposure sa cloud nang hindi na kailangan ng hardware para sa isang buong local vision model. I-configure ang paghahati na ito sa Settings → Vision (tingnan ang "Paano kinokontrol ng WebBrain ang singil sa cloud LLM?" sa itaas).

Hindi. Bilang default, hindi ipinapadala ng WebBrain ang raw HTML o isang raw DOM dump. Nagsisimula ito sa URL at pamagat ng page, kaugnay na gabay para sa site, at opsyonal na screenshot ng nakikitang bahagi kapag naka-enable ang vision.

Kapag kailangan ng isang gawain ang nilalaman ng page, binabasa ito ng WebBrain kapag kailangan bilang pinaikling semantic accessibility tree o extracted text. Ang mga pagbasa ay sinasala ayon sa visibility kapag naaangkop, nililimitahan ang bilang ng character, at hinahati sa mga page. Ang access sa raw page source ay available lamang sa Dev mode.