[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-81798":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":22,"hasPages":22,"topics":24,"createdAt":10,"pushedAt":10,"updatedAt":37,"readmeContent":38,"aiSummary":39,"trendingCount":16,"starSnapshotCount":16,"syncStatus":40,"lastSyncTime":41,"discoverSource":42},81798,"sinew","Paseru\u002Fsinew","Paseru","Desktop IDE with built-in AI coding agents","https:\u002F\u002Fsinew-ide.com\u002F",null,"Rust",61,12,1,6,0,7,21,4,3.34,"MIT License",false,"main",[25,26,27,28,29,30,31,32,33,34,35,36],"agentic","ai","ai-agent","anthropic","claude","codex","coding-assistant","llm","llm-agent","openai","openclaw","skills","2026-06-12 02:04:19","\u003Cp align=\"center\">\n  \u003Cimg src=\".github\u002Fassets\u002Fhero.png\" alt=\"Sinew — the coding harness you shape\" width=\"100%\" \u002F>\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FPaseru\u002Fsinew\u002Freleases\u002Flatest\">\u003Cimg alt=\"Release\" src=\"https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fv\u002Frelease\u002FPaseru\u002Fsinew?style=flat-square&labelColor=0b0b0d&color=3b82f6\">\u003C\u002Fa>\n  \u003Ca href=\".\u002FLICENSE\">\u003Cimg alt=\"License\" src=\"https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Flicense\u002FPaseru\u002Fsinew?style=flat-square&labelColor=0b0b0d&color=c4b5fd\">\u003C\u002Fa>\n  \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FPaseru\u002Fsinew\u002Factions\">\u003Cimg alt=\"Build\" src=\"https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Factions\u002Fworkflow\u002Fstatus\u002FPaseru\u002Fsinew\u002Frelease.yml?style=flat-square&labelColor=0b0b0d&color=3b82f6&label=build\">\u003C\u002Fa>\n  \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FPaseru\u002Fsinew\u002Freleases\">\u003Cimg alt=\"Downloads\" src=\"https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fdownloads\u002FPaseru\u002Fsinew\u002Ftotal?style=flat-square&labelColor=0b0b0d&color=c4b5fd\">\u003C\u002Fa>\n  \u003Ca href=\"https:\u002F\u002Fdiscord.gg\u002FMADQNHtZW\">\u003Cimg alt=\"Discord\" src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fdiscord-join-3b82f6?style=flat-square&labelColor=0b0b0d&logo=discord&logoColor=white\">\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  \u003Cb>Sinew\u003C\u002Fb> is a desktop AI coding harness you can actually reshape.\u003Cbr\u002F>\n  Every tool is toggleable, every description is editable, every provider is pluggable,\u003Cbr\u002F>\n  and the agent only sees the surface area you keep.\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  \u003Ccode>tauri 2\u003C\u002Fcode> · \u003Ccode>react\u003C\u002Fcode> · \u003Ccode>rust\u003C\u002Fcode> · \u003Ccode>monaco\u003C\u002Fcode> · \u003Ccode>xterm\u003C\u002Fcode> · \u003Ccode>mcp\u003C\u002Fcode>\n\u003C\u002Fp>\n\n---\n\n> [!NOTE]\n> **OAuth providers — a quick heads-up, then chill ✌️**\n>\n> Sinew can sign you in to **Codex**, **Claude Code** and **Antigravity** through their native OAuth flow, so you can plug Sinew into the subscription you already pay for instead of double-paying through an API key.\n>\n> - **Codex (OpenAI)** — fully in-bounds. The Codex CLI is open-source (Apache 2.0) and its OAuth flow is part of the publicly supported tooling, so third-party clients using it sit on solid ground.\n> - **Claude Code (Anthropic)** and **Antigravity (Google)** — the same OAuth flow is technically reserved for their own first-party clients. So in theory, those providers *could* flag accounts using it through a third-party harness.\n>\n> In practice: **no ban has ever been reported to us**, and this is the exact same approach every other open-source coding agent out there uses (opencode, crush, and friends). We track the upstream clients closely and ship updates fast whenever the flow shifts — so what Sinew sends keeps looking like a normal first-party session and stays clear of any flagging heuristics.\n>\n> Want to stay 100% sanctioned? Every provider also works with a plain **API key** or through **OpenRouter** — both fully in-bounds usages. Pick the path that feels right. Use at your own risk, but honestly: stay chill.\n\n---\n\n## Contents\n\n- [The three modes](#the-three-modes) — Act, Goal, Plan\n- [`AGENTS.md` & `DESIGN.md`](#agentsmd--designmd) — system prompt injection\n- [Multi-provider, one harness](#multi-provider-one-harness) — Anthropic, OpenAI, Google, Kimi, OpenRouter\n- [Tools](#tools) — the agent's toolset\n  - [`clean_context`](#clean_context) — the model cleans its own context\n  - [`bash` \u002F `bash_input`](#bash--bash_input) — PTY-backed shell sessions\n  - [Why dedicated `read`, `glob`, `grep`](#why-dedicated-tools-for-read-glob-and-grep)\n  - [`read`](#read) · [`glob`](#glob) · [`grep`](#grep) · [`edit_file`](#edit_file) · [`write_file`](#write_file)\n  - [`web_search`](#web_search) · [`web_fetch`](#web_fetch) · [`create_image`](#create_image)\n  - [`question`](#question) · [`todo_list`](#todo_list)\n  - [`load_mcp_tool`](#load_mcp_tool) · [`skill`](#skill)\n- [Sub-agents](#sub-agents) — configurable specialised agents\n- [Agent swarm](#agent-swarm) — peer-to-peer team of 2–8 agents\n- [Compaction](#compaction) — auto and manual\n- [Rollback](#rollback) — checkpointed conversation\n- [Architecture](#architecture) · [Install](#install) · [Build from source](#build-from-source)\n\n---\n\n## The three modes\n\n\u003Cp align=\"center\">\n  \u003Cimg src=\".github\u002Fassets\u002Fmodes.png\" alt=\"Three modes — Act, Goal, Plan\" width=\"100%\" \u002F>\n\u003C\u002Fp>\n\n### Act\n\nThe normal mode: the agent runs a classic single-turn loop. You prompt, it acts, control comes back to you.\n\n### Goal\n\nThe agent runs in a loop until the task is finished. It can keep going for hours, autonomously, without hand-holding.\n\n### Plan\n\nA non-stop question \u002F answer session. The agent explores the code, asks you a question, you answer, it explores some more, asks another, and so on. It **never exits the loop on its own** — the plan is only written when **you** click **\"Send and stop questions\"**.\n\nThe produced plan contains no technical jargon: no code, no code map, no file list. That's a deliberate choice. After a lot of A\u002FB against the plans produced by Claude Code, Codex and friends, the ones that work best describe the **functional** layer — what the app should do — without dictating the technical structure.\n\nFor a game, for example, the plan describes the expected experience, not the directory tree. Otherwise the agent burns all its reasoning **before** it ever touches code, and ends up boxed inside a structure forced from the start. By staying functional, you free its creativity at build time — it gets to decide how to structure things.\n\nIt's only constrained technically if the user wants to impose a specific stack.\n\n> The Plan mode prompt is fully editable in the **Settings** panel — so the harness adapts to how you work, not the other way around.\n\n---\n\n## `AGENTS.md` & `DESIGN.md`\n\nSinew supports two reference files at the root of the workspace, and **injects them automatically into the model's system prompt**.\n\n**`AGENTS.md`** — general instructions for the agent: project conventions, constraints, things to avoid, etc. It's the equivalent of a README you write for the model rather than for a human. Open convention popularised by Codex and shared with a whole ecosystem of other tools — one file works everywhere. For comparison, `CLAUDE.md` (Anthropic's own convention) is **explicitly ignored** in favour of this common standard.\n\n**`DESIGN.md`** — the project's design system: colours, typography, components, UI rules, etc. Convention introduced by Google. Sinew injects it with a dedicated header so that your product, UX, visual and frontend decisions respect the design system you use, whatever it is.\n\nBoth files get a dedicated icon in the file tree.\n\n---\n\n## Multi-provider, one harness\n\nSinew supports five model providers, each with its own connection method:\n\n| Provider | Method |\n|---|---|\n| **Anthropic** | subscription |\n| **OpenAI** | subscription |\n| **Google** | subscription |\n| **Kimi** | subscription |\n| **OpenRouter** | API key |\n\n### OAuth mode — the real differentiator\n\nWhen you connect to Anthropic, OpenAI, Google or Kimi via OAuth, Sinew uses **your existing subscription directly** (Claude Max, ChatGPT Plus \u002F Pro, etc.) with its own harness. No API key to provide, no metered billing — you're already paying the subscription anyway, you might as well use it.\n\n### No ecosystem lock-in\n\nClaude Code is limited to Anthropic models. Codex to OpenAI models. Sinew isn't locked anywhere: you can connect several providers in parallel and pick the right model for the right task.\n\n### Mix models by capability\n\nModel selection happens at three levels:\n\n- **Per mode.** Act, Plan and Goal can each have their own dedicated model in Settings. Typically: a large model for Plan (reasoning), a solid one for Act (execution), a fast one for Goal (long loop).\n- **Per sub-agent.** Each configured sub-agent has its own model (see the sub-agents section).\n- **Per teammate** in an Agent Team, through sub-agent profiles.\n\n---\n\n## Tools\n\nThe agent has access to a full set of tools:\n\n| Tool | Role |\n|------|------|\n| `bash` | Run shell commands |\n| `bash_input` | Send input to an interactive shell session |\n| `read` | Read files |\n| `glob` | Find files by pattern |\n| `grep` | Search text \u002F regex in files |\n| `edit_file` | Edit existing files with ordered search\u002Freplace operations |\n| `write_file` | Write complete files with overwrite guardrails |\n| `web_search` | Web search |\n| `web_fetch` | Fetch the contents of a URL |\n| `create_image` | Generate images |\n| `question` | Ask the user questions |\n| `todo_list` | Manage a task list |\n| `clean_context` | Clean useless tool results out of the context |\n| `load_mcp_tool` | Load an external MCP tool |\n| `skill` | Load a skill on demand (active when skills are present) |\n| `subagent_*` | Delegate a task to a configured sub-agent (one tool per enabled sub-agent) |\n| `team_run` | Launch an agent team |\n| `team_status` | Inspect the team's state |\n| `team_stop` | Stop one agent or the whole team |\n| `send_message` | Send a message between agents |\n\nEach tool can be **individually disabled** in Settings, which lets you go from a full-featured setup down to a minimalist one (CLI-style, à la Pi Code). Every tool description is also **editable**, which gives you another lever to tweak the harness.\n\n\u003Cp align=\"center\">\n  \u003Cimg src=\".github\u002Fassets\u002Fharness.png\" alt=\"Minimal vs Full harness\" width=\"100%\" \u002F>\n\u003C\u002Fp>\n\n---\n\n### `clean_context`\n\nSinew is the only coding agent where the model can **clean its own context**. None of the others — Cursor, Claude Code, Codex, Cline — offers this.\n\nThe tool takes a list of `tool_call_id`s from the current turn. For each one, the content of the result is replaced in history by an ultra-short placeholder (`[Tool result cleaned by you: irrelevant to future context.]`). The agent does its own mental housekeeping, by itself.\n\nThe tool description is written so the agent only deletes results that are **really** useless: explorations that went nowhere, paths it looked at and discarded, fruitless searches. Anything it cited, referenced, or used to make a decision stays. And when in doubt, it keeps.\n\nTwo guardrails:\n\n- The tool only touches results **from the current turn** (no retroactive purge of older context).\n- The placeholder stays visible — the agent knows there used to be a result here that it chose to throw away. **No silent forgetting.**\n\nAnd that \"current turn only\" limit solves a problem many people will anticipate: **prompt caching**. If we touched older tool results, we'd break the prefix cached by the provider, and every subsequent turn would replay at full price. Here, the current turn isn't cached yet, so we can purge it without losing anything on the billing side. **You gain context without sacrificing the cache.**\n\nWhy this is game-changing: tool results blow up the context very fast. A `glob` can return hundreds of paths, a `read` up to 500 lines, a `grep` a mountain of matches. On an exploration turn, most of that is noise. Without `clean_context` that noise piles up — especially in Goal mode where the context grows quickly. With it, the agent lives in a context that stays constantly cleaned of dead-end exploration.\n\n---\n\n### `bash` \u002F `bash_input`\n\n`bash` runs a shell command, `bash_input` interacts with an ongoing session.\n\nOn macOS \u002F Linux: Bash. On Windows: PowerShell (the system prompt warns the model about the syntax difference).\n\nThe interesting bit: if a command doesn't finish right away, Sinew returns a `session_id` and lets the process keep running. The agent can then send input, poll the output, or kill the session. PTY-backed, so `vim`, `top`, a REPL or a dev server actually work.\n\nOn the UI side, each command shows up in a card that displays the exact input and the raw shell output, untransformed.\n\n---\n\n#### Why dedicated tools for `read`, `glob` and `grep`?\n\nSome agents like Codex rely on the terminal for most everyday operations — reading a file, searching text, listing paths. The agent has to compose the right shell command every time. Sinew does the opposite: these operations get their own dedicated tools.\n\nThe idea: a shell command returns everything raw, with no way to force a limit, and the output is often noisy. A dedicated tool lets us **control exactly what comes out** — clean response, readable, no redundancy. And since it covers the same flexibility as the equivalent shell command, you don't lose any expressivity.\n\n---\n\n### `read`\n\nReads a file. Three parameters: `path`, `limit` and `offset`.\n\nThe twist: **`limit` is required**. Unlike other coding agents that leave it optional, Sinew forces the model to declare how many lines it wants. That preserves the agent's context and pushes it to target what's actually useful rather than vacuum everything up. If it needs to see more, it widens the limit and asks again. And the smarter models get, the better they exploit constraints like this in their favour.\n\nHere's what the agent receives after a `read` on a React component:\n\n```\npath: src\u002Fcomponents\u002FButton.tsx\ntotal: 124\n\n  1 | import { forwardRef } from \"react\";\n  2 | import clsx from \"clsx\";\n  3 |\n  4 | type ButtonProps = {\n...\n```\n\nA header with the path and the total line count, then the requested lines, numbered.\n\nAnd that's Sinew's whole philosophy: give the **minimum useful information**, no repetition. Just the path, the total line count (so the agent knows where it is and can paginate), and each line numbered. Nothing more. The model figures out the rest — target, cross-reference, widen if needed.\n\n---\n\n### `glob`\n\nFinds files in the workspace by pattern. Three parameters: `pattern`, `limit` and `path`.\n\nSame rule: **`limit` is required**.\n\nThe implementation sits on top of **ripgrep**.\n\nHere's what the agent receives after a `glob` on `src\u002F**\u002F*.tsx`:\n\n```\nmatches: 42\nshown: 25\n\nsrc\u002Fcomponents\u002FButton.tsx\nsrc\u002Fcomponents\u002FInput.tsx\n...\n```\n\nTwo counters: **`matches`** (the total found) and **`shown`** (how many are actually displayed). If they differ, it knows it was truncated and can either refine the pattern or widen `limit`. Same logic throughout: minimal signal, but exactly the signal that's needed.\n\n---\n\n### `grep`\n\nSearches text or a regex in the workspace files. Seven parameters: `pattern`, `limit`, `path`, `include`, `output_mode`, `unique`, `exclude_pattern`.\n\nSame rule: **`limit` is required**.\n\nThe implementation sits on top of **ripgrep**. The `include` parameter scopes the search to a file type (`*.tsx`, `*.rs`, etc.), and `path` accepts an array to target several subdirectories in a single call.\n\nThe **`output_mode`** parameter lets the agent pick the result shape based on its need, rather than filter or parse afterwards:\n\n- `context` *(default)* — grouped by file with line number + content\n- `matches` — only the matched strings\n- `files` — only the paths of matching files\n- `count` — number of matches per file\n\nTwo complementary filters:\n\n- **`unique`** dedups output lines (especially useful with `output_mode=matches`)\n- **`exclude_pattern`** is an anti-match: a regex that excludes lines whose content matches it. Handy to drop tests, comments, or other noise without contorting the main pattern.\n\nHere's what the agent receives after a `grep` on `forwardRef` filtered to `*.tsx` (`context` mode):\n\n```\nmatches: 12\nfiles: 3\nshown: 8\n\nsrc\u002Fcomponents\u002FButton.tsx\n  42 | const Button = forwardRef(...)\n  87 | export default Button;\n\nsrc\u002Fcomponents\u002FInput.tsx\n  15 | const Input = ...\n...\n```\n\nThree counters in the header: **`matches`** (total matches), **`files`** (number of files involved), **`shown`** (in case of truncation). And the results are **grouped by file** instead of the flat `file:line:text` format — same idea as RTK for those who know it: more readable and more compact for the agent to consume.\n\n---\n\n### `edit_file`\n\nEdits existing workspace text files with ordered search\u002Freplace operations. The agent sends top-level `files` grouped by file:\n\n```json\n{\n  \"files\": [\n    {\n      \"path\": \"src\u002Ffoo.ts\",\n      \"edits\": [\n        {\n          \"oldContent\": \"const oldName = value;\",\n          \"newContent\": \"const newName = value;\",\n          \"replaceAll\": false\n        }\n      ]\n    }\n  ]\n}\n```\n\n`oldContent` must be non-empty. By default it must match once in the file's current content at that step; if it appears multiple times, the agent adds surrounding context until it is unique. The matcher first tries exact text, then falls back to whitespace-\u002Fpunctuation-tolerant matching for common formatting drift. Set `replaceAll: true` on a replacement to replace every non-overlapping occurrence found at that step. `newContent` may be empty to delete the matched block.\n\nThe tool requires a successful prior `read` and refuses to write if the file changed since that read. Multiple replacements in the same file are applied sequentially in memory, so each edit sees the result of the previous edit; the file is still written only once after the full plan succeeds.\n\n### `write_file`\n\nWrites a complete text file with `path` and `content`.\n\nIt creates new files directly, including parent directories. If the file already exists, the agent must read it first; `write_file` refuses to overwrite if the file changed since that read. For targeted changes, the agent should prefer `edit_file`.\n\n---\n\n### `web_search`\n\nTwo providers to choose from, configurable in Settings.\n\n**LinkUp** *(paid, API key required)* — the more powerful one. On LinkUp's side, an LLM receives the query, runs the search, and **synthesises a natural-language answer with numbered inline citations**, plus a list of sources (up to 12) with their excerpts. Two modes: `standard` for a direct answer, `deep` for complex multi-source research. The agent can then chain with `web_fetch` to drill into a specific source.\n\n**Exa** *(free, public MCP)* — classic search. Returns a list of results with titles, URLs and content excerpts. It's what most other coding agents that offer web search rely on.\n\n---\n\n### `web_fetch`\n\nFetches the contents of a URL — typically a source returned by `web_search`. Single parameter: `url`.\n\nThe page is converted to clean Markdown before it reaches the agent.\n\n---\n\n### `create_image`\n\nImage generation, via **GPT Image 2** (OpenAI) or **Nano Banana 2** (Google), your choice in Settings. In both cases the agent controls the usual parameters (size, format, quality, etc.).\n\nFor GPT Image 2, two auth modes: either an **OpenAI API key**, or directly your **ChatGPT subscription** with no API key needed.\n\n---\n\n### `question`\n\nA question tool inside the chat. Classic: the agent can send one or several questions at once, in `single_choice` or `multiple_choice` form.\n\n---\n\n### `todo_list`\n\nThe agent's todo list. A single tool does everything: add, modify, mark as done, or delete a task.\n\nThe difference with Cursor, Claude Code, Codex and the rest: in their tools the todo is just another tool call. When the agent invokes it, the result stays in the conversation and eventually drowns under the tool calls that follow.\n\nSinew **re-injects the full state at every turn into the system reminder**. The model therefore always sees the up-to-date version in front of its eyes, no matter what happened since. That's what changes everything on long tasks — typically in Goal mode, where without it the agent would lose the thread.\n\n---\n\n### `load_mcp_tool`\n\nSinew supports the MCP protocol. Servers are configured in Settings.\n\nBut, unlike what you might expect, **MCP tools are not exposed directly** to the agent. What lives in the system prompt is just a **compact catalog** inside the `load_mcp_tool` description:\n\n```\nLoad one MCP tool before calling it. Available MCP tools:\n- Context7 \u002F query-docs\n- Context7 \u002F resolve-library-id\n- Linear \u002F create_issue\n- Linear \u002F search_issues\n...\n```\n\nThe agent calls `load_mcp_tool` with a `server` and a `tool`. From that point on, the tool in question is loaded into the conversation for good, with its full description and input schema. It can then use it normally.\n\nWhy the gymnastics? The classic MCP problem: if you connect several servers (Context7, Linear, Notion, GitHub…), you can end up with 50+ tools, each with a verbose description and an input schema. Dumped as-is into the system prompt, that eats thousands of tokens **before the agent even starts working**.\n\nWith lazy-load via catalog: only a `server \u002F tool` index stays permanently in the prompt, the full schemas only inject on demand, and once loaded a tool stays available for the whole conversation.\n\n---\n\n### `skill`\n\nSame logic as `load_mcp_tool`, but for **skills**. The tool only appears in the system prompt **if at least one skill is discovered** on the machine or in the workspace.\n\nIts description carries a compact catalog:\n\n```\nLoad one skill by name before using it. Available skills:\n- pdf-extraction\n- review-checklist\n- release-notes\n...\n```\n\nThe agent calls `skill` with a `name`, Sinew reads the `SKILL.md` of the requested skill and injects its content into the conversation. Same benefit as MCP: no skill takes up prompt space until it's explicitly loaded.\n\n**Four discovery locations**, from highest priority to lowest:\n\n1. `\u003Cworkspace>\u002F.agents\u002Fskills\u002F`\n2. `\u003Cworkspace>\u002F.sinew\u002Fskills\u002F`\n3. `~\u002F.agents\u002Fskills\u002F` *(global, follows the user)*\n4. `~\u002F.sinew\u002Fskills\u002F`\n\nEach skill is a directory containing a `SKILL.md` file.\n\nThe `.agents\u002Fskills\u002F` format is deliberately aligned with the **Claude Agent Skills convention**: a skill written for Claude works in Sinew as-is, and vice-versa. The `.sinew\u002Fskills\u002F` namespace stays available for project-specific skills.\n\nSkills can be individually enabled or disabled in Settings.\n\n---\n\n## Sub-agents\n\nSinew lets you configure as many **sub-agents** as you want in Settings, each with its own `name`, `description`, system `prompt`, `model`, and an `enabled` flag. Every enabled sub-agent is exposed to the main agent as a tool named `subagent_\u003Cid>` (e.g. `subagent_security-reviewer`, `subagent_doc-writer`). The tool description reuses the one you set in Settings, and the schema reduces to a single free-form `prompt`.\n\nWhen the main agent calls a sub-agent, Sinew launches a **full real turn** with the sub-agent's model and prompt, and the whole harness stays active: standard tools, `clean_context`, `todo_list`, MCP, skills, all of it. The sub-agent works in isolation, then returns a result to the main agent.\n\nTwo ways to use it:\n\n1. **Direct delegation (one-shot).** The main agent calls `subagent_\u003Cid>` for a focused task. Handy for handing off a precise job to a specialised prompt or model without changing the global harness.\n2. **Inside an Agent Team.** You assign a teammate to a sub-agent profile through `agent_profiles` in `team_run`. The teammate then inherits the sub-agent's prompt and model (see the next section).\n\n---\n\n## Agent swarm\n\n\u003Cp align=\"center\">\n  \u003Cimg src=\".github\u002Fassets\u002Fswarm.png\" alt=\"Agent swarm — peers, shared board, no lead\" width=\"100%\" \u002F>\n\u003C\u002Fp>\n\nThe main agent can launch a **team of 2 to 8 agents** to work together on an objective. No lead agent, no hierarchy: all teammates are peers and coordinate themselves through shared state.\n\nEach teammate can inherit a **sub-agent profile** pre-configured in Settings (with its own prompt and model). You don't pick a model on the fly for a teammate — you assign one of the profiles you already defined.\n\n### Difference with Claude Code Agent Teams\n\nClaude Code follows a **lead \u002F sub-agents** model: a main agent dispatches work to specialised sub-agents that execute their task and report back. It's effective for short orchestration, but it stays hierarchical.\n\nSinew follows a **peer-to-peer** model: no lead, the teammates collaborate autonomously. More powerful for long, parallel tasks, where each agent needs to make progress without waiting for a conductor.\n\nThe obvious risk of a flat team with no lead is drift — agents going in diverging directions, or stepping on each other. Sinew defuses that with the mechanisms below.\n\n### Coordination — everything flows through the system reminder\n\nAt every turn of every teammate, Sinew injects into its system reminder:\n\n- **The full team state** (`\u003Cagent_team_state>`): who is who, each teammate's status (`running`, `idle`, `error`…), the whole task board, and the most recent file changes. Each agent therefore sees, at all times, what the others are doing, without having to dig through its own context.\n- **Messages received from other teammates** (`\u003Cqueued_peer_messages>`): when a teammate sends a `send_message`, the recipient receives it at the start of its next turn via the reminder. No message lost in the conversation, no risk of being buried under further tool calls.\n\nSame philosophy as `todo_list`: important state is never \"somewhere in history\", it's **always fresh in front of the model's eyes**.\n\nExample of what a teammate receives in its system reminder at the start of a turn:\n\n```\n\u003Cagent_team_state>\nteam: refactor-auth | you: @backend\nteammates:\n- @backend [running] you\n- @frontend [running]\n- @reviewer [idle]\ntasks:\n- #1 [completed] @backend Extract the auth module into a dedicated crate\n- #2 [in_progress] @backend Implement the new JWT flow\n- #3 [blocked] @frontend Migrate the React client to the new endpoint (blocked by #2)\n- #4 [pending] @reviewer Security review of the JWT flow\nrecent file changes (newest -> oldest):\nnewest -> @backend edit_file modified crates\u002Fauth\u002Fsrc\u002Fjwt.rs (+128 -42)\n            @backend write_file added crates\u002Fauth\u002Fsrc\u002Flib.rs (+86 -0)\noldest -> @frontend edit_file modified src\u002Flib\u002Fapi.ts (+12 -8)\n\u003C\u002Fagent_team_state>\n\n\u003Cqueued_peer_messages>\n\u003Cteammate-message teammate_id=\"@frontend\" to=\"@backend\">\nWhen the \u002Fauth\u002Frefresh endpoint is ready, tell me the exact response contract so I can adapt the client.\n\u003C\u002Fteammate-message>\n\u003Cteammate-message teammate_id=\"@reviewer\" to=\"*\">\nHeads-up: I'm starting my review in 10 min, please push your latest commits to the refactor-auth branch.\n\u003C\u002Fteammate-message>\n\u003C\u002Fqueued_peer_messages>\n```\n\n### Task board with dependencies\n\nThe shared board supports explicit dependencies (`blockedBy`). A blocked task can't be claimed or started until its dependencies complete — auto-unblock fires automatically when they do. That prevents teammates from stepping on each other in workflows that require an order.\n\n### Swarm tools\n\n- `team_run` *(main agent side)* — launch a team with an objective, named teammates, an initial task board, and optionally per-teammate prompts or sub-agent profiles.\n- `team_status` *(main side)* — inspect the state of the active team.\n- `team_stop` *(main side)* — stop one teammate, or the whole team.\n- `send_message` *(teammate side)* — DM another teammate, or broadcast to all agents in the team.\n- An internal `task_list` tool lets teammates manipulate the shared board (create, update, claim, delete).\n\n---\n\n## Compaction\n\nSinew handles two modes of conversation compaction.\n\n**Automatic** — triggered on its own when the context window fills up. The history is summarised to free room and let the agent keep going.\n\n**Manual** — triggered from a button in the UI. The twist: you can attach an **optional directive** to steer compaction towards a specific topic (\"keep mostly what concerns X\", etc.). The cleanup is then more aggressive on everything outside the requested topic.\n\n---\n\n## Rollback\n\nIn the chat, **every past user message is clickable**. Clicking it opens a preview listing all files modified by the agent since that message, and offers to rewind to that point of the conversation.\n\nBefore confirming, a **toggle** lets you choose:\n\n- **Revert** the workspace changes (files are restored to their previous state)\n- **Keep** the changes as-is (you only undo the chat history)\n\nSinew then deletes all subsequent user \u002F assistant messages, and optionally restores the files. The conversation can resume cleanly from that point.\n\nUnder the hood, each turn records a *checkpoint* that captures the before \u002F after state of the files it touched — that's what makes revert possible at any past point.\n\n---\n\n## Architecture\n\n\u003Cp align=\"center\">\n  \u003Cimg src=\".github\u002Fassets\u002Farchitecture.png\" alt=\"Sinew architecture\" width=\"100%\" \u002F>\n\u003C\u002Fp>\n\n- **`src\u002F`** — React UI (Monaco editor, xterm terminal, chat, settings, file tree).\n- **`src-tauri\u002F`** — Tauri 2 shell, IPC commands, workspace I\u002FO, conversation store, checkpoint store.\n- **`crates\u002Fsinew-core`** — Provider-agnostic types: messages, tools, streams, model definitions.\n- **`crates\u002Fsinew-app`** — Agent loop (Act \u002F Goal \u002F Plan), tool implementations, swarm, MCP, compaction, rollback.\n- **`crates\u002Fsinew-{anthropic,openai,google,kimi,openrouter}`** — Provider adapters (auth, wire, streaming).\n\n---\n\n## Screenshot\n\n\u003Cp align=\"center\">\n  \u003Cimg src=\".github\u002Fassets\u002Fscreenshot.png\" alt=\"Sinew IDE\" width=\"100%\" \u002F>\n\u003C\u002Fp>\n\n---\n\n## Install\n\nGrab the latest build for your OS from the\n[releases page](https:\u002F\u002Fgithub.com\u002FPaseru\u002Fsinew\u002Freleases\u002Flatest).\n\n- **macOS** — `.dmg`\n- **Windows** — `.msi` \u002F `.exe`\n- **Linux** — `.AppImage` \u002F `.deb`\n\nThe app self-updates from GitHub releases.\n\n---\n\n## Build from source\n\n```bash\n# requires Rust 1.80+ and Node 20+\n# see https:\u002F\u002Ftauri.app\u002Fstart\u002Fprerequisites\u002F for platform deps\n\nnpm install\nnpm run tauri dev      # development\nnpm run tauri build    # release bundle\n```\n\nThe repo is a Cargo workspace (`crates\u002F*` + `src-tauri\u002F`) plus a Vite + React frontend (`src\u002F`).\n\n---\n\n## OAuth credentials\n\nProvider OAuth client IDs (and Google's client secret) are embedded in the source. This follows the standard practice for \"installed applications\" — the same approach used by tools like `gcloud`. These credentials are not treated as secret in this context.\n\n---\n\n## Community\n\n- [Discord](https:\u002F\u002Fdiscord.gg\u002FMADQNHtZW) — chat, support, share your harness configs\n- [Issues](https:\u002F\u002Fgithub.com\u002FPaseru\u002Fsinew\u002Fissues) — bugs and feature requests\n- [Discussions](https:\u002F\u002Fgithub.com\u002FPaseru\u002Fsinew\u002Fdiscussions) — design, providers, MCP\n\n---\n\n## License\n\n[MIT](.\u002FLICENSE)\n\n\u003Cp align=\"center\">\n  \u003Csub>Built with Tauri, Rust, and a stubborn refusal to ship a black-box harness.\u003C\u002Fsub>\n\u003C\u002Fp>\n","Sinew 是一款集成了AI编码助手的桌面IDE。它允许用户自定义工具、编辑描述和插拔提供商，使得AI代理仅能看到用户选择暴露的部分。该项目采用Rust编写，并结合了Tauri 2、React、Monaco Editor等技术栈来构建高效且灵活的开发环境。特别适合需要个性化定制AI辅助功能的开发者使用，无论是进行代码生成、调试还是学习新的编程技巧都能得到很好的支持。此外，Sinew 支持通过OAuth方式接入Codex（OpenAI）、Claude Code (Anthropic) 等服务，让用户能够利用已有的订阅而不必额外付费。",2,"2026-06-11 04:06:45","CREATED_QUERY"]