Guide
How to use the MFF app, section by section: labels, credits, sessions, models, keys, web search, peer review. It is the same manual you find inside the app — public here, no account needed.
From the dashboard you create a session choosing domain, mode and model. In the session you write your question: the answer streams in, with labels declaring how much the model commits to each statement. Use 📎 to attach images, PDFs or text documents; use 🌐 to request a web search before answering.
Every statement carries its declared level: 🟢 CERTAIN, 🔵 PROBABLE, 🟡 MAYBE, 🟠 DEPENDS, 🔴 UNKNOWN, ⚫ CANNOT. They are not decoration: they are the commitment the model takes on that sentence, and they stay in the export. A suffix like [doc] or [test] says where it comes from, [p:75%] how confident it is. In PLAIN mode there are no labels, and everything else on the platform works the same.
The session collects in a 🗂 card what has been established and on what grounds, extracted from the labels already declared — not a summary written by a model. It serves two purposes: to look at, and to carry elsewhere. “Copy as memory” gives you text you can attach to a new session, perhaps with another model, without dragging the whole transcript along. Whoever receives it reads that those labels were declared by someone else: claims to discuss, not verdicts to inherit.
A credit is spent when the answer actually applies the framework. If it does not, it is refunded. Web searches with your own BYOK key and peer review in PLAIN do not consume MFF credits: you only pay your provider’s cost. Balance and every movement are in Settings.
A session starts from the dashboard, and every wizard choice changes something concrete in the engine. The first is the mode: “Simple chat” (PLAIN) or “MFF Framework”. PLAIN is a free conversation: no epistemic labels, no credits spent, yet ALL platform features remain — attachments, web search, peer review, read-aloud, export. MFF injects the epistemic protocol instead: every statement in the answer will carry a declared commitment level, and a credit is spent only if the framework is actually applied.
The domain (General, Business, Strategic, Technical, Legal, Medical, Scientific, Creative, Academic) does two things. First: it defines what 🟢 CERTAIN, 🔵 PROBABLE and 🟡 MAYBE mean in that context — in the scientific domain “CERTAIN” means replicated, published results; in the creative domain the bar is different. Second: it sets the model’s default temperature, from 0.2 (Legal: conservative, repeatable answers) to 1.0 (Creative: maximum variability). You can always override it in the advanced settings.
The operating mode decides the cut of the answer: MFF-E is rigorous epistemic analysis, MFF-G reduces noise and redundancy, MFF-X interprets and explains without altering, MFF-EX combines them (the central mode), MFF-EGX adds the discipline of synthesis. AUTO lets the protocol choose turn by turn based on the task.
The levels are the anti-hallucination defense modules, enabled at will (default L1+L2+L3). L1 Forced Citation is always on and cannot be disabled: 🟢 CERTAIN without a source is downgraded to 🔵 PROBABLE, always. L2 opens the External Verification Zone on at-risk content; L3 forces the model to state the conditions that would refute its claims; L4 hooks up web search (used via the 🌐 button in chat); L5 enables peer review and extended reasoning; L6 checks epistemic drift every 5 turns; L7 is multi-source validation with a second model. PAVA and NIST are shield protocols for long sessions and regulated domains. Practical implication: more levels = more rigor but longer, more token-expensive answers; L4 and L5/L7 have prerequisites (a search source for the former, a peer model for the latter).
The session language is a separate choice from the interface language, and it stays fixed: switching the UI language does NOT translate answers already generated — the epistemic label belongs to the text that model produced, and translating under the labels would falsify them.
Inside the session: the answer streams in; under each message you find 📋 copy, 🌐 sources, 🔊 read aloud, ⚖ peer review, and on each of your questions the ability to edit and resend (or regenerate the answer). “▸ Continue” resumes an answer truncated by the budget. In sessions beyond 100 messages, “⤒ Load earlier messages” at the top of the transcript walks back through history. Every 10-12 turns the engine updates the State Card: it is the session’s transferable memory — the correct way to change model is to export it and attach it to a new session, not to swap engines mid-conversation.
The picker always shows each provider’s full lineup, marking which models are actually served right now: the truth comes from the provider’s live catalog, not from a hand-written list. An unserved model is visible and marked, not hidden — knowing it exists but does not answer is information, not noise.
Capabilities come from the catalog too, not from the name: if the model declares vision, image attachments are enabled; if it declares reasoning, L5 can switch on extended thinking tokens; if it declares image generation, it joins the generation routes. When the catalog is unreachable the engine falls back to heuristics declared as such.
The free-versus-paid choice has precise implications. :free models cost nothing but have a tighter document budget and context, and 🌐 web search is disabled for cost containment. Paid models run on YOUR BYOK key: the cost is your provider’s, MFF adds nothing on top.
If the provider fails mid-answer (rate limit, overload, retired model), the engine tries the fallbacks: first the reserve models you can set in the advanced settings (up to 3, in order), then the policy chain across your providers with an active key. Failover is always DECLARED: the answer, the labels and the State Card report who actually served, never who was asked. A non-recoverable error (invalid key, exhausted balance) does not fail over: it is shown as it is, and the turn’s MFF credit is refunded.
One implication worth knowing: after a failover the turn restarts from scratch on the reserve model (the fallen model’s partial text is discarded, not stitched) — what you read is ALWAYS from a single model, declared.
MFF talks to 17 providers, in two families. Aggregators (OpenRouter, OrcaRouter) give access to dozens of vendors with a single key: convenient for exploring, and OpenRouter also connects with one click via OAuth, no key copying. Direct providers (OpenAI, Anthropic, Google, Groq, Cerebras, Mistral, DeepSeek, xAI, Perplexity, Z.AI, NVIDIA NIM, SambaNova, Hyperbolic, Cohere, Cloudflare Workers AI) expose the vendor’s native capabilities: Anthropic’s built-in web search, Perplexity’s native citations shown among the sources, Groq’s and Cerebras’ generous free tiers.
The choice affects routing: with an aggregator the request makes one extra hop and capabilities depend on what the aggregator exposes; with a direct provider you get the shortest path and the native features. Peer review, by design, picks the second model from your DIRECT providers, so the reviewer is truly independent from the first model’s channel.
Every key has a protection switch (breaker): if the provider answers “invalid key” three times in a row, the key is paused for fifteen minutes to stop burning requests; repeated failures and rate limits degrade it temporarily. In Settings you see each key’s state and can force a breaker reset.
Image generation is a capability of the PLATFORM, not of the chat model: if the session model cannot generate images, the engine routes the request to the first of your keyed providers that can, and declares it. No need to switch sessions to generate an image.
API keys are configured in Settings, one per provider. The flow: open the provider card, paste the key, MFF validates it IMMEDIATELY with a real test query — a key that fails the test is not saved. Valid keys are encrypted server-side (AES key-ring with encryption key rotation) and are never shown in clear again, never put in a URL, never sent to the browser. You can label them, and delete them anytime.
For OpenRouter there is the fast path: “Connect OpenRouter” opens their OAuth flow, you authorize, and the key reaches MFF with no copy-paste.
On every key you can set a whitelist of allowed models: the session can only use those, and a failover will never pick a model outside the list. It is the right protection if you share the account or want to keep yourself away from expensive models: the restriction wins over any automatism.
Separate from model keys are the SEARCH keys (Serper, Tavily, SerpAPI, Brave), used by the 🌐 button. These are validated with a test query too. You can elect one as default: the engine tries it first, the others remain reserves in the fixed order Serper → Tavily → SerpAPI → Brave. With your own search key you only pay your provider; without one, MFF’s included search quota is used, which is limited and shared.
A security implication worth knowing: the session model NEVER sees your keys — requests leave from the MFF server, and no secrets transit in the prompt.
The 🌐 button next to the composer requests a web search BEFORE the answer. The flow is transparent at every step. 1) A mini-model extracts the proposed search query from the conversation and SHOWS it to you: you can correct or rewrite it before it goes out — the query is your decision, not a blind automatism. 2) The search runs on the MWAL chain: your default key first, then the reserves, in the order Serper → Tavily → SerpAPI → Brave; if an engine fails, the hand-off to the next one is declared. 3) The results enter the context as a grounding block, and the answer can cite them.
The anti-hallucination rule is strict: the 🌐 CONFIRMED:WEB and 🌐 VERIFIED:WEB labels are allowed ONLY if a real grounding block was injected in that turn (or the provider has native search, like Anthropic or Perplexity). Without the block, the model must declare it has no live access and fall back to 🔵 PROBABLE[mem] — saying “I searched the web” is not evidence, and the protocol treats it as such.
Sources stay attached to the answer: the 🌐 chip in the message footer lists the links, survives reloads and ends up in the export. For Perplexity, the model’s native citations are shown as well.
Two honest limits. First: search engine snippets are by construction a cache — for data that changes by the minute (live quotes, the exact time) the source can be pertinent yet stale. Second: on :free models the 🌐 is disabled for cost containment.
Peer review has a SECOND model, from a different provider, re-read an answer and shows you the judgement next to the original. It is not just any second opinion: it is level L5-B of the protocol — the ensemble logic says that convergence of two independent agents can promote a 🔵 PROBABLE to 🟢 CERTAIN, and a divergence forces 🟡 MAYBE or 🔴 UNKNOWN. Two models sharing neither weights nor channel, agreeing on the same statement, are worth more than one.
How to enable it, step by step: 1) in the wizard’s advanced settings choose the peer model — the list draws from your direct BYOK providers, deliberately different from the session provider; 2) in chat, under any answer, press ⚖; 3) the review streams in and stays anchored to that message, with its convergence verdict. Reviews are persisted: you find them again on reload and in the export, and those anchored to messages older than the loaded page remain reachable at the top of the transcript.
It works in PLAIN too, by platform parity: without labels it is still an independent second opinion on the content.
Cost implications: the review runs on YOUR peer-model key — you pay your provider; in PLAIN it consumes no MFF credits. Epistemic implication: if you regenerate an answer, reviews stay anchored to the message they referred to — a review never migrates onto a text it never read.
The base rule of MFF credits is one: you pay for the framework applied, not for the attempt. At the start of a turn one credit is reserved; if the answer actually applies the protocol, it is confirmed; if it does not, or the provider fails, it comes back. PLAIN never consumes credits. Everything running on your own keys (BYOK models, web search, peer review) costs only what your provider bills: MFF adds nothing.
To spend less, in order of effectiveness: 1) use :free models for drafts and exploration — free, with the trade-off of tighter context and document budget and no 🌐; 2) prefer short sessions and transfer the State Card instead of dragging very long conversations: history beyond the cap gets truncated by the engine anyway, the card is the memory that travels without paying context tokens; 3) keep reasoning on Low until the task demands more — extended thinking tokens are billed like any others; 4) set the allowed-models whitelist on your key, so no automatism can pick an expensive model on your behalf; 5) set cheap fallbacks in the advanced settings, because failover respects your list.
Every answer carries its numbers: the technical footer shows tokens in and out, timings, and — when the model’s price list is known — the message cost estimate and the session running total. If the provider’s usage never arrives, the estimate is marked as such (~), never passed off as data.
A platform guarantee: the technical protections (key encryption, breaker, declared failover, rate limits) are identical for free and paying users. Free is not a less safe version.
The Settings page has two views, selectable from the menu at the top: “Basic user” shows the essentials (profile, keys, balance, voice, privacy); “Expert user” adds diagnostics, AI preferences, model whitelist and movement history. The choice is remembered on the device. If this guide mentions something you cannot see on the page, it almost certainly lives in the Expert view.
Basic view areas, top to bottom: Profile (interface language and default provider for new sessions); Appearance with the light/dark theme; Voice (the voice, speed and pitch used by 🔊 and by 🎙 dictation); Credits (balance and how to request more); Model API keys, where you paste a key or connect OpenRouter in one click — each key shows a traffic light: active, invalid, or paused; Web search, where you add search-engine keys (Serper, Tavily, SerpAPI, Brave) and elect the default with the ⭐; at the bottom, the Privacy area with the full export of your data and account deletion (immediate and final, protected by written confirmation).
The Expert view adds the fine tuning: a custom temperature that overrides the domain preset, a cap on response tokens, the default reasoning effort (L5), the default language of new sessions, automatic continuation of truncated answers; on keys, the 🎯 whitelist editor and each key’s technical declarations (how many models the catalog exposes, with which capabilities, what credits remain at the provider); on search, the toggle governing query-extraction downgrade.
Diagnostics (Expert view) is the panel that answers “why is it not working?”, and no number in there is invented: they are real probes. The BYOK probe runs an actual test query on each of your keys and reports the outcome with latency; the images panel declares WHICH of your keys would generate an image right now and with which model; model health shows telemetry of what you actually used (time to first token, errors, 429s); the field census lists what provider APIs expose and MFF does not translate yet.
What to do when something is red. Key “invalid”: the key was revoked or expired on the provider’s site — regenerate it there and paste it again; MFF cannot repair it. Key “paused”: the breaker stopped it after repeated errors (three “invalid” in a row = a quarter-hour pause) to stop burning requests; it reactivates by itself when the pause ends, or immediately with the “Reactivate” button if you are sure the problem is fixed. A failed probe on a key that worked yesterday: before deleting it, look at the code — a rate limit or a provider outage passes on its own, and deleting the key speeds up nothing. General rule of the panel: missing data is shown as missing, never passed off as zero.