yetone

Magpie vs CC Switch: choose who owns your agent's upstream The engineering result to aim for is an explainable request path: which model answered, which credentials it used, what happens on failure, and how to restore direct access. Start with Magpie for shared cross-agent routing, CC Switch for a desktop configuration workspace, Claude Code Router for explicit request policies, or CLIProxyAPI for an account-backed compatible proxy. These are editorial shortlists based on documented emphasis, not measured performance or security rankings. Their capabilities overlap. AIHubMix prepared this comparison from official documentation checked on November 3, 2026. No hands-on benchmark, reliability test or security audit was performed. Claude Code Router's README lists AIHubMix among its sponsors; that relationship is disclosed, not used as technical evidence. Define the boundary before choosing the manager Claude Code, Codex and Gemini CLI own the agent environment: tools, approvals and the conversation loop. A model generates responses; a provider supplies model access. Replacing the upstream does not replace the agent or its permissions. Separate five operations: - Configuration switching: change an endpoint, key or model. - Routing: put a gateway between agent and upstream, possibly translating formats. - Aggregation: combine model choices; this does not inherently add fallback. - Account pooling: distribute requests among credentials. Round robin is not guaranteed recovery. - Fallback: try another configured destination after a qualifying failure. Protocol names are another boundary. OpenAI Chat Completions and Responses are different APIs; Anthropic Messages and Gemini have their own structures. Documented conversion does not establish lossless tool, reasoning, image or streaming behavior. Likewise, accepting a compatible base URL is not the same as native configuration integration. Feature coverage differs by client, provider and release. Choose the ownership you need, then validate that exact combination. Choose a starting point Use the shortlist to decide what to validate, not to infer exclusive capabilities. | Tool | Start here for | Check first | | --- | --- | --- | | Magpie | Shared gateway | Alternative targets | | CC Switch | Desktop workspace | Aggregation ≠ failover | | CCR | Routing rules | Each policy branch | | CLIProxyAPI | Account-backed proxy | Separate UI and stats | CCR means Claude Code Router. Magpie needs another usable destination for fallback; CC Switch's aggregation has no failover; CCR rules need validation; CLIProxyAPI's desktop companion and statistics are separate components. This is not a measured ranking, and coverage differs by agent and provider. Magpie: own a shared gateway across agents Magpie combines native configuration management with a local gateway. Documented integrations include Claude Code, Codex, Gemini CLI, OpenCode, Cline and Cursor CLI. Other compatible clients can use its endpoint without necessarily having a native integration. The gateway translates OpenAI Chat, OpenAI Responses, Anthropic Messages and Gemini formats. Providers include API-key services, compatible custom endpoints, local servers and supported subscription accounts. Profiles group several agents' configurations. Routing groups expose multiple models or providers as one selection. Documented policies include order for ordered recovery, rotate for changing members each turn, usage for the least-used member, smart for eligible subscriptions resetting soonest, and pace for remaining weekly capacity relative to reset time. Groups can nest. Conversation stickiness aims to preserve a useful prompt cache; it does not prove cache continuity across arbitrary provider changes. Optional intent routing asks a selected model to read new turns, without an established guarantee of savings. Fallback also needs somewhere to go: one account without a routing group leaves errors to reach the agent. Magpie's Library manages instructions, MCP servers, skills and subagents, alongside documented usage, quota, cost and session views. It is not only a router. Decide privacy settings separately Masking is off by default. When enabled, it substitutes detected sensitive values locally and restores them in replies, including tool arguments. Detection can miss or misclassify values; the model cannot inspect a masked original. If enabled masking cannot run, the README describes withholding the request with HTTP 503. The privacy documentation also covers account discovery: Magpie can read existing agent sign-ins, and discovery can be disabled. Release builds describe daily telemetry with a random identifier, version, system and product-use identifiers. Privacy settings or DO_NOT_TRACK=1 disable that telemetry, but partner-link clicks and partner-list fetches are counted independently. The README says those counts retain no identifier or address. A local gateway does not mean no other network activity. CC Switch: own the desktop workspace, with routing available CC Switch combines provider management with MCP, skills, prompts, projects, sessions, usage tracking, backups and synchronization. Listed clients include Claude Code, Claude Desktop, Codex, Gemini CLI and OpenCode; features differ by client. Its three modes have different contracts: - Direct: connect the agent to the chosen provider. The project says switching preserves unrelated hooks, plugins, MCP settings and comments. - Routing: forward locally, convert Anthropic Messages, OpenAI Chat Completions, OpenAI Responses and Gemini Native, and use per-tool failover queues, circuit breaking and provider-health monitoring. - Aggregation: expose multiple providers' models in Claude Code or Codex. Requests follow the chosen model's provider. Aggregation does not provide failover. Aggregation excludes Claude official subscriptions. Official-login providers generally cannot enter Routing, except for the documented Codex OpenAI Official case. Consult the user manual for the exact client/mode matrix. Restart requirements matter. Claude Code supports documented hot switching; Direct changes for Codex, Gemini CLI and Grok Build generally require restarting. Routing may still need a restart when the model changes. Codex aggregation-list changes require restarting the relevant daemon, application or editor environment. The provider-card connectivity check tests reachability, not API-key or model validity. Also, WebDAV/S3-compatible sync is not a complete recovery copy: some device settings, state and original-configuration backups remain local. Data defaults to ~/.cc-switch, with SQLite and associated files. Claude Code Router: own conditions, credential pools and route inspection Claude Code Router, or CCR, describes a multi-agent gateway and control plane, not just a Claude Code wrapper. Its README also lists Codex, OpenCode, Pi, Kimi CLI and Grok CLI. Its emphasis is explicit policy: header/body conditions, prefixes, request rewriting, retries and ordered fallback models. Credential pools and key rotation sit beside agent profiles, model overrides and environment settings. CCR documents request/response details, resolved provider/model/credential, status, latency, tokens, estimated cost, tool calls and traces. This makes routes inspectable; it does not establish improved task quality, and estimated cost is not an invoice. Deployment options include desktop applications, an npm CLI with browser management UI, and Docker. The npm CLI requires Node.js 22 or newer. The provider guide covers protocols, custom endpoints and credential pools, and warns that connectivity tests send upstream requests: they can consume paid usage or request limits. Shortlist CCR when a route must be explainable from rules and logs. More policy branches also mean more combinations to validate. CLIProxyAPI: own the account-backed endpoint CLIProxyAPI exposes OpenAI-compatible interfaces including Responses, Gemini-compatible interfaces including Interactions, and Claude-compatible interfaces for clients and SDKs. Its README documents Codex and Claude Code OAuth, Gemini account access, round-robin multi-account balancing for several providers, configured OpenAI-compatible upstreams and a reusable Go SDK. Endpoint compatibility does not establish that the core project natively rewrites every agent's profiles. Count the surrounding components separately. The README recommends EasyCLIProxyAPI for graphical configuration, updates, tray controls and service start/stop. Since v6.10.0, CLIProxyAPI and CPAMC no longer ship built-in usage statistics; separate statistics and management projects are referenced instead. Do not conclude that CLIProxyAPI has no retries, fallback or recovery controls: inspect the selected release's configuration. Conversely, round-robin distribution alone is not a guaranteed cross-model fallback policy. Proposed acceptance workflow, not a reported test Use the following before connecting a real project. This is a reader exercise, not a test performed for this article. 1. Capture the baseline. Use a disposable repository and low-privilege test credentials. Back up the original agent configuration and choose one manager to own it. 2. Validate one route. Connect one agent to one provider. Check a plain response and the actual resolved provider/model, not just a connectivity indicator. 3. Validate agent behavior. Ask it to read a harmless file and propose a small change. Verify a complete tool-call/result cycle and streaming completion before permitting writes. 4. Exercise recovery only if needed. Add another route, then use a safe local mock or authorized test setup to check the intended failure condition and alternate destination. Do not deliberately exhaust paid quotas. 5. Check side effects. Confirm retries or recovery do not repeat side-effectful tool actions in your workflow. This is an acceptance criterion, not an observed product defect. 6. Rehearse removal. Stop the manager and verify the documented restore or return-to-direct procedure. Apply restart requirements and reconcile usage estimates with provider records. Pitfalls outside the model picker A working login is not permission. OAuth support does not establish provider approval for every cross-client use. CC Switch explicitly warns about subscriptions outside official clients. Check provider terms and organizational rules; a manager adds no entitlement and removes no limits. Local is still a trust boundary. Review credential permissions, account discovery, backup/sync scope and request-log contents before importing production credentials. Encryption at rest was not verified here. Remote access needs its own authentication and exposure review. Several configuration owners complicate rollback. Avoid several managers automatically rewriting the same settings. This is an operational precaution, not a demonstrated product bug. Choose the simplest arrangement that passes acceptance. One agent on its official provider may need no gateway at all. The useful outcome is an explainable, reversible setup—not a winner inferred from feature counts. Sources Official sources checked on November 3, 2026: 1. Magpie README — integrations, routing groups, Library and privacy behavior. 2. CC Switch README — modes, client coverage, restarts and storage. 3. Claude Code Router README — agents, rules, credentials and deployment. 4. CLIProxyAPI README — interfaces, accounts, companion software and statistics boundary. 5. CCR provider guide — protocols, pools and test-request costs.

