What's new: the MITHUNAI changelog

• Plan and usage: Settings → Plan & usage shows your plan, each limit next to what you use now (assistants, indexed documents, website widgets, people and tracked AI search questions), your trial end and this month’s answers. MITHUNAI staff set the plan; to change it, contact sales. A create past a limit is refused with 403 plan_limit, naming the limit, and nothing you already have is removed. See Plan and usage.
• Overage, if you ask for it: on Growth and Business, answers can continue past the monthly allowance up to twice it, counted and invoiced. Off unless you agree to it.
• Your own AI keys (Beta): on a plan with your own keys, answers use your organisation’s OpenAI, Anthropic or Google key, saved by an owner or admin under Settings → AI provider keys, encrypted and never shown again. Without a key, a question is refused rather than answered on MITHUNAI’s keys. Not yet run against a live provider account. See Your own AI keys.
• Behaviour change for software: GET /usage now also returns overage and overage_ceiling; there are three new error codes, plan_limit, model_key_missing and model_key_rejected. See Errors.

• Trust: Data handling, Deployment modes, Security questionnaire, Shared responsibility and Subprocessors.
• Administration and knowledge: Audit log and Source permissions.
• API reference: eleven endpoint pages, among them Export the audit log, Run an assistant’s eval, Get a document’s access list and Record a deflection.

• Microsoft Teams — ask MITHUNAI in a chat, and decide approvals on a card: message the bot in a personal chat, or mention it in a channel or group chat, and it replies in Teams from the assistant you chose, with numbered sources, or says “I don’t know”. An owner or admin connects the Teams organisation under Integrations → Microsoft Teams by Microsoft Entra admin consent, and each person links their own Teams account from a single-use link the bot sends them in a personal chat. When your deployment has approvals in Teams switched on, an AI employee’s action waiting for approval is posted as a card with Allow once and Deny, and a press counts only as the person it is linked to. Access on request, and it answers only once your deployment’s operator has registered the bot. See Microsoft Teams.
• Slack — decide approvals on a card: when your deployment has approvals in Slack switched on, an AI employee’s action waiting for approval is posted to the channel an owner or admin chose, with Allow once, Always allow and Deny. Each person links their own Slack account once, from a link the bot sends in a direct message and a code sent back to it, and a press counts only as that linked person. Always allow is never offered for an action that moves money, deletes, publishes or changes access. Access on request. See Approve AI-employee actions from Slack.
• Finance — Expensify, read only: for card spend and receipts, connect Expensify instead of Ramp, one at a time. The Finance employee reads the last 31 days of expenses, whether each has a receipt, and the submitter’s email. It approves, returns and reimburses nothing in Expensify. See Connect your tools.
• Four features that are off by default. Each is access on request and stays off until your deployment’s operator turns it on. While it is off the platform refuses it, and the console no longer shows its screen, so nothing changes for you until then.
  • A mailbox for each Sales rep: an owner or admin can attach a Gmail or Outlook mailbox for one named person, so that person’s follow-ups are drafted in their own. A draft is saved there and never sent. See Sales.
  • A stored widget presentation: an embed can keep its default way of appearing, Chat bubble or Docked sidebar, under Widget embeds. A snippet that sets data-mode still wins. See Setting the default for an embed.
  • An AI gateway policy for one organisation: a Platform Super Admin can give one customer its own monthly token or cost budget, budget mode, redaction and answer-cache setting from the staff portal. See AI budgets, redaction, fallbacks and an answer cache.
  • Kept eval sets and runs: under Settings → Answer quality, keep a set of questions under a name, run it again whenever you like, and see each run’s pass rate. See Answer quality evals.
• Source permissions are still not available: the storage for them is built, but answers do not yet respect a source’s own permissions on any deployment, and Source permissions is unchanged.
• Marketer — a failed GitHub fix says whether a branch was left behind: when a GitHub pull request from Propose a fix fails, the message now says a branch was left only if the branch was actually created. Before, GitHub refusing the branch itself was reported as though one existed. Nothing is merged from here and your default branch is never touched.
• Support — test on past tickets reads like the live employee: the bench that replays your solved tickets now answers every lookup the Support and Sales planners can make with “nothing found”, so a replay never stops on a lookup it was not given. See Test on past tickets.
• Signed-in apps are kept out of search results (behaviour change): the console, MITHUNAI Team, Agents and the Gateway now tell search engines not to index their sign-in screens. Your public site and these docs are unaffected.

