What is the tech stack of this project?

what's the stack of this project?

Chopin is a TypeScript/Bun monorepo with this stack:

• Frontend: React 19, Vite 7, Tailwind CSS 4
• Rich-text editing: Lexical + MDXEditor
• Real-time collaboration: Yjs over WebSockets, including shared editing and presence
• Backend: Bun’s native HTTP/WebSocket server with a custom router—no Express-style framework
• Database: PostgreSQL 17, storing document/Yjs state, chat, decisions, jobs, and sessions
• AI integration: GitHub Copilot SDK for the hosted Planner agent
• Authentication/repository access: GitHub App and GitHub APIs
• Agent interoperability: Streamable HTTP MCP endpoint
• Testing: Bun Test and Playwright E2E
• Tooling: Bun workspaces, TypeScript, dprint, Oxlint
• Deployment: Docker/Docker Compose; one app process and one PostgreSQL database

Architecturally, the production Bun process serves the compiled React client, HTTP API, MCP endpoint, and WebSocket from the same origin.

Good source entry points:

• package.json — workspace and shared dependency versions
• apps/web/package.json — frontend stack
• apps/server/package.json — backend and Copilot dependencies
• packages/editor/package.json — editor/collaboration stack
• docs/architecture.md — system architecture
• compose.yaml and Dockerfile — deployment stack

til "GitHub Copilot SDK". interesting. tell me more about that package. why should i use it? model agnostic, or just copilot apis?

The GitHub Copilot SDK is less like a thin LLM client and more like an embeddable agent runtime.

Your application talks to the SDK, which communicates with the Copilot CLI running in server mode over JSON-RPC:

Application → @github/copilot-sdk → Copilot CLI runtime → model/provider

It gives you higher-level agent features out of the box:

• Stateful sessions and streaming events
• Custom function tools with schemas and handlers
• MCP server integration
• Permission callbacks for every tool invocation
• Custom agents, prompts, skills, and tool restrictions
• Copilot/GitHub authentication
• Model discovery and selection
• Session limits and usage controls
• Built-in coding/repository tools

##Is it model-agnostic?

Yes at the model level, but not completely at the runtime level.

###Through GitHub Copilot

You can select among models Copilot makes available, including models from:

• Anthropic
• OpenAI
• Google
• Microsoft and others

Your application uses the same session/tool API regardless of the selected model. You can also use model: "auto".

In that sense it is multi-model: it isn’t restricted to a GitHub-owned model.

###Through BYOK

The current SDK also supports bring-your-own-key configurations for:

• OpenAI
• Anthropic
• Azure OpenAI / Azure AI Foundry
• OpenAI-compatible endpoints
• Local services such as Ollama

BYOK bypasses Copilot authentication and bills through your provider.

Conceptually:

const session = await client.createSession({
  model: "gpt-4.1",
  provider: {
    type: "openai",
    apiKey: process.env.OPENAI_API_KEY,
  },
});

However, this does not make it a generic abstraction like Vercel AI SDK or LiteLLM. The orchestration layer is still the Copilot CLI agent runtime. Its session semantics, built-in tools, permission system, system prompt, and feature behavior are Copilot-specific. Provider capabilities may also differ.

A useful distinction is:

##Why would you use it?

It makes sense when you want to build an agentic developer product, rather than simply call an LLM.

For example, if your app needs the model to:

1. Receive a task
2. Search a repository
3. Call application-defined tools
4. Access MCP servers
5. Ask for approval before sensitive actions
6. Stream progress and tool events
7. Continue within a session

…the SDK supplies most of that control plane.

It is particularly attractive when:

• Your users already have Copilot accounts or entitlements.
• GitHub identity and repository context are central.
• You want access to several model providers through one Copilot-facing API.
• You need custom tools and MCP without writing your own agent loop.
• You want explicit permission interception around tool calls.
• You want an agent runtime available across TypeScript, Python, Go, .NET, Java, and Rust.

##Why might you not use it?

I’d probably choose a lower-level model SDK or a neutral AI framework when:

• You only need chat/completions or structured generation.
• Avoiding the Copilot CLI child process/runtime is important.
• You want complete control over the agent loop and system prompt.
• Your application is unrelated to coding or GitHub.
• Provider portability is a hard architectural requirement.
• You need exactly matching behavior across providers.
• You want to avoid Copilot billing, policy, or entitlement dependencies and don’t need its BYOK agent layer.

Also, built-in coding tools require careful sandboxing. The SDK offers permission handlers, but the application still owns the security policy; blindly approving all tools would be risky in a hosted application.

##How Chopin uses it

Chopin uses the SDK firmly in Copilot-backed mode, not BYOK mode.

It:

• Starts CopilotClient against a Copilot CLI process.
• Creates disposable sessions.
• Passes the current user’s GitHub App user token into each session.
• Requires that user’s Copilot entitlement.
• Selects the model through MODEL, defaulting to claude-sonnet-4.6.
• Defines a custom Planner agent and custom document-editing tools.
• Connects to GitHub’s MCP endpoint for read-only pull-request access.
• Uses permission callbacks to enforce repository and session boundaries.
• Disables filesystem access, plugins, skills, repository instructions, host Git operations, and persistent SDK session storage.

See apps/server/src/agent/client.ts, especially hardened(), plannerConfiguration(), and connect(). The project’s security model is summarized in docs/hosted-agent.md.

So in Chopin, switching MODEL from Claude to another Copilot-supported model is intended to be straightforward. Switching from Copilot authentication to OpenAI/Anthropic BYOK would require code and configuration changes because Chopin currently always supplies a GitHub token and relies on Copilot/GitHub capabilities.

Official references:

• Copilot SDK repository
• SDK getting started
• Authentication and BYOK
• Supported Copilot models