Alma 的 Relay Server 开源了 🎉 用自己的中继服务器远程控制电脑上的 Alma： · Cloudflare Workers 一键部署，免费套餐就够 · 或 Docker 一条命令，自动 HTTPS · 端到端加密，中继只看得到密文 设置 → 远程访问 → 使用自建中继，填入地址即可。 yetone/alma-relay

🐦 Run Claude Code on Kimi or Codex on DeepSeek, all switched from your menu bar with automatic quota failover. 🔗 yetone/magpie Credits: yetone/magpie #magpie #golang #opensource

越用越觉得， Magpie 是如此得优雅和优美。 还记得当年因为 alma， openai xai 在推上主动对 作者 @yetone 发工作邀请。 yetone/magpie

小白用 AI 的隐私安全全靠这两位大佬守护，我说的。 Magpie yetone/magpie AstrLink Calcium-Ion/AstrLink t.co

#ai工具十月第三周 Github 开源热榜：模型网关、AI 艺术创作工作台、跨工具记忆 #github #agent #ai工具 1｜magpie：一个本地模型网关，把你所有编程助手的模型和订阅收到一处。菜单栏点一下就换模型，Claude Code、Codex、Gemini CLI、OpenCode 都能共用同一批 key 和订阅；按 smart、order、rotate、usage、pace 等策略在成员间分发请求，某个配额用完会自动换下一个。README 还提到能从 CC Switch 导入已有供应商配置。链接：yetone/magpie 2｜ArtCraft：艺术家的 AI 创作 IDE。先在二维画布合成、再到三维里摆好场景道具和相机，然后才交给模型生成，做可控可复现的图片和视频；内置 62 个模型目录，覆盖图像、视频、音乐音效和三维，像 Nano Banana、FLUX、可灵、Veo 都在里面。链接：storytold/artcraft 3｜ai-memory：给编程助手的跨工具长期记忆。在 Claude Code 干到一半退出，去 Codex 的同一个目录接着干，不用重讲架构和试过的失败路；记忆就是一堆 git 管的 markdown 文件，能直接 grep、用 Obsidian 打开，数据库只是能随时重建的索引，默认全程零大模型调用。链接：akitaonrails/ai-memory 4｜Filee：拖拽式离线文件转换器。按住键拖动文件，光标处弹出一个甜甜圈选目标格式，只显示能转的格式，支持 255 种格式、离线转换、结果存原文件旁边；多步转换路线会自己找出来，从 Releases 下载即用，Windows、macOS、Linux 都有。链接：KnifeLemon/Filee 5｜Strata：在自己的游戏 PC 上跑大模型。按项目自述可在普通游戏显卡上跑一个大参数模型，兼容 OpenAI 和 Anthropic 接口，能接别的应用，聊天和文件都留在本机；三种装法：下载桌面应用、一行命令，或者让 AI 助手照仓库说明自己装。链接：Niko1221/Strata 十月第三周 Github 开源热榜 Top 5，覆盖模型网关、艺术创作、跨工具记忆、文件转换和本地大模型，Oraink 替你捞重点。 章节： 00:00 开场 · 本周 Top5 00:07 1｜magpie 00:43 2｜ArtCraft 01:11 3｜ai-memory 01:45 4｜Filee 02:16 5｜Strata 02:48 结尾 · 关注 Oraink