• Slack — answers in the thread: mention the bot in a channel, or send it a direct message, and it replies in the thread from the assistant you chose, with numbered sources, or says “I don’t know”. Connect a workspace in Integrations → Slack once your deployment’s operator has registered the Slack app. It has not yet answered in a real Slack workspace. See Slack.
• Proposed answers for coverage gaps: a new tab on Coverage gaps drafts an answer to a question your assistants could not answer, from your own sources and through the same grounding as any answer. A person reviews it and publishes it as a custom answer, or dismisses it. See Proposed answers.
• AI search visibility — propose a fix for a gap: Propose a fix on a gap drafts a section that answers the question from your own knowledge base, never from the engine’s answer. Edit it, then send it to the Marketer as a GitHub pull request or a WordPress draft, or copy or download it. Nothing is sent until a person approves it, a pull request never touches your default branch and is never merged from here, and a WordPress draft is never published. See AI search visibility.
• Approvals — Allow once, Always allow or Deny: an approval now carries out exactly what you read, and nothing else. Always allow lets one kind of action from one employee and one tool run without asking; money, deleting, publishing and access changes can never be always allowed. A rule can instead require two different people. A card from work that arrived by itself expires after a day if nobody decides. Rules are off by default. See Approvals and Approval rules.
• Support — test on past tickets, with a confidence threshold: run the Support employee on tickets your team already solved and compare what it would have proposed with what was actually sent. Below the threshold you set, a reply becomes a hand-off to a person. See Test on past tickets.
• Support — Freshdesk and Intercom, and a hand-off summary: Support now works in Freshdesk or Intercom as well as Zendesk, one helpdesk at a time, and picks up new tickets from either by itself. Every hand-off note carries the question, why it is with you, what was tried, the sources consulted, a suggested priority and suggested tags. See Support.
• Sales — drafts in your own mailbox, and account briefs: with Gmail or Microsoft Outlook connected, the Sales employee drafts a follow-up in the one mailbox you name, after a meeting, on a quiet deal or in reply to a prospect, and briefs you on an account from HubSpot and your knowledge. A draft is sent only if you turn sending on and a person approves it. See Sales.
• IT service desk — Okta, Google Workspace and Microsoft Entra ID: with your identity provider connected, the IT service desk prepares access requests and revokes, password and MFA resets, onboarding, offboarding and access reviews. Every change waits for a person, and offboarding suspends an account rather than deleting it. See IT service desk.
• DevOps — Sentry, PagerDuty and Datadog, and postmortems: the DevOps employee reads Sentry issues, Datadog metrics and logs and the PagerDuty incident, writes the likely cause with numbered evidence and how sure it is, and can take Sentry’s and PagerDuty’s signed alerts at an address of their own. After an incident it drafts a postmortem a person edits and approves. A rollback or restart is never sent. See DevOps.
• Finance — QuickBooks Online, Xero and Ramp, and the close: connect your own Intuit or Xero app and sign in once, and the Finance employee reads your bills, invoices, contacts and accounts; with Ramp it reads card spend. It flags charges with no receipt or out of policy and reminds each cardholder, drafts a bill or invoice copied from that vendor’s or customer’s last one, proposes the account for uncategorised lines, and runs a numbered month-end checklist that says what it did not read. Every write to your books waits for a person and can never be always allowed. It never moves money: there is no action that pays, transfers, refunds, approves or changes a card, and preparing a payment for a payment run has been removed. See Finance.
• Widget — four ways to appear: besides the chat bubble, the widget can be a docked sidebar, a search box that answers with sources, or a form deflector that shows a cited answer beside your support form before it is sent. Choose with data-mode, or with How it appears next to the line in the console. See Ways it can appear.
• Analytics — deflections: Get usage analytics returns deflections, how many visitors the form deflector helped and how many sent the form anyway, and Usage shows them when there are any.
• MCP — rate an answer: a new feedback tool rates an answer ask_assistant returned, as helpful or not, with an optional note. ask_assistant now returns the conversation_id and message_id it takes, and adds a line naming them after the answer text. It is the one tool that writes, and it writes only that rating. See MCP.
• Knowledge — a sync that would remove most of a source waits (behaviour change): when a re-sync would remove more than 45% of a source’s documents, nothing is removed and the documents stay in use until a person chooses Remove them or Keep them under Ingestion. The run’s error_code is removal_held. See When a sync would remove most of a source.
• Knowledge — source permissions, built and not yet available: a source can answer each person only from the documents they can read in the source system, applied inside the search, so a document someone cannot read never shapes their answer, and a document whose readers the source did not report is answered to knowledge administrators only. Who can see this sits under each document. The switch is shown on GitHub repository sources and cannot be turned on until a database change is released; until then every source answers as before. See Source permissions.
• Conversations — save an answer: Save as answer under an answer turns it into a custom answer after you review it. See Conversations.
• AI budgets, redaction, fallbacks and an answer cache: whoever runs your deployment can give each organisation a monthly model-token or estimated-cost budget, with owners and administrators emailed at 50, 80 and 100 per cent and, if they choose, model calls stopped at 100 per cent with budget_exceeded; keep email addresses, phone numbers, card and account numbers, national IDs and keys out of prompts; fall back to other models, or send a share of traffic to a canary; and answer a repeated question from a cache. Each is off until switched on. See it under Settings → AI gateway or with GET /ai-gateway, and read AI budgets, redaction, fallbacks and cache.
• Audit log export: owners and admins can download their organization’s audit log, as CSV or JSON Lines, from Settings → Audit log or GET /audit-log/export, filtered by date range, actor, action or category. Every export is recorded in the log itself. See Audit log.
• Answer quality evals: write questions you know the answers to, and ones an assistant should decline, then score every answer for grounding in its cited passages, correct citations, expected sources and facts, and correct abstention, in Settings → Answer quality, through POST /assistants/{assistant_id}/evals, or with flask mithunai-evals run in CI. Each question is one answer from your allowance. See Answer quality evals.
• Marketer — posts to X and LinkedIn, and search performance: with X or LinkedIn connected, an approved post goes on your account or company page, exactly as approved; every post waits for a person, and nothing deletes a post, sends a message, follows or likes. With WordPress connected, the posts are drafted once you publish the article, linking to it. With Google Search Console connected, Check search performance finds the pages that lost search clicks and gives the likely reason with numbered evidence. See Marketer.
• Documentation: every page now has a title and description of its own sized for search results, the pages for Beta features are labelled Beta in the sidebar, and Product status lists each feature above.

