models.md

Models and tools

← Docs · 中文

Connecting models

With Anthropic, the page and the bridge still speak OpenAI's format internally; only the outermost layer is swapped. Requests become Messages API requests (system split out, tool results merged into user, tool definitions converted to input_schema, thinking levels converted to a thinking budget on older models and to adaptive plus effort from 4.6 on, and no temperature when thinking is on), and the event stream is converted back into OpenAI-style chunks. Thinking blocks are sent back to the next round with their signatures, as Anthropic requires for rounds with tool calls. Newer signatures cover the entire preceding context, so if an earlier exchange is changed within an answer — an old screenshot replaced by a line of text, early rounds condensed into notes — the thinking blocks after the change are no longer sent back, to avoid rejection. Image and PDF originals are sent as is; other files leave only a one-line note.

ChatGPT subscription (choose ChatGPT subscription as the API) uses the "Sign in with ChatGPT" flow that OpenAI offers open-source and local apps. Click Sign in on the card: the bridge opens a temporary callback port on 127.0.0.1 and opens OpenAI's authorization page in your system browser; approve with your ChatGPT account and return to Yan. (On first registration OpenAI issues a client_id for this machine, reused for later sign-ins; in ChatGPT's settings you can see Yan, check usage and set a weekly cap for it.) Credentials stay in the bridge, stored in ChatGPT 登录.json under the storage root, never in the page or in backups. Access tokens last an hour; near expiry the bridge exchanges the refresh token for a new one, and clears it only if the exchange is refused (sign-in expired), asking you to sign in again. Sign out revokes the refresh token with OpenAI. Requests go straight to the public Responses API (api.openai.com/v1/responses) with Yan's own prompts and tools, not through the Codex layer; the bridge converts requests into Responses requests and the event stream back into OpenAI-style chunks. No Base URL or API key is needed; the model list is the models this account can use, and each model's thinking levels come with the list (no probing request needed). For rounds with tool calls, the encrypted thinking is sent back with the next round; each chat carries a fixed cache key so earlier messages hit the cache. Temperature and output limits aren't accepted, and usage counts against the subscription. Rejections such as quota exhausted or plan not supported are turned into readable explanations. The old "Codex subscription" (borrowing the Codex CLI sign-in) has been removed; saved models of that kind switch to ChatGPT subscription automatically — just sign in once.