Top 10 AI GitHub Repos Blowing Up Right Now (Oct 24) Today's fastest-rising AI repositories on GitHub, ranked by real momentum from the last 24-48 hours rather than all-time size. Every repository was checked against the GitHub API on 24 October 2026, and the list is dominated by agent infrastructure: orchestration runtimes, control planes, memory layers, security skills and fast decision engines. Ranked list (the video counts down 10 → 1): 1. openclaw/openclaw — openclaw/openclaw 2. obra/superpowers — obra/superpowers 3. mattpocock/skills — mattpocock/skills 4. affaan-m/ECC — affaan-m/ECC 5. thedotmack/claude-mem — thedotmack/claude-mem 6. Panniantong/Agent-Reach — Panniantong/Agent-Reach 7. calesthio/OpenMontage — calesthio/OpenMontage 8. ayghri/i-have-adhd — ayghri/i-have-adhd 9. browser-use/jev-ultrafast — browser-use/jev-ultrafast 10. yetone/magpie — yetone/magpie Disclaimer: rankings are based on GitHub trending and star-velocity snapshots for 24 October 2026 and change daily. Star counts are approximate and move fast — they were read from the GitHub API on the day of recording. Licences are mentioned only where a repository clearly states one. CHAPTERS 0:00 Hook 0:15 Intro 0:32 #10 yetone/magpie 0:59 #9 browser-use/jev-ultrafast 1:30 #8 ayghri/i-have-adhd 2:00 #7 calesthio/OpenMontage 2:31 #6 Panniantong/Agent-Reach 3:04 #5 thedotmack/claude-mem 3:38 #4 affaan-m/ECC 4:14 #3 mattpocock/skills 4:47 #2 obra/superpowers 5:16 #1 openclaw/openclaw 5:56 Pattern of the day 6:20 CTA + outro New AI GitHub Top 10 every day — subscribe for tomorrow's list. #GitHub #AI #Agents #OpenSource #LLM #MachineLearning --- More AI content --- ⚡ AI in 60 Seconds: youtube.com 🤖 Hermes Agent News: youtube.com 🔬 Top 10 HF Models: youtube.com 💬 Join our Discord community: discord.gg