• Product status — a new label, Beta: a feature that is still new and still being worked on is now labelled Beta instead of preview. Only the label changes: each feature behaves as it did, and every note about what has not yet been proven stays beside it. These moved from Preview to Beta: GitHub discussions; scheduled automatic re-sync; private GitHub repositories; Confluence Cloud and Notion; Jira Cloud, Jira Service Management and Zendesk solved tickets; the MCP server; grouping similar coverage gaps; top questions; inviting a colleague by email; password reset; requesting access; and one sign-in and one sign-out, which is Beta. The Integrations screen in the console says Beta once your deployment takes this update.
• Three statuses, not four: MITHUNAI Team, AI search visibility and MITHUNAI Agents are now Beta too. Team and AI search visibility stay switched off by default, Agents is on request, and every note about what has not yet been run against a real account stays beside them. A status is now Available, Beta or Planned. Entries below this one keep the word they were published with. See Product status.
• MITHUNAI RAG at its own address, in beta: rag.mithunai.com now answers and sends a signed-out visitor to sign-in.
• Security fix, Model Gateway sign-in: an organisation’s Owner or Administrator signing in to the Model Gateway with their MITHUNAI account could be treated as a platform administrator there. This is fixed and deployed on the hosted service.

• API — a failed answer is kept (behaviour change): when generating an answer fails on POST /conversations/{conversation_id}/messages, your question and an answer with status: "failed" now stay in the conversation, as they already did on the streaming endpoint. You still get the same 502 or 503 error. A retry with the same idempotency_key now returns that failed turn with 201 instead of asking again, so give a retry of a failed question a new key. The widget’s own non-streaming endpoint behaves the same way.
• Members — added by invitation only (security, behaviour change): adding a member, in Settings → Members or with POST /members, always emails an invitation, and the person joins when they accept it. The answer is the same whether or not the address has an account and whether or not it already belongs to a member, who is left as they are and sent nothing, so adding someone can no longer be used to find out which addresses have accounts. POST /members now answers 202 instead of 201 with the member, and no longer answers 404 or 409 for an existing member. Without email set up on your deployment, nobody new can be added.
• Sign-in — no error when you are signed out (behaviour change): opening MITHUNAI while signed out no longer logs a 401 error in your browser’s console on any address. GET /session now answers a browser with no session 200 and {"authenticated": false, "refreshable": false} (or true when a stored sign-in can be renewed), and a signed-in answer carries "authenticated": true. A session that is presented and refused, and an API key, are still refused with 401. If your own code calls GET /session, read authenticated instead of the status.
• Conversations — readable after an assistant is turned off (behaviour change): when an assistant is disabled or archived, or has no knowledge attached, you can still read its conversations, list their messages, rename, archive and delete them. Those requests used to return 400. Asking a new question is still refused, and so are a widget visitor’s thread requests. See Lifecycle.
• Conversations — a lost answer no longer blocks the conversation (behaviour change): if the server writing an answer stops, the conversation used to answer 409 to every later question. A question sent more than 15 minutes later now takes over, and the lost answer is marked interrupted.
• Assistants — only models that can answer (behaviour change): GET /models no longer lists embedding models, and saving an assistant with one returns 400. It used to save, and then fail every question. An assistant already saved with one keeps failing until you change its model.
• Answers — a retired model says so: when a provider has retired an assistant’s model, the error reads “The requested model is not available.” rather than “The AI provider rejected the request.” See Troubleshooting.
• Knowledge — fix: cancelling a run of 25 documents or fewer now stops it; it could finish as succeeded after the cancel was accepted. A failed run no longer retries over a newer sync of the same source.
• Widget — fix: a returning visitor on a busy website finds their thread. Listing threads used to read one page of the embed’s newest threads, so other visitors’ threads could hide it; it now reads up to the 500 newest.
• API — fix: a limit, cursor or revision that is not a plain number returns 400, and a very large offset on the document endpoints returns an empty page. Each used to return a 500.
• Email — fix: on a deployment with no brand file of its own, invitation and password-reset emails now link to that deployment’s console, not to app.mithunai.com.
• Chat — a named model is the model: when your deployment names one or more models, Chat’s menu lists exactly those and opens on the first. It used to open on auto and list everything the Gateway offers, including models your provider account cannot call. See Choose a model.
• Console — fewer refusals: the console now shares what it has just read as you move between screens, and after a 429 it waits for the time the server named before sending again, so moving around quickly no longer reaches the rate limit.
• Console — fix: the members and invitations tables keep their actions on screen on a phone.
• MITHUNAI RAG — fix: on rag., the widget line, the API address and the MCP address you copy point at the platform’s address, where they work.
• Agents — sign-in: where your deployment signs in with MITHUNAI, Agents offers no sign-up of its own, an invitation signs you in with MITHUNAI and returns you to it, and a sign-in that fails returns to the sign-in page and says why.
• Gateway — fix: returning from the MITHUNAI sign-in lands you signed in, rather than going to the provider a second time.
• For MITHUNAI staff: the staff portal’s Platform Setup tab replaces Platform Setup & Health and reports only whether an assistant resolves. Its health probe, which reported every service healthy without checking any, is gone.