SiliconFlow (the first API option, SiliconFlow; for illustrated steps see Using SiliconFlow in Yan) is an OpenAI-compatible API, listed separately only to fill in the address (https://api.siliconflow.cn/v1; for the international site change it to .com). Switching away clears the address too. Fetch list only fetches chat models (with sub_type=chat; image, embedding and speech models aren't listed). Thinking levels: DeepSeek-V4 and GLM-5.2 accept reasoning_effort with only two levels, high and max; other models (Qwen3 and the like) are converted to enable_thinking and thinking_budget (capped at 32768). Models saved earlier as OpenAI compatible with a SiliconFlow address are recognized by the bridge by address all the same.

• Temperature left blank isn't sent and the API decides (some APIs accept only the default and error if it's sent); it's sent only when filled in. max_tokens exists only for Anthropic (required by the Messages API, default 32000); OpenAI-compatible APIs don't get the field and the server applies the model's limit, so a small number typed by hand never cuts long answers short. The token limit is optional and accepts k (thousand), m (million), e (hundred million): blank means unlimited, and the top right shows tokens used instead; if set, Tokens left decreases with usage, and when exhausted that chat pauses — switch models or raise the limit to continue in place. Usage is settled when each answer finishes, and is still recorded on stop, network loss or a tool chain failing midway (rounds where the API gave no usage are estimated). When an answer starts, it reserves "prompt + maximum output" first, so when several chats start at once, later ones see what earlier ones have reserved rather than all assuming the same amount is left and overspending together.
• Click the ink stroke at the top right to open the Models tab; the usage card sits at the top: one year per page, one ink dot per day, in five shades (the dot grows with them) graded against the days with usage that year. Today is ringed in vermilion; hover a dot to see that day's replies, subagents, side threads, review and images (titles and context condensing count as replies; images are counted by number). The row below is both the year's totals per kind and a filter — click a kind to see only it. Years are listed for switching only once there are earlier records. Numbers live in 用量.json under the storage root: the page reports each spend by local date and kind, and the bridge adds it up (several open pages need no merging). The ink left on each model is tracked separately as before. Older versions kept no such record, so counting starts the day you upgrade
• The model picker is next to the send button, with thinking effort at the bottom of the menu (Default / Low / Medium / High / Max; there's no "off" — choose Low to make it think less). Each model remembers its chosen level, restored when you switch back to that model and used by new chats. OpenAI-style APIs send reasoning_effort; DashScope compatible mode and SiliconFlow's Qwen and the like send enable_thinking and thinking_budget; Default sends no field. Providers accept different levels (some only low / medium / xhigh, some add minimal or max, some don't accept the field at all). When a model is chosen (in the menu, in settings or by typing its ID, on Fetch list, on Test connection), Yan probes it: it deliberately sends a level that doesn't exist, and if the API errors in OpenAI's style, the levels listed in the error are recorded on the model; if it says it doesn't recognize reasoning_effort, the model is recorded as not supporting it (the menu shows only Default and sends no field); relays that accept anything get the four common levels. Each model is probed once, again after switching models; authentication and network errors don't count as a probe. The result fills Thinking levels in the model's advanced settings and can be edited (hand edits are final — Test connection won't re-probe; they're discarded only when the model changes). The probe is for the model's current identity; previously recorded levels are never carried over. The menu lists only the levels this model accepts, and a level it doesn't accept falls to the nearest one (choosing Max when it only goes to high uses high); the label next to the send button shows the level actually sent. If a model wasn't probed and the API rejects a level, Yan still records the levels from the error and resends with the nearest one
• Tool arguments are parsed as JSON and rescued even when the model writes them sloppily: wrapped in a code fence, a trailing comma, cut off by max_tokens, the argument object encoded again as a string — all are repaired before parsing. Only if it truly can't be parsed does the call fail, and the message back to the model includes the exact error position, the arguments this tool expects and the raw text received, so it can fix it in one go
• Tool calls (function calling; can be turned off in the model's advanced settings): search_web searches without a key (the bridge queries Bing directly, at most three at once, staggered; Bing sometimes treats direct requests as a script and matches only the first word, so when the later words don't match any results, it searches again with a headless browser, with DuckDuckGo as the last resort; if no provider matches, the results are given anyway and marked as possibly unreliable); fetch_page reads web page and PDF text (24,000 characters per chunk, longer texts continue with offset; PDFs are extracted on the page side, the same as attachments; pages that refuse direct requests or need scripts to show content are opened in a headless browser); http_request sends requests to public APIs (GET / POST / PUT / PATCH / DELETE / HEAD, with headers and body, returning status, headers and body; text truncated at 60,000 characters, binary reported only by type and size; local 127.0.0.1 / localhost is allowed — the model must be able to test services it started itself — while LAN and other private addresses are still refused, and like the agent API it only accepts requests from this site's pages; not given to side threads); read_document reads documents in chat attachments and Files by page number or keyword; run_js evaluates JavaScript in an isolated sandbox (arithmetic and statistics, dates, regex, JSON transforms — anything easy to get wrong by mental arithmetic; the sandbox is a Worker inside preview.html's iframe with a null origin and a CSP that forbids network access, with fetch / importScripts / indexedDB removed, leaving only standard JS; a single expression is evaluated directly, a statement block returns its value with return, and console.log output comes back too; on timeout the whole Worker is killed; it doesn't go through the bridge); download_file saves a file from the web into the working folder or Files (local allowed, private refused, as above; up to 64 MB; without a path it uses the file name from the URL, adding (2) for duplicates; counted in the answer's change summary). In Agent mode there are also update_plan (for tasks with more than a few steps, a plan shown to the user, drawn in Steps as a checklist card: ○ to do, ▶ in progress, ✓ done, – skipped; the full list is given each time, and the next question's step summary carries it) and update_intent (Intent: a conclusion graph for long jobs spanning many answers, stored in the folder as .yan/意.json and carried across chats; see Chat and Agent). All are collected in the Steps fold, each step shown as a spinner / ✓ / × for running, success and failure. Duplicate calls in the same round reuse existing results (only successful ones); adjacent read-only calls in the same round (reading files, searching, reading web pages, recalling memory) run in parallel, with results returned in the original order; executing, writing, editing and requests go one at a time
• After a web-backed answer, a deduplicated Sources card is built from successful search and page-reading steps, with sources read in full marked separately
• ask_user: when the next step depends on the user's choice, the model can pop up a small form (at most 8 questions, usually 1–3, one per page with back and forth; each with 2–4 options, multiple choice or your own answer; for single-choice questions, picking an option and writing your own are mutually exclusive) that floats above the input box. Available in both modes; the answers are carried into later rounds through the Steps summary
• All built-in prompts (the general system prompt, the agent's way of working, the side-thread focus line, each tool's description) are in the prompts/ folder and take effect on reload; support.js only concatenates