Keep Dynamic Icon Groups from Breaking Your List Layout --- title: "Keep Dynamic Icon Groups from Breaking Your List Layout" published: true tags: react, css, webdev, frontend --- A list looks tidy when every row starts with one icon. Then one item gets three icons, another gets five, and the labels stop lining up. The tempting fix is to adjust the gap. That works for one row and breaks another. The gap was consistent already; the space before it was changing. Give every row the same leading slot, then put a limit on what can occupy it. In this React example, that means a shared CSS Grid column, a bounded icon stack, and an explicit rule for overflow. !Animated illustration of icon group alignment before and after using a fixed-width slot Why the labels drift Suppose a row contains an icon group followed by its label: <li className="source-row"> <IconGroup members={item.members} /> <div className="row-content">{item.label}</div> </li> With a content-sized group in a flex row, the label follows the group's width. One badge takes less space than three overlapping badges. Even with identical icon sizes and gaps, the labels start at different positions. That is reasonable flex behavior. It becomes a problem when the design expects a common label column across independent rows. A concrete instance appears in Magpie issue #2498: model rows have a single provider icon, while routing groups have stacked icons. The issue describes reserving a common leading width. This tutorial uses that reported problem as a starting point, with an independent teaching implementation. Define the stack policy before choosing the width A fixed column alone does not stop its children from overflowing. Decide how many positions the component can display first. For this example: | Number of sources | Visible content | | --- | --- | | 0 | Empty slot, with the label still aligned | | 1–3 | All source icons | | 4 or more | First two icons and a counter for the remaining sources | Five sources therefore render as two icons and +3. The counter occupies the third position; it is not appended as a fourth item. Use 28px badges, with each overlapping badge starting 16px after the previous one. Three positions occupy: 28 + (3 - 1) × 16 = 60px A 64px slot leaves 4px of spare space. With a 16px root font size, those dimensions are 1.75rem, 1rem, and 4rem. Choose a width from the actual badge geometry and overflow policy. A 3rem slot, for example, would be too small for this particular stack. Build the React component The example uses three Tabler SVGs retrieved through the SVGicons catalogue: - Folder - Bell - File Settings They are by Paweł Kuna and distributed under the MIT licence. Keep the copyright and licence notice with redistributed assets. Save them in your application's public directory so they are available at /icons/folder.svg, /icons/bell.svg, and /icons/file-settings.svg. The layout does not require a particular icon library. Using local image files keeps SVG markup out of the component's layout logic. function IconGroup({ members }) { const visible = members.length > 3 ? members.slice(0, 2) : members; const hidden = members.length - visible.length; return ( <span className="icon-slot" aria-hidden="true"> <span className="icon-stack"> {visible.map((member, index) => ( <span className="badge" key={member.id} style={{ '--index': index }} > <img src={member.src} alt="" width="18" height="18" /> </span> ))} {hidden > 0 && ( <span className="badge count" style={{ '--index': 2 }}> {hidden > 99 ? '99+' : `+${hidden}`} </span> )} </span> </span> ); } function SourceList({ items }) { return ( <ul className="source-list"> {items.map((item) => ( <li className="source-row" key={item.id}> <IconGroup members={item.members} /> <div className="row-content"> <span className="row-label">{item.label}</span> <span className="sr-only"> {item.members.length ? `. Sources: ${item.members.map((m) => m.name).join(', ')}` : '. No connected sources'} </span> </div> </li> ))} </ul> ); } Each member needs a stable, unique id, a readable name, and a trusted local src. For example: const files = { id: 'files', name: 'Files', src: '/icons/folder.svg', }; const alerts = { id: 'alerts', name: 'Alerts', src: '/icons/bell.svg', }; const config = { id: 'config', name: 'Configuration', src: '/icons/file-settings.svg', }; const archive = { id: 'archive', name: 'Archive', src: '/icons/folder.svg', }; const monitoring = { id: 'monitoring', name: 'Monitoring', src: '/icons/bell.svg', }; const items = [ { id: 'documents', label: 'Documents', members: [files], }, { id: 'activity', label: 'Project activity', members: [files, alerts], }, { id: 'overview', label: 'Workspace overview', members: [files, alerts, config], }, { id: 'operations', label: 'Operations across all connected workspaces', members: [files, alerts, config, archive, monitoring], }, { id: 'empty', label: 'No connected sources yet', members: [], }, ]; export default function App() { return <SourceList items={items} />; } The source names are exposed once as text. The overlapping images and counter are hidden from assistive technology, avoiding a second announcement of the same source information. This approach suits a static list. If users need to inspect or select individual sources, provide a visible details view with equivalent keyboard access. A tiny overlapped badge should not be the only way to reach an action. Localize the source sentence and counter formatting for your product. Reserve the column and contain the stack Apply these styles: * { box-sizing: border-box; } .source-list { --badge-size: 1.75rem; --stack-step: 1rem; --icon-slot: 4rem; list-style: none; margin: 0; padding: 0; } .source-row { display: grid; grid-template-columns: var(--icon-slot) minmax(0, 1fr); column-gap: .75rem; align-items: start; padding-block: 1rem; border-block-start: 1px solid #e3e8f1; } .icon-slot { min-inline-size: 0; inline-size: var(--icon-slot); } .icon-stack { display: block; position: relative; block-size: var(--badge-size); } .badge { position: absolute; inset-inline-start: calc(var(--index) * var(--stack-step)); inset-block-start: 0; inline-size: var(--badge-size); block-size: var(--badge-size); display: grid; place-items: center; background: #dce8ff; border: 2px solid white; border-radius: 50%; } .badge:nth-child(2) { background: #dcf5ec; } .badge:nth-child(3) { background: #efe3ff; } .badge img { display: block; inline-size: 1.125rem; block-size: 1.125rem; } .count { font-size: .625rem; font-weight: 800; color: #17233b; } .row-content { min-inline-size: 0; } .row-label { display: block; overflow-wrap: anywhere; } .sr-only { position: absolute; inline-size: 1px; block-size: 1px; padding: 0; margin: -1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap; border: 0; } There are two separate constraints here: - The shared --icon-slot keeps the label position consistent across rows. - The component's three-position limit keeps the stack within that slot. An empty group keeps its wrapper, so zero icons does not become another alignment exception. The absolutely positioned badges need an explicit stack height because they do not contribute to their parent's normal flow height. Later badges paint over earlier ones in this simple stack. The label track uses minmax(0, 1fr) so its minimum track size does not default to a content-based minimum. min-inline-size: 0 lets the content wrapper shrink, while overflow-wrap: anywhere allows long unbroken identifiers to wrap. These choices address different parts of overflow handling. Replacing the icon column alone will not fix every long-text case. See MDN's references for grid track sizing and minimum widths. If labels must stay on one line, use a deliberate truncation design instead. Make the full text available through an accessible details interaction; do not rely only on a mouse tooltip. Keep the same rule on narrow screens and in RTL As the container narrows, the fixed slot stays put and the text wraps in the remaining track. Top alignment keeps a multi-line label beside the top of its icon stack. If a compact design needs a smaller slot, change its geometry for the entire list. For example, 24px badges with a 12px step occupy 48px across three positions: .source-list.compact { --badge-size: 1.5rem; --stack-step: .75rem; --icon-slot: 3rem; } Never make this choice independently for each row, or the common column disappears again. Check that the counter remains readable in the smaller badges. For right-to-left layout, place dir="rtl" on the list or an ancestor. Grid's inline direction places the leading column on the right. inset-inline-start moves the badge stack from that same side. <div dir="rtl"> <SourceList items={items} /> </div> Use real translated labels when reviewing the result. Changing direction on English text checks the layout rule, but does not verify Arabic or Hebrew typography, punctuation, or mixed-direction identifiers. Test the relationship that matters A screenshot can catch an obvious regression. A geometry assertion can also express the actual requirement: every label container has the same leading edge. Here is a Playwright test for a page containing one .source-list. Serve the component on the / route and configure Playwright's baseURL to point to your development server. import { test, expect } from '@playwright/test'; for (const width of [420, 1100]) { for (const direction of ['ltr', 'rtl']) { test(`label alignment: ${width}px ${direction}`, async ({ page }) => { await page.setViewportSize({ width, height: 1000, }); await page.goto('/'); await page.locator('.source-list').evaluate((list, dir) => { list.dir = dir; }, direction); const edges = await page.locator('.row-content').evaluateAll( (nodes, dir) => nodes.map((node) => { const rect = node.getBoundingClientRect(); return dir === 'rtl' ? rect.right : rect.left; }), direction ); expect(edges.length).toBeGreaterThan(1); expect( Math.max(...edges) - Math.min(...edges) ).toBeLessThan(1); }); } } Also check that every badge stays within its slot, images have loaded, and the document has no horizontal overflow. A component can keep its labels aligned while its icons still collide with them. Use fixtures with: - Zero, one, two, three and five sources. - A very large source count. - A multi-line label. - A long unbroken identifier. - Larger text. - Both LTR and RTL directions. Check keyboard navigation if the rows contain links or buttons. Keep screenshot baselines only after reviewing the initial renders, and rerun the checks in your supported browser engines. The useful invariant is simple: source count may change the content of the icon slot, but it must not change where the label begins. Once that rule is explicit, new data has much less room to rearrange the list.