• MITHUNAI Team — AI employees (preview, off by default): six employees, each built for one team: Support, IT service desk, DevOps, Marketer, Sales and Finance. You hand one a piece of work; it plans it, answers from your knowledge with sources, and proposes what to do. Anything that would change another system waits in Waiting for you, where an Owner or Administrator can Approve, Edit and approve, or Reject it; an API key can never approve. What needs approval sets your organisation’s policy, and some actions, such as access changes, fixes to a running service, anything published, CRM changes, emails and preparing a payment, always need a person. Every step is recorded in What it has done, and edits people make are shown the next time the same kind of action comes up. Connect your own tools: an Owner or Administrator can connect Zendesk (Support), Jira and Jira Service Management (IT service desk, DevOps) and GitHub and Grafana Cloud (DevOps, read-only) with a token you create, and an approved action then happens there; none of these has yet been run against a real account, so try one on a sandbox first. Every other tool is a stand-in, so nothing is sent, published or changed in it; answers and reading web pages are real. See Connect your tools. The preview is switched off unless your platform administrator turns it on. See MITHUNAI Team and the AI employees API.
• Members — transfer ownership: the Owner can hand the organisation to another member with Make owner in Settings → Members. The new Owner takes over, and you stay on as an Administrator. It needs a signed-in session, never an API key. See Make someone else the Owner and POST /members/{account_id}/make-owner.
• Knowledge — Jira, Jira Service Management and Zendesk tickets (preview): Connect source reads the issues of named Jira Cloud projects, the resolved requests of a Jira Service Management service desk with their public replies only, and the solved tickets of a Zendesk Support account with their public replies only, never an internal note. Jira and Jira Service Management use the same Atlassian connection as Confluence. All three are built against recorded responses and have not yet been run against a real account. See Jira, Jira Service Management and Zendesk tickets.
• Sign in once (rolling out): one sign-in and one sign-out across every MITHUNAI product is built. When your deployment takes the update, Agents and the Gateway stop showing their own password forms and send you straight to the MITHUNAI sign-in, and signing out of any product signs you out of all of them on every device, Chat at its next sign-in renewal. Until then, sign-in works as before. See Sign in once.
• MITHUNAI RAG — its own address (rolling out): the knowledge screens are moving from app.mithunai.com to rag.mithunai.com. Old addresses forward to the new one, and the widget, the HTTP API and MCP keep their addresses, so nothing you installed changes. See MITHUNAI RAG.
• Chat — the sidebar: Chat’s sidebar is laid out like the console’s, with search at the top and More in MITHUNAI, Documentation and your account, with Sign out, at the foot. See MITHUNAI Chat.
• Widget — each visitor gets their own budget: a visitor can send 20 requests a minute, under a ceiling of 600 a minute for the whole embed, so one busy visitor no longer uses up the allowance everyone on your site shares. Visitors behind one network address share their 20. See Rate limits.
• Widget — fix: a visitor over the limit now sees “Too many requests” and the time to wait, instead of a network error.
• API — fix: an API key or a signed-in person on one server can now reach the documented 120 requests a minute; on some deployments it was refused from its 21st.
• Knowledge — fix: a scheduled re-sync of a source that has not changed now ends skipped instead of reading it all again; a sync you ask for still reads everything. See Ingestion.
• Knowledge — fix: one upload batch takes up to 200 files, the most that can then become a single source. A larger batch was accepted but could not be turned into a source.
• MCP — fix: the search_knowledge tool now says that, with no knowledge base named, it searches the knowledge your assistants answer from, which is what it does. To search another, name it; list_knowledge lists them.
• Usage — fix: the first answers of a month are no longer refused when two arrive at the same moment.
• For MITHUNAI staff: platform staff can see every organisation’s answer allowance in the staff portal. Nothing changes for customers.
• Documentation — organised by product: this site now has a tab for each MITHUNAI product, RAG, Chat, Gateway, Agents and Team, and a Platform tab for your account, sign-in, members, usage and security. Every old address still works.

