> For the complete documentation index, see [llms.txt](https://yvechat.gitbook.io/wp/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yvechat.gitbook.io/wp/product-scope/limitations.md). # Limitations Honest constraints, with sources YveChat is designed to be useful immediately, and it operates inside real constraints. Every limitation below is documented by a primary source, linked in place. This page exists because a sovereignty claim that dissolves under checking is worth nothing. *** ### Browser and Local Access | Limitation | Current impact | Planned direction | | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | Chrome gates local network access | Requests from the hosted origin to the Engine require a user permission prompt, and denial blocks the connection | Guided first-run prompt handling, with a local fallback interface | | The gate keeps tightening | Chrome 142 shipped the restriction, 145 split the permission in two, 147 extended it to WebSocket and WebTransport | Transport chosen to survive the WebSocket gating, tracked per release | | Safari loopback behavior is inconsistent | WebKit's loopback mixed-content bug has been open since 2017, and Safari 18 shipped a regression blocking this exact pattern | Safari treated as best-effort, with an explicit degraded-mode message | | Ollama rejects the hosted origin by default | Direct browser calls fail CORS until `OLLAMA_ORIGINS` is configured and the daemon restarted | The Engine proxies locally, avoiding browser CORS entirely | | Ollama binds to loopback | The Engine and Ollama must be co-resident on one machine | Remote runtime configuration as an explicit, later option | Sources: [Chrome Local Network Access](https://developer.chrome.com/blog/local-network-access), [Chrome Platform Status](https://chromestatus.com/feature/5152728072060928), [WebKit 171934](https://bugs.webkit.org/show_bug.cgi?id=171934), [WebKit 279249](https://bugs.webkit.org/show_bug.cgi?id=279249), [Ollama FAQ](https://docs.ollama.com/faq) *** ### Local Inference | Limitation | Current impact | Planned direction | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | Local models trail frontier models | On the LMArena text leaderboard retrieved 2026-08-03, the top 15 entries were proprietary models scoring 1483 to 1509, while the highest-ranked model near 30B parameters sat at rank 158 with 1383 | Frontier models stay available through user keys. Local quality improves independently | | Ollama defaults to a 4096-token context | Long documents truncate silently, appearing as memory loss | Context set explicitly per request, with the active value surfaced | | Memory scales with parallelism times context | Raising context to be competitive multiplies VRAM and can fail to load | Hardware-aware defaults, with clear failure messages | | Ollama serializes by default | One parallel request per model, so concurrent chats and tool calls queue | Local inference modeled as a serialized resource with visible queueing | | GPU support is driver-sensitive | NVIDIA compute capability 5.0 and above with specific driver minimums. Many installs land on CPU | The Engine reports detected acceleration so slow generation is explainable | | vLLM requires GPU infrastructure | Installation targets CUDA and ROCm, making it a power-user path | Positioned as a homelab and infrastructure option | | OpenAI compatibility is partial | vLLM accepts parameters OpenAI omits and omits others, so a single request builder cannot be reused unchanged | Capability negotiated per backend | Sources: [LMArena text leaderboard](https://arena.ai/leaderboard/text), [Ollama FAQ](https://docs.ollama.com/faq), [Ollama GPU](https://docs.ollama.com/gpu), [vLLM OpenAI-compatible server](https://docs.vllm.ai/en/latest/serving/openai_compatible_server/) {% hint style="warning" %} Local inference is a custody and privacy capability. Capability parity with frontier models is not claimed, and the first side-by-side comparison a user runs will confirm the gap. Leaderboard positions move continuously, and the figures above carry their retrieval date. {% endhint %} *** ### Bring Your Own Keys | Limitation | Current impact | Planned direction | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | Providers instruct against client-side keys | Google states keys compiled into client-side code can be extracted, and directs developers to a backend proxy. OpenAI directs developers to route through their own backend | Keys held by the Engine on the user's machine, satisfying the guidance while keeping custody | | Rate limits belong to the user's account | Limits and spend caps apply per user, and a new account can start below published tier limits | Provider-attributed errors that read rate limit headers and name the provider | | Tier advancement takes calendar time | Gemini Tier 2 requires "$100 + 3 days" and Tier 3 "$1,000 + 30 days", so limits cannot be bought past on day one | Clear onboarding guidance about provider tiers | | Daily quotas reset on a provider clock | Gemini daily limits reset at midnight Pacific, so exhaustion persists for hours | Distinct interface treatment for daily versus per-minute limits | Sources: [Gemini API key guidance](https://ai.google.dev/gemini-api/docs/api-key), [OpenAI API key safety](https://help.openai.com/en/articles/5112595-best-practices-for-api-key-safety), [Anthropic rate limits](https://platform.claude.com/docs/en/api/rate-limits), [Gemini rate limits](https://ai.google.dev/gemini-api/docs/rate-limits) *** ### Tools and MCP | Limitation | Current impact | Planned direction | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | MCP cannot enforce its own security | The specification states it "cannot enforce these security principles at the protocol level" | Every control implemented in the gateway, inherited from nothing | | Tool metadata is untrusted input | Any added server can supply adversarial text reaching the model as instructions | Server-level trust designation, with untrusted metadata isolated from system context | | Local MCP server installation executes arbitrary code | Documented risks include arbitrary execution, obfuscated commands, and exfiltration of files such as SSH keys | Full untruncated command display, sandboxing, and privilege restriction | | Reading tools are SSRF primitives | `open_url` and `read_pdf` can be directed at internal addresses | Outbound requests filtered against private and reserved ranges | | Web search leaves the machine | Ollama Web Search requires an account and API key with queries reaching Ollama's servers. SearXNG dispatches queries to upstream engines | Presented as a deliberate, per-conversation exit from sovereignty | | Public SearXNG instances often disable JSON | Requesting an unset format returns 403, and many public instances disable these formats | Self-hosted instances recommended, with the disabled-format condition detected and explained | Sources: [MCP specification](https://modelcontextprotocol.io/specification/2025-06-18/index), [MCP security best practices](https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices), [Ollama web search](https://docs.ollama.com/capabilities/web-search), [SearXNG search API](https://docs.searxng.org/dev/search_api.html) *** ### Wallet Identity | Limitation | Current impact | Planned direction | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Sign-In With Ethereum authenticates only | Authorization to server resources and encryption sit explicitly outside its scope | Authorization implemented as a separate, documented layer | | Phishing resistance depends on the wallet | The standard assigns request origin verification to wallets, whose implementations vary | Canonical origins published on [Verified Links](/wp/res/verified-links.md) | | Wallet-derived encryption lacks a standard | ERC-5630 states there is no security proof for using one secret key for both secp256k1 signing and ec25519 encryption, and remains in Draft | Client-side encryption treated as an open dependency | | Smart contract wallets need on-chain verification | ERC-1271 validation requires a call against the account contract, adding an RPC dependency and a login-path failure mode | Supported deliberately, with the dependency disclosed | | Wallet access depends on wallet recovery | Losing control of the wallet removes that wallet sign-in path. Local accounts remain an alternative identity path | Clear onboarding about wallet recovery and the optional local-account path | Sources: [ERC-4361](https://eips.ethereum.org/EIPS/eip-4361), [ERC-5630](https://eips.ethereum.org/EIPS/eip-5630), [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271) *** ### Self-Hosting and Regulation | Limitation | Current impact | Planned direction | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Certificate renewal is accelerating | Let's Encrypt made six-day certificates generally available and announced standard lifetimes moving from 90 days to 45 | Unattended ACME automation treated as a requirement in deployment guidance | | Self-hosting concentrates legal responsibility | Under GDPR, whoever determines the purposes and means of processing is the controller. A self-hoster processing others' personal data becomes that controller | Deployment guidance states the obligation plainly | | AI regulation is arriving on a fixed timetable | The EU AI Act applies its general-purpose AI obligations from 2 August 2025, with remaining requirements from 2 August 2026 | Classification reviewed against the Regulation | | Operational burden transfers to the user | Updates, backups, TLS, and uptime become the operator's responsibility | Documented runbooks, signed releases, and sane defaults | Sources: [Let's Encrypt six-day certificates](https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability), [Let's Encrypt 90 to 45 days](https://letsencrypt.org/2025/12/02/from-90-to-45), [GDPR](http://data.europa.eu/eli/reg/2016/679/oj), [EU AI Act](http://data.europa.eu/eli/reg/2024/1689/oj) {% hint style="danger" %} Self-hosting increases the operator's regulatory exposure. A user who self-hosts and processes other people's personal data takes on the full controller obligation set, including lawful basis, data subject rights, and breach notification. Sovereignty transfers responsibility along with control. {% endhint %} *** YveChat is real, usable, and incomplete. Stating where it ends is part of stating what it is. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://yvechat.gitbook.io/wp/product-scope/limitations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.