Runner 0.17.0 发布：支持 Claude Code 多账号切换 之前在 V 站介绍过 Runner ，是一个管理 CLI agent 的原生桌面工具，本质是一个类似 terminal multiplexer 的工具，可以在同一个 app 中管理不同平台的 agent cli ，也可以把几个 agent 组成 crew 一起协作沟通。 之前的帖子：[我的第一个 300 stars 开源项目 Runner]( v2ex.com) 这次做 claude 多账号切换的初衷主要是我自己用了两年的 Claude 账号最近被封了，用的是 Max 订阅。并且想要再搞出一个新的 max 账号现在太难了，有 [KYC]( support.claude.com)，加上越来越严格的检查，感觉普通国内用户想稳定用一个 Max 账号的成本已经显著增加了。 从我自己最近的使用情况来看，Pro 账号的检查相对没那么严格，用多个 Pro 的重度用户也多了起来。这样就需要管理几个账号、看各自的用量，也希望换个账号以后还能接着之前的工作继续做。 所以这次 0.17.0 给 Runner 加了 Claude Code 多账号支持，可以在里面分别登录、查看用量，切换账号以后继续之前的对话。这里单独开一帖，配几张图介绍一下。  添加另一个账号  在 Settings → Agents → Claude Code 的 Accounts 里面，可以看到自己原来用的账号，默认叫 Personal 。点 Add account ，给新账号起个名字，再跟着 Claude Code 的浏览器登录流程走一遍就可以了。如果之前已经用独立目录登录过，也可以直接选择那个目录。 添加以后，两个账号的登录会分别保留，平时切换不用再来回退出和登录。  原来的配置可以继续用 我自己用 Claude Code 会配一些 skills 、MCP 和插件，换个账号以后如果这些都要重新弄一遍，还是挺麻烦的。所以添加账号时，可以勾选 Use Personal’s settings ，继续用主账号的全局 CLAUDE.md 、skills 、MCP 和已启用的插件。 这里主账号和当前使用的账号是分开的：主账号提供共享配置，Active 决定接下来用哪个账号启动会话。比如配置一直用 Personal 的，干活时可以切到 Work 。 新账号已有的本地配置和同名 skill 会保留，登录信息也是各自独立的。 换个账号，继续之前的对话 在用量下拉框里选好账号以后，新开的 chat 和新启动的 Claude Code crew 成员就会使用它。已经在跑的会话会继续使用原来的账号。 已有的 chat 如果也想换账号，可以先 Stop ，选好另一个账号，再点 Resume 。Runner 会接着原来的对话继续，不用重新开一个 chat ，再把项目和做到哪一步介绍一遍。 这一版先做了手动切换，不会在额度用完时自动轮换账号。多账号功能目前也只针对 Claude Code 。 账号切换实现对比 做这个功能的时候，也看了社区里一些工具的实现。大致可以分成两类： 1. 通过反代或者 agent gateway 。 客户端先把请求交给一个中间服务，由它选择账号、转发请求，有的还会做协议转换。具体实现也有区别，比如 [Magpie 的 Claude gateway]( github.com/yetone/magpie/blob/main/docs/subsystem…)，是由 gateway 调用真实的 Claude Code ，再由 Claude Code 向 Anthropic 发起请求。 2. 原生 CLI 直连，在本机切换账号。 不额外加模型请求代理，还是由 Claude Code 自己发请求。这里又可以分成替换登录凭据和切换账号目录两种做法，所以 direct mode 不一定就是切目录。 [Anthropic 官方文档里的多账号用法]( code.claude.com)是给每个账号一个独立的配置目录，用 CLAUDE_CONFIG_DIR 来选择。例如个人账号继续直接运行 claude，工作账号用 CLAUDE_CONFIG_DIR=~/.claude-work claude，各自在自己的目录下登录。 对 Runner 来说，我觉得沿用这个官方提供的机制是最稳妥的选择。Runner 本来就在管理本机的 CLI 进程，经常会有几个 agent 同时跑。每个账号保留自己的登录状态和凭据存储，登录、保存凭据和 token 刷新都交给 Claude Code ，Runner 负责启动时选好目录。从登录状态的稳定性和账号凭据管理上，这样我会更放心一些。 Runner 具体怎么做 - 登录和凭据： 添加账号时，在对应目录下运行 claude auth login，走 Claude Code 自己的浏览器登录流程。macOS 上凭据由 Claude Code 放进对应的 Keychain 项，Windows 上放在对应目录的凭据文件里。Runner 保存账号名字、目录等信息，不另外保存一份供切换用的凭据；查看用量时会读取本机凭据，查询对应账号的用量。 - 启动和切换： 原来的账号保持原来的启动方式，额外账号通过 CLAUDE_CONFIG_DIR 指定目录。切换 Active 账号，只影响接下来新开或恢复的会话，已经在跑的 agent 继续用自己的账号。在 Runner 外面直接打开的 Claude Code 也继续使用原来的默认登录。 - 共享配置： 目录分开以后，skills 、MCP 和插件这些也需要处理。Runner 按需链接主账号的 CLAUDE.md 、skills 等内容，settings 、MCP 和插件通过启动参数带入，保留各账号已有的本地文件和插件状态。所以账号可以分别登录，常用配置仍然可以共用。 - 继续原来的对话： Runner 会记住对话文件最初在哪个目录。换账号恢复时，用 claude --resume <原对话文件路径> 接着原来的记录继续，不需要把历史复制到新账号目录，也不用从头开一个 chat 。 和 Magpie direct mode 的区别 [Magpie 的 direct mode]( github.com/yetone/magpie/blob/main/internal/provi…) 会记住多个账号的凭据，切换时先保存当前账号的最新凭据，再把选中账号的凭据写回 Claude Code 原来使用的位置。这样配置和历史可以一直留在同一个目录，切换工具需要处理凭据的保存、替换和刷新后的同步。 Runner 这里切的是启动时使用的目录，每个账号的凭据留在各自的存储里。相应地，Runner 要多处理共享配置和跨目录恢复对话。这是两种实现各自需要处理的事情，也和 Runner 本身就管理会话的功能有关。 另外，Magpie 的 [gateway 内部也会给 Claude 账号使用独立目录]( github.com/yetone/magpie/blob/main/internal/provi…)。所以这个区别具体说的是它切换原生 Claude Code 登录的 direct mode ，独立目录也不是 Runner 特有的做法。 和 CC Switch 的区别 [CC Switch]( github.com/farion1231/cc-switch/blob/main/README.…) 在 Claude Code 这一侧主要是切换 provider 配置。Direct 模式会修改配置里的 endpoint 、key 、模型等字段； Routing 模式则让请求经过它的本地路由，可以做协议转换和故障切换。Claude Official 使用 Claude Code 自己的登录，不经过本地 Routing 。 按它目前的文档，Accounts 里的多订阅账号管理列出的是 ChatGPT 、GitHub Copilot 和 Grok 。它的 Claude provider 切换，和 Runner 这次做的几个 Claude 订阅账号各自登录、切换后继续同一个会话，处理的需求有所不同。 下载和反馈 Repo： yicheng47/runner 官网： runnersh.dev 下载： runnersh.dev 版本说明：[Runner 0.17.0]( github.com/yicheng47/runner/releases/tag/v0.17.0) 支持 macOS （ Apple Silicon ）和 Windows x64 （ Windows 10 1809 及以上）。 有多个 Claude 账号的朋友可以试试看，有问题在楼里反馈，或者到 GitHub 提 issue 都可以。也欢迎分享自己平时是怎么切换账号的，看看还有哪些地方可以做得方便一点。