• Members — invite by email (preview): in Settings → Members, an Owner or Administrator enters an address and a role and selects Send invitation. The person chooses their own password from the link and needs no account first; an address that already has one confirms with its existing password. A link works once, for seven days. Pending invitations can be re-sent or revoked. Email is off on a deployment until its operator sets up a mail provider, and until then the form says so and is turned off. See Invitations and POST /invitations.
• Members — change a role or remove a member: Change role and Remove member in a member’s row. Removing someone signs them out, stops the API keys they created in your organisation and withdraws the invitations they sent. Nobody can act on their own seat, the Owner’s or a more senior one, and these changes take a signed-in session, never an API key. See Members, PATCH and DELETE /members/{account_id}. Ownership cannot be transferred yet.
• Sign-in — reset a forgotten password (preview): Forgot password? on the sign-in screen emails a link that works once, for 30 minutes. Choosing a new password signs you out of the console on every device. It needs email, as above. See Password reset.
• Usage — a monthly answer allowance: each organisation has a number of answers its assistants may give in a calendar month, counted the same way on the Playground, the widget, the API and MCP. The Dashboard shows Answers this month, warns at 80%, and says when the count starts again. At the limit, new questions are refused with 429 quota_exceeded until the next month; everything else keeps working. Read it with GET /usage. It counts answers, not spend. See Usage and limits.
• Knowledge — saved connections: Settings → Connections holds your organisation’s own tokens for GitHub, Confluence and Notion, encrypted and never shown again, each sent only to the service it belongs to. Replace a token without touching the sources that use it. See Saved connections and the Connections API.
• Knowledge — Confluence, Notion and private GitHub (preview): Connect source has Confluence (Cloud sites) and Notion under Knowledge bases, and This repository is private under GitHub. Each reads with a saved connection. Confluence and Notion have been tested against scripted responses written from each service’s documentation, not yet against real sites; private GitHub has not yet been run against a real private repository. See Confluence, Notion and Private GitHub.
• Analyze — Top questions (preview): what people asked your assistants most in the last 7, 30 or 90 days, answered or not, with a CSV export. It never shows who asked: a question is listed only once three different people have asked it. See Top questions and GET /analytics/top-questions.
• Analyze — coverage gaps grouped by meaning (preview): Group similar questions now puts together questions that mean the same thing in different words, and says Grouped by wording only when it could not compare meaning. See Coverage gaps.
• Console — the sidebar: one line per screen, with what each is for in a tooltip; search at the top; Documentation and your account, with Sign out, at the foot. No screen moved. See Console walkthrough.
• Documentation — one place: /docs and /documentation on the console, Chat, Agents and the Gateway now open this site, and the Gateway’s /v1/docs opens its section here. See Other surfaces.
• Widget — fix: a declined answer read back after a reload no longer tells a website visitor to connect a source.
• Security: a Confluence or Notion token is sent only to the one host it belongs to, through the same network protections as every other fetch; a redirect to another host is refused before anything is sent. See Security.
• Documentation: Product status now says what has been run end to end against the product as it ships, and what has not.

