| askA | YOUR DEFAULT MOVE on anything non-trivial — use it liberally and early, don't wait to be told and don't wait until you're stuck. Reach for it BEFORE you guess at unfamiliar code, an API, or a library's behavior; whenever you weigh a design or refactor trade-off; when a bug isn't fully understood; or to have a strong reasoner sanity-check a plan or diff before you commit it. One well-framed ask with the code attached beats several bare ones. ask_opus5 is this same tool on Claude Opus 5 — cheaper and faster; use it for high-volume or long back-and-forth work and keep ask for the hardest calls. Ask the Fable model to reason about the SOFTWARE/ENGINEERING work you're doing: code structure, functionality, data/control flow, module and function relationships, routing, architecture, and design trade-offs. For questions about EXISTING code, ALWAYS paste the real code into context — the actual function/file/snippet the question is about, plus any error or failing test. The model has NO tools and CANNOT open files, so a bare file path is useless to it. Conceptual/brainstorming questions need no context and are welcome. Frame each call as ONE specific decision ('should X or Y given constraint Z' beats 'thoughts on this code?') or ONE generative prompt ('give me 5 approaches to X, with trade-offs'). Reuse the session key to think through a problem over several follow-up turns instead of restating everything. Answers usually take 1–3 minutes. Broad and conceptual engineering questions — including brainstorming and ideas for future code — are fine. Refused only when the question itself directly asks for offensive-security work (exploit development, attack tooling) or non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope); questions about security-related code are normal engineering. The result carries a sidecar ({recommendation, confidence, needs_context}); when the model needs more, it returns a followup telling you exactly what to paste — paste those (or context_write them and pass context_ref) and re-ask on the SAME session, but first check followup.likely_already_pasted and RE-READ your own paste rather than resending it. A context_exhausted status means the model still can't answer after repeated tries — stop re-asking and use your own judgment. |
| ask_opus5A | The same guarded, multi-turn reasoning as ask, but on Claude Opus 5 (claude-opus-5) instead of Fable — identical arguments, identical result shape (sidecar, followup, context_exhausted), same session/reset conversation model. Reach for it exactly where you'd reach for ask: before guessing at unfamiliar code, when weighing a design trade-off, or to sanity-check a plan or diff. WHICH ONE: Opus 5 is roughly half Fable's price and noticeably faster, so prefer it for high-volume or latency-sensitive reasoning and for long back-and-forth sessions; keep ask (Fable) for the hardest, most consequential single calls. Running BOTH on the same question is a cheap two-model cross-check without paying for a full council. Sessions are namespaced per tool: the same session key on ask and ask_opus5 is two independent conversations (use reset_session(model='opus5') to clear this one). The model has NO tools and CANNOT open files — paste the real code into context (or point at it with context_ref). Same scope as ask: broad and conceptual engineering questions, including brainstorming and ideas for future code, are fine; refused only for direct offensive-security asks (exploit development, attack tooling) and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope). Opus 5 also works as the opus token in every multi-model mode — ask_council member or synthesizer, ask_chain stage, ask_debate proposer/opponent/adjudicator. |
| ask_m3A | Ask the MiniMax model (MiniMax-M3) — on its own, independent of Fable — to reason about the SOFTWARE/ENGINEERING work you're doing: code structure, functionality, data/control flow, module and function relationships, routing, architecture, and design trade-offs. Broad and conceptual engineering questions (including brainstorming/ideas for future code) are fine — add a snippet or file path in context when the question is about existing code. Single-turn. Direct offensive-security asks (exploit development, attack tooling) and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. Use ask for Fable, or ask_council to ask both and get a synthesized answer. |
| ask_glmA | Ask the GLM model — on its own, independent of Fable — to reason about the SOFTWARE/ENGINEERING work you're doing: code structure, functionality, data/control flow, module and function relationships, routing, architecture, and design trade-offs. Broad and conceptual engineering questions (including brainstorming/ideas for future code) are fine — add a snippet or file path in context when the question is about existing code. Single-turn. Served by Z.ai's Anthropic-compatible endpoint (GLM-5.2) when ASK_FABLE_GLM_API_KEY is set; otherwise it falls back to Atlas-hosted GLM-5.3 on the Atlas key, and is only reported as not_configured when neither is available. Direct offensive-security asks (exploit development, attack tooling) and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. Use ask for Fable, ask_m3 for MiniMax, or ask_council to ask several and get a synthesized answer. |
| ask_deepseekA | Ask the DeepSeek model (deepseek-v4-pro, via DeepSeek's Anthropic-compatible endpoint) — on its own, independent of Fable — to reason about the SOFTWARE/ENGINEERING work you're doing: code structure, functionality, data/control flow, module and function relationships, routing, architecture, and design trade-offs. Cheap direct API — prefer it (like ask_m3/ask_glm) over pricier cloud models for a quick independent opinion. Broad and conceptual engineering questions (including brainstorming/ideas for future code) are fine — add a snippet or file path in context when the question is about existing code. Single-turn. Requires ASK_FABLE_DEEPSEEK_API_KEY configured on the server (reported as not_configured otherwise). Direct offensive-security asks (exploit development, attack tooling) and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. Use ask for Fable, ask_m3 for MiniMax, ask_glm for GLM, or ask_council to ask several and get a synthesized answer. |
| ask_geminiA | Ask Google's Gemini model (Gemini 3.1 Pro, via the local agy CLI) — on its own, independent of Fable — to reason about the SOFTWARE/ENGINEERING work you're doing: code structure, functionality, data/control flow, module and function relationships, routing, architecture, and design trade-offs. Broad and conceptual engineering questions (including brainstorming/ideas for future code) are fine — add a snippet or file path in context when the question is about existing code. Single-turn. Requires the agy CLI installed and signed in on the server (reported as binary_missing otherwise). Direct offensive-security asks (exploit development, attack tooling) and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. Use ask for Fable, ask_m3 for MiniMax, ask_glm for GLM, or ask_council to ask several and get a synthesized answer. |
| ask_codexA | Ask OpenAI's model (GPT-5.6 Sol, via the local codex CLI in non-interactive codex exec mode) — on its own, independent of Fable — to reason about the SOFTWARE/ENGINEERING work you're doing: code structure, functionality, data/control flow, module and function relationships, routing, architecture, and design trade-offs. Broad and conceptual engineering questions (including brainstorming/ideas for future code) are fine — add a snippet or file path in context when the question is about existing code. Runs hermetically and read-only (it can't see or touch your repo — put the code it needs in context). Single-turn. Requires the codex CLI installed and logged in on the server (reported as binary_missing otherwise). Direct offensive-security asks (exploit development, attack tooling) and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. Use ask for Fable, ask_m3 for MiniMax, ask_gemini for Gemini, ask_glm for GLM, or ask_council to ask several and get a synthesized answer. |
| ask_grokA | Ask xAI's Grok model (grok-4.6 by default, via the local grok CLI in single-turn -p mode) — on its own, independent of Fable — to reason about the SOFTWARE/ENGINEERING work you're doing: code structure, functionality, data/control flow, module and function relationships, routing, architecture, and design trade-offs. PREFER THIS over ask_atlas with xai/grok-* whenever the grok binary is installed (uses your grok login session; no Atlas API key). Runs hermetically (tools disabled; put the code it needs in context). Single-turn. Requires the grok CLI installed and logged in on the server (reported as binary_missing otherwise). Broad and conceptual engineering questions (including brainstorming/ideas for future code) are fine. Direct offensive-security asks (exploit development, attack tooling) and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. Use ask for Fable, or ask_council with model token grok to include Grok in a multi-model panel. |
| ask_kimiA | Ask Moonshot's Kimi model (kimi-code/k3 by default, via the local kimi CLI in single-turn mode) — on its own, independent of Fable — to reason about the SOFTWARE/ENGINEERING work you're doing: code structure, functionality, data/control flow, module and function relationships, routing, architecture, and design trade-offs. PREFER THIS over ask_atlas with moonshotai/kimi-* whenever the kimi binary is installed: it runs on your Kimi Code subscription instead of per-token Atlas billing. NOTE the context caveat: k3 is a 1M-context model, but this CLI takes the prompt as a single argv value, which the kernel caps near 131k bytes — larger prompts are refused with a pointer to ask_atlas ('moonshotai/kimi-k3'), which has no such limit. The turn is sandboxed to pure text reasoning — the model has NO filesystem or tool access, so put the real code in context. Single-turn. Requires the kimi CLI on PATH and a completed kimi login (reported as binary_missing / not_configured otherwise). Direct offensive-security asks (exploit development, attack tooling) and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. Use ask for Fable, ask_m3 for MiniMax, or ask_council to ask several and get a synthesized answer. |
| ask_councilA | DIRECTIONAL — reserve this for a genuinely contentious or HARD-TO-REVERSE decision (architecture, concurrency, data model, public API, migration) where a single opinion isn't enough and you want several models cross-checked, or for divergent brainstorming where you want independent idea sets merged without losing distinct options. It's slower and heavier than ask, so DON'T reach for it on routine questions — default to ask, and use at most one council call per problem. Check quorum/degraded in the result: a 1-of-N answer is one opinion, not consensus. Ask several models at once the same SOFTWARE/ENGINEERING question, then get back one answer that Fable synthesizes by reconciling all of them (each raw answer is also returned under sources). By default asks Fable (whichever id is newest) + MiniMax (MiniMax-M3), plus DeepSeek (deepseek-v4-pro) when ASK_FABLE_DEEPSEEK_API_KEY is configured — cheap direct models are preferred and consulted first. Pass models to choose from ['fable','fable51','opus','deepseek','minimax','glm','gemini','codex','grok','kimi'] ('fable' tracks the newest Fable automatically and 'fable51' pins claude-fable-5-1 even after it stops being newest — they are the same model today, so naming both buys you nothing; 'opus' is Claude Opus 5 on the same OAuth session as Fable — always available, half the price; 'gemini'/'codex'/'grok'/'kimi' need their local CLIs; 'glm'/'deepseek' need API keys configured on the server). You can also add Ollama Cloud models as 'ollama:' tokens (e.g. 'ollama:qwen3-coder:480b-cloud', 'ollama:nemotron-3-ultra:cloud'); these are reached via a local signed-in ollama daemon by default (reported+skipped if unreachable). The group token 'twin' (aka 'twin flames') expands to BOTH Anthropic reasoners at once — fable + opus — so models=['twin'] is a dual Fable/Opus 5 invocation and models=['twin','minimax'] adds a third voice to it. Both ride the OAuth session, so it needs no provider keys and is the cheapest real second opinion available. Instead of listing models, you can pass a named tier: 'default' (fable+minimax, +deepseek when its key is configured), 'twin' (the twin flames, fable+opus), 'middle' (all of the above +opus+glm+gemini+codex+grok+kimi, cheap models first), or 'full' (+the configured Ollama Cloud models). The result carries a consensus signal ('strong' | 'partial' | 'divergent' | 'unknown') and material_disagreement computed from the panelists' recommendations, and each entry in sources shows that model's recommendation — so you can see WHO endorsed what, not just the merged answer. Panel answers are anonymized to the synthesizer to blunt self-preference bias. Pass synthesizer to have a different model adjudicate the panel (default 'fable'; e.g. 'opus' = Claude Opus 5, 'codex'/'gpt' = GPT-5.6 Sol via the local CLI, or 'atlas:openai/gpt-5.6-sol') — it falls back to Fable when unavailable or failing, and the result's synthesis block reports what actually ran. Same scope as ask: broad and conceptual engineering questions (including brainstorming) are fine; direct offensive-security asks and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. |
| ask_chainA | DIRECTIONAL, SEQUENTIAL — the relay counterpart to ask_council. Where the council asks N models the SAME question in parallel and synthesizes their independent answers ('what's true?'), the chain threads a question through an ORDERED pipeline where each stage refines the last ('make this answer better'). The operator sets the order as a pipeline string like 'm3 > glm > deepseek > fable' (or an ordered models array). Stage 1 drafts; each middle stage is told to solve independently and CRITIQUE the prior draft before extending it (an anti-anchoring guard); the final stage DECIDES, seeing all prior stages as anonymized peers. Best for two things a council can't do: cost-tiered escalation (a cheap/fast model does the legwork, Fable finalizes) and explicit draft → red-team → decide pipelines. Costs MORE latency than a council (stages run sequentially, not in parallel), so reserve it for when the ordered refinement is the point. Draft → critique → refine is also a natural IDEATION pipeline: a cheap model brainstorms broadly, later stages prune and sharpen the ideas. Order matters and repeats are allowed ('fable > glm > fable' = draft, critique, re-decide). A mid-chain model that refuses/errors is skipped (recorded); if the final stage fails, Fable synthesizes the survivors. The result carries a recommendation_drift trail and material_drift flag — the chain analogue of the council's consensus signal — so you can see whether the answer was refined or just rubber-stamped. Same scope as ask: broad and conceptual engineering questions (including brainstorming) are fine; direct offensive-security asks and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. Aliases: 'm3' = minimax, 'opus5' = opus. Any stage can be 'opus' (Claude Opus 5) — a cheaper, faster terminus than Fable, e.g. 'm3 > opus'. The group token 'twin' (aka 'twin flames') expands in place to two stages, fable then opus, so 'm3 > twin' is a cheap draft finished by both Anthropic reasoners in turn. Default pipeline if none given: minimax > fable. |
| ask_debateA | DIRECTIONAL, ADVERSARIAL — pit two models AGAINST each other over a structured claims ledger, then have a fresh third model adjudicate. Unlike ask_council (N models vote independently) or ask_chain (each stage refines the last), the debate makes one model PROPOSE a position decomposed into load-bearing claims, the other REFUTE each claim (concede or contest-with-a-concrete-failure-scenario), the proposer REVISE under fire, and an anonymized adjudicator RULE on the merits. Reserve it for a genuinely contentious, hard-to-reverse SOFTWARE decision where you want the strongest case for AND against stress-tested — 'is this concurrency design sound', 'should we commit to approach X or Y' — not for questions with a clear answer. Pick the pair with proposer and opponent (e.g. proposer='fable', opponent='codex' for Fable vs GPT-5.6 Sol, or opponent='glm'); defaults to fable vs minimax. adjudicator picks who rules (default 'fable'; e.g. 'opus' for Claude Opus 5, or 'codex') — keep it off the debating pair so the ruling stays third-party. rounds is 1 (default) or 2 (adds a rebuttal pass). The server decides the outcome deterministically from the ledger — resolution is 'conceded' (opponent conceded everything), 'converged' (all contests resolved and both sides agree), 'adjudicated' (the adjudicator decided), or 'stalemate' (both dug in with nothing new → confidence is mechanically downgraded). Costs up to four sequential model calls, so it's the most expensive mode — use it sparingly. Degrades to a single-critic pass when the opponent is unconfigured. Same scope as ask: broad and conceptual engineering questions are fine; direct offensive-security asks and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. Aliases: 'm3' = minimax, 'gpt' = codex, 'opus5' = opus. |
| ask_ollamaA | Ask a single Ollama Cloud model — on its own — to reason about the SOFTWARE/ENGINEERING work you're doing: code structure, functionality, data/control flow, module and function relationships, routing, architecture, and design trade-offs. Pass model to pick a cloud model (e.g. 'kimi-k2.7-code:cloud', 'gpt-oss:120b-cloud', 'deepseek-v3.2:cloud'); omit it to use the server's default. Reached via a local signed-in ollama daemon by default (no API key needed). Single-turn. Broad and conceptual engineering questions (including brainstorming/ideas for future code) are fine — add a snippet or file path in context when the question is about existing code. Direct offensive-security asks (exploit development, attack tooling) and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. Use ask_council to mix Ollama models with Fable. |
| ask_ollama_councilA | DIRECTIONAL — the Ollama-only counterpart to ask_council: reserve it for a contentious or hard-to-reverse decision you want several cloud models to cross-check, not for routine questions (default to ask; at most one council call per problem, and check quorum/degraded in the result). Ask several Ollama Cloud models the same SOFTWARE/ENGINEERING question at once, then get back one answer that Fable synthesizes by reconciling all of them (each raw answer is also returned under sources). Pass models as a list of cloud model ids (e.g. ['qwen3-coder:480b-cloud', 'nemotron-3-ultra:cloud','kimi-k2.7-code:cloud']); an 'ollama:' prefix is optional. Omit models to use the server's configured set (ASK_FABLE_OLLAMA_COUNCIL). Reached via a local signed-in ollama daemon by default (no API key needed). Use ask_council instead to mix Ollama models with Fable/MiniMax/GLM/DeepSeek in one council. Same scope as ask: broad and conceptual engineering questions (including brainstorming) are fine; direct offensive-security asks and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. |
| ask_atlasA | Ask a single Atlas Cloud text model — on its own — to reason about the SOFTWARE/ENGINEERING work you're doing: code structure, functionality, data/control flow, module and function relationships, routing, architecture, and design trade-offs. Pass model to pick from 60+ models (e.g. 'xai/grok-4.6', 'openai/gpt-5.6-sol', 'anthropic/claude-opus-4.8', 'deepseek-ai/deepseek-v4-pro'); omit it to use the default. Pass effort (quick/standard/deep; default deep — max reasoning) to set the answer budget. REACH FOR THIS the first time an Atlas model is wanted: call list_atlas_models(task=<the user's job>); use an accepted native selection when one is returned, or render its structured picker fallback, then call ask_atlas with the selected model and effort (the catalog endpoint is free — no tokens charged). PREFER ask_grok (local grok CLI) over Atlas for xAI Grok models when the binary is installed — ask_atlas with xai/grok-* auto-routes to the local CLI when available. Other Atlas models remain HTTP. Atlas models are ALSO reachable in ask_council / ask_chain / ask_debate as dynamic atlas:<model> tokens, e.g. 'atlas:xai/grok-4.6' (Grok tokens prefer the local CLI when present). OpenRouter models join the same way as 'openrouter:'. Single-turn. Needs ASK_FABLE_ATLAS_API_KEY (or the ATLASCLOUD_API_KEY the Atlas Cloud MCP server already uses) for non-Grok models. Broad and conceptual engineering questions (including brainstorming/ideas for future code) are fine — add a snippet or file path in context when the question is about existing code. Direct offensive-security asks (exploit development, attack tooling) and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. |
| ask_atlas_councilA | DIRECTIONAL — the Atlas-only counterpart to ask_council, with GPT-5.6 Sol as the default adjudicator: reserve it for a contentious or hard-to-reverse decision you want several Atlas Cloud models to cross-check, not for routine questions (default to ask; at most one council call per problem, and check quorum/degraded in the result). Ask several Atlas Cloud models the same SOFTWARE/ENGINEERING question at once, then get back one answer the adjudicator synthesizes by reconciling all of them (each raw answer is also returned under sources). The adjudicator defaults GPT-first: the local codex CLI (GPT-5.6 Sol, no Atlas tokens) when installed, else Atlas-hosted 'openai/gpt-5.6-sol', else Fable — override with synthesizer (any council token) or persist a choice with configure_atlas_council; the result's synthesis block reports what actually adjudicated. Pass models as a list of Atlas model ids (e.g. ['zai-org/glm-5.2','deepseek-ai/deepseek-v4-pro', 'moonshotai/kimi-k2']; an 'atlas:' prefix is optional). Omit models to use the configured set (configure_atlas_council / ASK_FABLE_ATLAS_COUNCIL), else 3 featured catalog models, one per provider. Needs ASK_FABLE_ATLAS_API_KEY (or the ATLASCLOUD_API_KEY the Atlas Cloud MCP server already uses); xai/grok-* members reroute to the local grok CLI when installed, no key needed. Use ask_council instead to mix Atlas models with Fable/MiniMax/GLM/DeepSeek in one council. Same scope as ask: broad and conceptual engineering questions (including brainstorming) are fine; direct offensive-security asks and non-software domain knowledge (biology/medicine refused; neuroscience, cognitive science, AI/ML, and CS are in-scope) are refused. |
| ask_openrouterA | Ask ONE model on OpenRouter — a single gateway fronting ~400 models from every major lab (Anthropic, OpenAI, Google, DeepSeek, Meta, Qwen, Moonshot, xAI, Mistral, …) behind one API key. Use it to reach a model this server has no dedicated tool for, or to compare the same question across labs without configuring each provider separately. Guarded and single-turn, same scope rules as every other ask tool. PICK A MODEL FIRST: call list_openrouter_models(task='…') — the catalog is free and needs no key — then offer the user the ranked shortlist with its prices before spending anything. Omitting model uses the server default. effort is quick/standard/deep (default deep); because OpenRouter publishes each model's supported reasoning efforts, deep asks for the most the chosen model actually supports instead of guessing. COST: this bills the operator's OpenRouter credit per token, and the result reports the real dollar cost of the call. Prefer a dedicated tool when one exists for the same model — ask / ask_opus5 (Claude on the operator's OAuth session, no per-token cost), ask_grok, ask_kimi, ask_deepseek. Grok and Kimi ids are rerouted to those local CLIs automatically when they are installed. Any model here also works in ask_council, ask_chain, and ask_debate as an 'openrouter:' token. |
| ask_openrouter_councilA | Ask SEVERAL OpenRouter models the same question in parallel, then have an adjudicator reconcile their answers into one. The point is cross-LAB diversity on a single API key: a panel of Claude + GPT + Gemini + DeepSeek disagrees in more useful ways than three models from one vendor, and you configure none of them separately. Same fan-out/synthesis contract and consensus signal as ask_council. models takes OpenRouter ids (the 'openrouter:' prefix is optional); omit it to use the configured set (configure_openrouter_council), else 3 featured catalog models, one per provider. The adjudicator defaults GPT-first: the local codex CLI when installed, else OpenRouter-hosted GPT-5.6 Sol, else Fable. COST: this is N billed calls plus a synthesis — reserve it for a contentious, hard-to-reverse decision, exactly as with ask_council. Grok and Kimi members reroute to the local CLIs when installed. |
| configure_openrouter_councilA | Persist the default panel for ask_openrouter_council (and optionally its adjudicator) to the server's config file, so the choice survives restarts without anyone hand-editing an env var. Pass models (OpenRouter ids) and/or synthesizer (any council token, or a bare OpenRouter id). Call list_openrouter_models first and let the user pick — this writes a durable default on their behalf, so it should reflect their choice, not yours. |
| list_openrouter_modelsA | List the live OpenRouter catalog — ~400 models with price per million tokens, context window, and which reasoning efforts each one accepts. FREE: the catalog endpoint needs no API key and costs nothing, so call it before ask_openrouter rather than guessing a model id. Pass task='…' to rank a provider-diverse shortlist for that job; ranking reads the catalog's own fields (reasoning support, context length, price, release date), so a model released today ranks correctly with no update here. A task mentioning cheap/fast/high-volume flips the ranking toward the cheap and free tiers; otherwise it leads with capable models. Show the user the shortlist with prices and let them choose — do not silently pick an expensive model on their behalf. |
| list_atlas_modelsA | RECOMMEND AND PICK an Atlas Cloud text model. When the user asks for the best Atlas model(s) for a job, pass that job as task; the tool ranks the live catalog and opens a native model + effort selection popup when the MCP client supports form elicitation, with a structured picker fallback otherwise. Returns the live catalog (no auth needed; free, no tokens charged) as a ready-to-render menu: task-ranked recommendations, featured (~8 curated models, HOT/NEW-tagged, one per provider), the full menu (each with model_id, label, cost_note like '$2/$6 per M', provider, tags, context length, latency), and effort_choices (quick/standard/deep). REACH FOR THIS the first time an Atlas model is wanted. If selection.action is accept, call ask_atlas with the selected model and effort; if native elicitation is unavailable, show picker with the host's selection UI. Read-only. |
| list_ollama_modelsA | List the Ollama Cloud models available to put in the council, so you can offer the user a real, concrete choice instead of guessing. Returns the live ollama.com catalog (GLM, MiniMax-M3, Qwen, Kimi, DeepSeek, Nemotron, Mistral, gpt-oss, …) as daemon-ready ids, the models already pulled locally (certain to run right now), and the council that's currently configured. REACH FOR THIS the first time an Ollama council is wanted or when the user asks to configure ask_fable: call this, show the options, ask which they want, then persist the choice with configure_ollama_council. Read-only. |
| configure_ollama_councilA | Save the user's chosen Ollama Cloud council so it sticks across sessions (written to ask_fable's config file, which overrides the ASK_FABLE_OLLAMA_* env defaults). Pass models as the list of cloud model ids to use for ask_ollama_council and the full tier (e.g. ['minimax-m3:cloud', 'glm-5.2:cloud', 'qwen3-coder:480b-cloud']; an 'ollama:' prefix is optional and a bare name like 'minimax-m3' is normalized to 'minimax-m3:cloud'). Optionally set default_model for the single-model ask_ollama tool. Confirm the selection with the user first — call list_ollama_models to ground it in what's actually available. Returns the saved config and its file path. |
| configure_atlas_councilA | Save the user's chosen Atlas Cloud council (and optionally its adjudicator) so it sticks across sessions (written to ask_fable's config file, which overrides the ASK_FABLE_ATLAS_COUNCIL / ASK_FABLE_ATLAS_SYNTHESIZER env defaults). Pass models as the list of Atlas model ids ask_atlas_council should use by default (e.g. ['zai-org/glm-5.2','deepseek-ai/deepseek-v4-pro', 'moonshotai/kimi-k2']; an 'atlas:' prefix is optional). Optionally set synthesizer ('gpt' = the local GPT-5.6 Sol CLI, 'openai/gpt-5.6-sol' = the Atlas-hosted one, 'fable', …); omit it to keep the built-in ladder (local codex CLI → Atlas-hosted GPT-5.6 Sol → Fable). Confirm the selection with the user first — call list_atlas_models to ground it in the live catalog. Returns the saved config and its file path. |
| configure_tracingA | Toggle reasoning-trace capture at runtime, persisted across sessions (writes ask_fable's config file, which overrides the ASK_FABLE_TRACE_MODE / ASK_FABLE_STREAM_REASONING env defaults — no ~/.claude.json edit or restart needed; it applies on the next call). trace_mode='full' records redacted model reasoning into traces and trace bundles (and saves answer markdown); 'safe' withholds reasoning content while structural traces still record. stream_reasoning=true|false turns live thinking on the server console on or off. Pass either or both. Returns the effective settings and the config path. |
| context_writeA | Store a chunk of context (code, file contents, a stack trace, design notes) under a stable key so you paste it ONCE and reuse it. Then pass context_ref='<key>' on ask to pull it in instead of re-pasting the same code into every call — the big lever against the re-paste tax, since the model can't see your repo. The store is shared by every agent on this server, so a sibling agent can context_read what you wrote. Reusing a key overwrites it. Give a one-line description so it shows usefully in context_list. |
| context_packA | Point, don't paste. The reasoning models can't see your repo, but THIS server runs locally next to it — so instead of hand-pasting code, NAME the files (and optional line ranges) you want and let the server read them, apply a character budget, and store the bundle on the context bus under key. Then pass context_ref='<key>' on ask / councils exactly as usual. Each spec is path or path:START-END (1-indexed inclusive), relative to the configured project root; reads never escape that root, and .git//.env* are refused. Requires an operator-configured project root (config project_root or the ASK_FABLE_PROJECT_ROOT env var) — returns not_configured if unset. Over-budget or unreadable specs are reported in skipped with a reason and complete:false; nothing is silently truncated, and if nothing can be packed the store is left untouched. |
| context_readA | Read back context previously saved with context_write, by key. Returns the stored value plus its size, age, and description; not_found if the key isn't set. Use it to inspect a shared blob, or to consume context another agent wrote. |
| context_listA | List what's in the shared context store — each key with its size, age, and description (never the full value). Read-only. Reach for this to discover what context is already available to reference via context_ref before re-pasting. |
| context_deleteA | Delete a stored context by key (housekeeping once a blob is no longer needed). Returns whether a row was removed. |
| reset_sessionA | Dump (optionally to a file) and clear a Fable conversation session, so the next ask on that key starts a fresh topic. |
| statsA | Read-only usage/health stats aggregated from the ask_fable audit log — see how the tools are performing without spelunking JSONL. Buckets every recorded call over a time window ('1h' | '24h' | '7d' | 'all', default '24h') by 'model', 'session', or 'day', reporting calls / allowed / refused / errors, avg and p95 latency, and error_rate per bucket plus totals. Optional model / session filters narrow to one backend or workflow. Council/chain records also carry quorum, consensus, and synth_fallback in the log. Use it to answer things like 'is GLM erroring a lot today?' or 'how slow are councils this week?'. Makes no model call and is never cached. |
| trace_listB | List recent correlated tool traces without raw content. |
| trace_getB | Read the ordered events and artifact references for one trace. |
| session_listA | COORDINATION — the operator dashboard. Lists ask_fable sessions across instances on this machine (opencode / Claude Code / salient windows) so you can see what other agents are asking the oracles. Each entry shows session key, agent_id, latest question, oracle, status, heartbeat age, and turn count. Defaults: THIS project only, and active_only: true (hide sessions with no heartbeat in ~5 min — the stale threshold). Pass active_only: false for retained history, all_projects: true for the whole machine. Use it to avoid duplicate work or watch the live fleet. Read-only, makes no model call. Visibility-only — never affects oracle answers; oracles only see what a calling agent explicitly passes in question/context. |
| session_peekA | COORDINATION — read the full turn history (every question and answer, in order) for one session, across instances. Use it to understand what an agent has learned in a session before joining the work, or to recover a finding another instance produced. Optionally scope to one agent_id. Returns the complete conversation bounded by retention. Read-only, makes no model call. Like session_list, this is visibility-only — it never feeds back into an oracle's context. |
| session_statsA | COORDINATION — aggregated oracle usage across ALL instances on this machine (unlike stats, which only sees the current instance's audit log). Turn counts (by status/oracle/agent) default to the last 24h (window_s: 86400); pass window_s: 0 for all retained history. Also returns fresh_sessions (heartbeat within the stale window) vs total_sessions, plus attributed_turns / unknown_turns. Defaults to this project; all_projects: true for the whole machine. Use it to answer 'which agents are burning the most oracle calls?' or 'how is the fleet doing today?'. Read-only, makes no model call. |