Top 10 GitHub Repos of October 2026 — #1 Took 67,955 Stars in 19 Days Ten repositories. 311,780 stars. One snapshot, taken on 19 October 2026. Every month GitHub quietly produces a handful of repos that explode — and October 2026 was one of the strangest months yet. A photo editor written from scratch in Rust out-starred everything. The same studio also took the #10 slot, 109 seconds after shipping the repo that won. And an 11-day-old agent skill beat projects that had a three-week head start. This is the full ranking, with the numbers that explain each breakout: stars, forks, star velocity, language share, licence, age — all pulled from the GitHub API at a single moment, so nothing here is a moving target. ━━━━━━━━━━━━━━━━━━━━ CHAPTERS 0:00 Cold open 0:15 How the list was built 0:36 The whole board — positions 1 to 5 0:51 Positions 6 to 10 1:06 #10 — pdfcraft (a PDF editor, pure Rust) 1:32 #9 — anatomy (11 days old, 1,499 stars a day) 1:58 #8 — magpie (Codex on DeepSeek, Claude Code on Kimi) 2:24 #7 — Compositor (the Photoshop alternative for Mac) 2:50 #6 — jev-ultrafast (fastest and cheapest web agent) 3:16 #5 — dsh-our-free-model (frontier models, no login, no key) 3:42 #4 — Strata (frontier weights on consumer hardware) 4:08 #3 — laya (decisions in a single forward pass) 4:34 #2 — HowToLiveBetter (a life manual, not an app) 5:00 #1 — photocraft (67,955 stars in 19 days) 5:26 October at a glance 5:50 That was October ━━━━━━━━━━━━━━━━━━━━ THE METHOD · Window: repositories created between 1 September and 19 October 2026 · Metric: total stars at one snapshot — 19 October 2026, 10:30 UTC · Sample: 616 repositories cleared the 500-star filter; the top 10 are ranked here · Detail: forks, open issues, licence, language bytes and creation dates all come from the same API call · Stars per day = stars ÷ days since creation No growth estimates, no projections, no vibes. One reading of the meter. ━━━━━━━━━━━━━━━━━━━━ THE TOP 10 1. storytold/photocraft — 67,955 stars · Rust · Apache-2.0 2. eternity4719/HowToLiveBetter — 66,148 stars · HTML · CC-BY-4.0 3. NandhaKishorM/laya — 33,470 stars · Python · Apache-2.0 4. Niko1221/Strata — 27,805 stars · C++ · MIT 5. Ebony-Vinyl/dsh-our-free-model — 26,509 stars · JavaScript · MIT 6. browser-use/jev-ultrafast — 23,253 stars · Python · MIT 7. robbietilton/Compositor — 17,434 stars · Swift · MIT 8. yetone/magpie — 16,636 stars · Go · MIT 9. wheresryan22/anatomy — 16,490 stars · JavaScript · MIT 10. storytold/pdfcraft — 16,080 stars · Rust · Apache-2.0 Links: storytold/photocraft eternity4719/HowToLiveBetter NandhaKishorM/laya Niko1221/Strata Ebony-Vinyl/dsh-our-free-model browser-use/jev-ultrafast robbietilton/Compositor yetone/magpie wheresryan22/anatomy storytold/pdfcraft ━━━━━━━━━━━━━━━━━━━━ This is the first of a monthly series — next one lands with November's board. Subscribe if you want the numbers before they become the trend. #GitHub #OpenSource #GitHubTrending