• Widget — Add Ask AI to your website in three steps: under Integrations → Website widget, enter your website’s address, copy one line, and select Check my website. The first step connects your website as a source, prepares an assistant and creates the embed for you; running it again creates nothing twice. Email to my developer hands the line to whoever edits your site. See Website widget.
• Widget — Check my website: MITHUNAI reads a page of your site and reports whether the line is on it, whether it carries the right key and whether the address is one the embed allows, with an Allow button when it is not. It reads the page’s HTML only and does not follow redirects. Also available as POST /widget-deployments/{deployment_id}/installation-check. See What the check reports.
• Widget — one line to install: the snippet is a single script tag, configured by data- attributes on the tag itself: data-api-base-url and data-widget-key, plus an optional attribute for each setting. Snippets already on a page keep working unchanged. The widget guide gained installation steps for WordPress, Shopify, Webflow, Wix, Google Tag Manager, Next.js and Docusaurus, and says which of them MITHUNAI has verified itself. See Install it on your platform.
• Widget — Ask AI: the launcher is labelled Ask AI, and the snippet takes three more optional settings for its label, for hiding the launcher and for a keyboard shortcut. Your page can drive the widget with open, close, toggle, ask and isOpen, and listen for mithunai: events. A conversation is kept when the panel is closed, the page reloads or the visitor moves to another page in the same tab, and a visitor can copy an answer or rate it up or down. A thumbs down appears in Coverage gaps. See Customise the widget.
• Widget — allowed websites: a deployment can let each embed’s own list of allowed origins decide where the widget loads, so adding your website needs no change by the operator. It is a deployment setting; if a listed website is still refused, ask whoever operates your deployment.
• Widget — fix: a website visitor’s question is answered from the embed’s assistant and its knowledge. Earlier in this release some visitor questions were refused instead of answered.
• Console — Dashboard, Configure, Deploy and Analyze: the console opens on a Dashboard and groups the rest by what you are doing. Knowledge is now Sources, Ask is Playground, Assistants is Customizations and Unanswered is Coverage gaps. Operations is gone: usage moved to the Dashboard, API keys and Integrations (the widget and MCP) are destinations of their own, and the deployment map is under Settings. Old links and bookmarks still open the right screen. See Console walkthrough.
• Console — the setup guide ends on your website: the first-run guide on the Dashboard has a fifth step, Put it on your website, which opens the three-step widget setup.
• Knowledge — seven more source types: custom answers you write yourself, OpenAPI and Swagger schemas in JSON or YAML, public Zendesk help centres, public Discourse forums, and a GitHub repository’s issues, pull requests and, in preview, discussions. None takes a credential, so a help centre or forum that needs signing in cannot be connected. See Connectors.
• Knowledge — edit, rename, pause and resume a source: a source’s settings can be changed after it is created, with PATCH /knowledge/sources/{source_id} or from its menu in the console. Saving an edit reads nothing; the next sync applies it. See Sources.
• Analyze — source analytics: which of your sources the answers cite, and which documents in them, with a CSV export in the console and GET /analytics/sources. See Source analytics.
• Analyze — grouped coverage gaps (preview): Group similar questions collects near-identical wording into one row, and group=true does the same over the API. It matches wording, not meaning: two questions that say the same thing in different words stay apart. See Coverage gaps.
• Analyze — Conversations: a read-only list of what was asked and answered. Owners and Administrators see the whole organisation’s; reading a conversation you did not take part in is now recorded in the audit trail. See Conversations.
• Documentation: the guides are grouped by what you are doing — get started, knowledge sources, answers and assistants, deploy, analyze, administration — with a page for each Analyze screen, for Settings, and for Chat, Agents and the Model Gateway as surfaces of the product. Existing addresses still work.
• Documentation correction: these pages described Agents as in preview and said one account opened every surface. Agents is deployed but not open to customers yet, and Agents and the Gateway each still show a sign-in form of their own beside the MITHUNAI sign-in. They also said every model call goes through the Model Gateway; Chat’s do, and the console’s assistants use whichever providers the operator configured. See Other surfaces.
• Documentation correction: the Gateway pages misdescribed several behaviours, among them the failover breaker, which stops one request and not one model, the response cache’s temperature ceiling, which defaults to 1.0, and who administers the Gateway. See Guardrails and settings and Keys and budgets.
• Documentation correction: these pages said MITHUNAI never re-syncs on a schedule. A deployment can, on one interval for every source, and it is off unless the deployment’s operator turns it on. See Scheduled re-sync.

• Gateway — conditional routing: an operator can store an ordered list of rules, each a condition over facts the Gateway derives from the request (endpoint, streaming, tools, task type, detected client, requested model) plus client-declared labels, and the chain or routing axis to use when a rule matches. An explicit auto:<chain> from the client always wins, so a rule can never override a deliberate choice. See Routing and failover.
• Gateway — guardrails in the dashboard: the output token cap, the per-request token budget, the failover circuit breaker, the two headroom thresholds, the task-type weight shift and the response cache can all be set under Settings → Gateway. See Guardrails and settings.
• Gateway — free-tier pools and chain auto-ordering: the analytics panel groups models into the free-tier pools they actually share, counting one allowance per pool and scaling it by the usable credentials you hold, instead of double-counting every model’s label. A chain can be reordered by capability, measured speed or monthly allowance; a preset writes priority only and never switches a model on or off. See Models and cost.
• Console — a Knowledge section: Knowledge became a section with Ingestion and Unanswered under it. The mid-October release reorganised this again; see the entry above.
• Console — a staff entrance: #/staff opens the console for platform staff. It is the same sign-in, and where a person lands is decided from the account that signed in, never from the address they typed. See The staff entrance.
• Sign-in — one account across the surfaces (preview): Chat signs in through the MITHUNAI sign-in, and Agents and the Gateway now offer it too, alongside the email-and-password form each still shows. See One sign-in.
• Security: an ingestion job now re-checks that an uploaded file belongs to the organisation asking for it before reading it, as uploading and deleting already did. See Security.
• Documentation: the Gateway section gained the catalogue, routing, keys and guardrails pages.

• Members: list the people in your organisation and add a colleague who already has an account, with GET and POST /members. There are no invitations, role changes or removals yet.
• Answers: answer.completed now carries abstention_reason, so a client can tell “nothing in your sources covers this” from “something does, but not closely enough”. The widget receives a coarser unsupported or unavailable. The reason is not stored, so a message read back later, or a replayed turn, carries none. See Stream a message.
• Branding: the terms link now appears in the console footer, and the switches for the “Powered by MITHUNAI” line and for branding in the widget now take effect. The console opens in the light theme by default.
• Access: the console’s sign-up form explains that accounts are provisioned rather than creating one. Request a demo at mithunai.com.
• Documentation corrections: pages that described webhooks, SDKs, a command-line tool, extra connectors, a response cache and compliance certifications as available now say plainly that they are not, and what to use instead.

​

Introducing MITHUNAI

• Knowledge: connect websites, sitemaps, GitHub repositories and uploaded PDF, Word, Markdown and text files, with background ingestion you can monitor and cancel.
• Answers: grounded answers with citations, abstention when content does not support an answer, and streaming.
• Assistants: several assistants per organisation, each with its own knowledge, model and guidance.
• Channels: the HTTP API, the website widget and a read-only MCP server (preview).
• Administration: roles, API keys, organisation branding, usage and unanswered-question reports.
• Console: redesigned, with the new MITHUNAI brand.