Files
Bundle OKF 0.2 · 7 conceitos · myclr08/openwiki-copilot-cli
Open source Repository Open in the app JSON README (API)
About
# Files
- [OpenWiki Quickstart](quickstart.md) - Quickstart reference for the OpenWiki TypeScript CLI, including documentation-generation workflows, supported model providers, and the primary source files. Use it to navigate the repository's architecture, commands, agent runtime, operations, and connectors.
# Directories
- [agent](agent/)
- [architecture](architecture/)
- [cli](cli/)
- [evals](evals/)
- [integrations](integrations/)
- [operations](operations/)
Details
- Kind
- OKF bundles
- Topic
- Developer tools
- Publisher
- myclr08
- Origin
- okf_github
- Category
- dados
- Version
- 0.2
- Last push
- 2026-08-21T10:21:15Z
- Repository state
- ativo
- Language
- TypeScript
- License
- MIT
- Added
- 2026-09-08 09:04:14
- Updated
- 2026-09-08 09:04:14
- Origin id
myclr08/openwiki-copilot-cli:openwiki/index.md
README
<!-- markdownlint-disable MD033 MD041 -->
<div align="center">
<img alt="OpenWiki" src="./static/openwiki-lockup.png" width="620">
### The self-maintaining wiki. Built for agents, explored by humans.
[](https://www.npmjs.com/package/openwiki)
[](https://www.npmjs.com/package/openwiki)
[](https://nodejs.org)
[](./LICENSE)
[](https://github.com/langchain-ai/deepagentsjs)
<a href="https://trendshift.io/repositories/70339?utm_source=trendshift-badge&utm_medium=badge&utm_campaign=badge-trendshift-70339" target="_blank" rel="noopener noreferrer"><img src="https://trendshift.io/api/badge/trendshift/repositories/70339/daily" alt="langchain-ai%2Fopenwiki | Trendshift" width="250" height="55"/></a>
</div>
OpenWiki is a CLI that writes and maintains a wiki for your codebase or your personal knowledge. An agent reads your sources, synthesizes a linked Markdown wiki you own, and keeps it current on every change. It is built for agents to read as memory, and it ships an interactive visualizer for humans to explore.
**OpenWiki gives you:**
- **Agent-written docs** that stay accurate, generated by a [Deep Agents](https://github.com/langchain-ai/deepagentsjs) documentation agent.
- **Two modes:** a `code` wiki for a repository, or a `personal` wiki for your own knowledge.
- **Twelve model providers** out of the box, from OpenAI and Anthropic to Bedrock, Gemini, and any OpenAI-compatible gateway — or **GitHub Copilot CLI** for a whole folder of repositories at once.
- **Built-in connectors** for Custom MCP, Notion, Slack, Gmail, X, Web Search, Hacker News, and local git repositories.
- **An interactive visualizer** that turns any wiki into a live, explorable node graph.
- **Self-updating** through GitHub Actions, GitLab CI, or Bitbucket Pipelines.
- **Open Knowledge Format** ([OKF v0.2](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md)) output with validated Mermaid diagrams.
## 🎉 What's new
- **Workspace mode:** `openwiki workspace <folder>` documents every repository in a folder with GitHub Copilot CLI, writing one central wiki with a cross-repository index.
- **Custom MCP connector:** point OpenWiki at any MCP server and pull its tools into a run, no bespoke integration required.
- **LangSmith APAC region:** the LangSmith connector now works against APAC-hosted workspaces.
- **OpenAI Responses API:** OpenAI-compatible providers can opt into the Responses API instead of Chat Completions.
- **Provider-aware CI:** the generated self-update workflow now emits an env block matched to your configured provider, so scheduled runs work out of the box.
## Quick start
Install the CLI:
```sh
npm install -g openwiki
```
Generate a wiki for the current repository. The first run walks you through picking a provider, key, and model, then writes docs to `openwiki/`:
```sh
openwiki --init
```
Keep it current automatically by adding a scheduled CI job that opens a docs PR on every change:
- **GitHub Actions:** copy [`openwiki-update.yml`](./examples/openwiki-update.yml) into `.github/workflows/openwiki-update.yml`.
- **GitLab CI:** copy [`openwiki-update.gitlab-ci.yml`](./examples/openwiki-update.gitlab-ci.yml) into `.gitlab-ci.yml` or include it from your pipeline.
- **Bitbucket Pipelines:** copy [`openwiki-update.bitbucket-pipelines.yml`](./examples/openwiki-update.bitbucket-pipelines.yml) into `bitbucket-pipelines.yml`, then schedule the `openwiki-update` pipeline.
> [!NOTE]
> On Windows, install with a Node.js package manager (`npm install -g openwiki` or `pnpm add -g openwiki`). Installing with `bun` can fall back to compiling the `better-sqlite3` native dependency, which needs Visual Studio Build Tools with the Desktop development with C++ workload.
## Two modes
OpenWiki runs in one of two modes. Bare `openwiki`, `openwiki --init`, and `openwiki --update` default to **code** mode; add the `personal` positional (or `--mode personal`) for the personal brain.
| Mode | Documents | Writes to | Get started |
| -------------------- | ---------------------- | ----------------------- | -------------------------- |
| **Code** _(default)_ | The current repository | `openwiki/` in the repo | `openwiki --init` |
| **Personal** | Your connected sources | `~/.openwiki/wiki` | `openwiki personal --init` |
By default the CLI stays open after a run so you can send follow-up messages. Add `-p` / `--print` for a one-shot, non-interactive run that prints the final output and exits. `--init` and `--update` auto-exit on success in an interactive terminal, so the same command works one-shot or interactively.
## Explore your wiki
Turn any wiki into an interactive node graph with a live, side-by-side Markdown reader:
```sh
openwiki visualize
```
<div align="center">
<img alt="The OpenWiki visualizer: an interactive node graph beside a live Markdown reader." src="./static/visualizer.gif" width="880">
</div>
This serves `./openwiki` on a local loopback address (`127.0.0.1`, never exposed on the network) and opens your browser to the graph. Edits to the wiki files are picked up automatically while the server runs. Pass a path to visualize a different directory, `--port <port>` to choose the port (it increments on conflict; default `4321`), and `--no-open` to leave the browser alone:
```sh
openwiki visualize openwiki --port 4400 --no-open
```
To publish the visualizer beside generated documentation, export a static directory instead of starting the server:
```sh
openwiki visualize openwiki --export docs/openwiki-visualizer
```
The export contains `index.html`, `client.js`, `client-lib.js`, and `graph.json`. Its client reads the sibling graph file and does not use live reload, so the directory can be hosted by GitHub Pages, MkDocs, or any other static host. `--export` cannot be combined with `--port` or `--no-open`.
> [!NOTE]
> The page loads its graph, Markdown, and diagram libraries from a public CDN, so an internet connection is required for both local and static viewers.
## Many repositories, one wiki
`openwiki workspace` documents a whole folder of repositories in one run, using [GitHub Copilot CLI](https://github.com/github/copilot-cli) as the agent instead of a hosted model provider:
```sh
openwiki workspace ~/repos
```
Point it at the folder your checkouts live in. It finds every git repository inside, documents them one at a time, and writes a single central wiki:
```
~/repos/openwiki/
index.md cross-repository index
repos/api-service/
index.md
overview.md
...
repos/web-app/
...
```
Your repositories are never written to. Copilot runs with the wiki directory as its working directory and only gets read access to the source through `--add-dir`, and each repository's git status is compared before and after the run, so a stray write is reported instead of going unnoticed.
The final page is the point of running them together: after every repository is documented, one more pass reads the per-repository wikis and writes the cross-repository index — what this collection of code is, and which repositories actually depend on each other.
```sh
openwiki workspace ~/repos --update # only re-document repos whose HEAD moved
openwiki workspace ~/repos --output ~/wiki # write the wiki somewhere else
openwiki workspace ~/repos --only api-service,web-app # limit the run
openwiki workspace ~/repos --model claude-sonnet-4.6 # pick the Copilot model
openwiki workspace ~/repos --language tr # write the wiki in another language
openwiki workspace ~/repos "focus on the public API" # extra guidance for the run
```
A failing repository does not stop the run; it is reported in the summary and the command exits non-zero. Drop an `INSTRUCTIONS.md` in the wiki root to give every repository the same scope and priority brief.
<details>
<summary><b>Requirements and configuration</b></summary>
<br/>
This mode needs the `copilot` CLI on your `PATH` and a GitHub account with Copilot CLI access:
```sh
npm install -g @github/copilot
copilot login
```
Copilot CLI owns its own authentication, so there is no OpenWiki provider or API key to configure for this mode — `openwiki auth` and `OPENWIKI_PROVIDER` are not involved.
On Windows, `copilot` on `PATH` is an npm shim (`copilot.cmd`), and Node cannot start a `.cmd` directly — it reports `EINVAL`. OpenWiki resolves the shim to the real executable inside the npm package by itself, so this normally needs no attention. If it cannot, point the variable below at the executable:
```
%APPDATA%\npm\node_modules\@github\copilot-win32-x64\copilot.exe
```
These variables can also live in `~/.openwiki/.env`, which this mode reads on startup, so they need not be exported in every shell.
| Variable | Purpose |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| `OPENWIKI_COPILOT_CLI_BIN` | Path to the `copilot` executable, when it is not on `PATH` or the one on `PATH` is a shim that cannot be started. |
| `OPENWIKI_COPILOT_TIMEOUT_MS` | Per-repository time budget. Defaults to one hour. |
| `OPENWIKI_COPILOT_GITHUB_MCP` | Set to `1` to keep Copilot's built-in GitHub MCP server enabled. It is disabled by default: documenting local code needs no network tools. |
The wiki this mode produces is an ordinary OpenWiki: the same OKF front matter, the same deterministic index generation, the same Mermaid and link validation, and `openwiki visualize ~/repos/openwiki` explores it like any other.
</details>
## From wiki to technical design document
`openwiki tdd` fills the company's "MVP - Teknik Detay" template for a new
project, grounded in the workspace wiki:
```sh
openwiki tdd ~/repos --jira DNZ-1111
```
The run reads the Jira record when a key is given (`OPENWIKI_JIRA_BASE_URL`
and `OPENWIKI_JIRA_TOKEN` — a profile Personal Access Token, sent as a
Bearer header; both can live in `~/.openwiki/.env`), asks for an optional
brief, then interviews you in the terminal — asking only what the wiki and
the Jira record cannot answer. Every answer is saved immediately, so an
interrupted session resumes where it stopped. The finished document lands in
`<workspace>/tdd/<KEY>/tdd.md` as Markdown ready to paste into Confluence,
with `[Netleştirilecek: …]` marking what still needs a human decision.
Readable Jira attachments (txt, md, csv, PDF, Word) are pulled into the
evidence; unreadable ones (images, Excel) become interview questions instead
of silently disappearing. `--template <file>` substitutes a newer company
template; `--output <file>` copies the document elsewhere.
## Connect your sources
In `personal` mode, OpenWiki ingests knowledge from the tools you already use, synthesizing them into your local wiki. First-run onboarding offers setup for **local git repositories, Notion, Gmail, X/Twitter, Web Search, and Hacker News**.
During an ingestion run, deterministic connector tools write raw data and manifests under `~/.openwiki/connectors/<connector>/raw/`, then source-specific agent runs synthesize the wiki under `~/.openwiki/wiki/`. You can configure the same connector more than once (for example one Web Search source for AI research and another for NBA news); OpenWiki stores them as separate instances like `web-search-1` and `web-search-2`.
```sh
openwiki auth notion # run a local browser OAuth flow for a provider
openwiki ingest all # run every configured source
openwiki ingest web-search # run one connector's sources
```
<details>
<summary><b>Connector details and OAuth</b></summary>
<br/>
- `git-repo` reads configured local repository paths and writes compact manifests.
- `x` uses the X API directly with OAuth user-context credentials for home timeline, user posts, mentions, bookmarks, and list posts.
- `notion` targets the hosted Notion MCP server, so authenticate through Notion OAuth rather than pasting a token.
- `google` uses the Gmail API directly with OAuth user credentials to fetch recent mail.
- `web-search` uses Tavily through LangChain and requires `TAVILY_API_KEY`.
- `hackernews` uses the public Hacker News feed and search APIs, with no credentials required.
`openwiki auth <provider>` runs a local browser OAuth flow, saves returned tokens into `~/.openwiki/.env`, creates connector config when possible, and discovers MCP tools for MCP-backed providers. Slack and Gmail require app client credentials to already be set in that file; Notion uses dynamic client registration for hosted MCP; X uses OAuth 2.0 with PKCE. `openwiki auth configure <provider>` and `openwiki auth tools <provider>` are advanced retry commands.
Connector secrets are referenced by env var name and stored in `~/.openwiki/.env`; connector config files never contain raw secret values.
**Slack OAuth tunnel.** `openwiki ngrok start` starts an ngrok tunnel with a random HTTPS forwarding URL, reads ngrok's local inspection API, appends `/callback`, and saves `OPENWIKI_HTTPS_OAUTH_REDIRECT_URI` automatically. Register the printed callback URL in Slack. With a fixed domain, run `openwiki ngrok start https://<your-ngrok-domain>`.
</details>
### LangSmith connector (code mode)
The connectors above feed a `personal` wiki. The **LangSmith** connector instead enriches a `code` wiki: it pulls recent LangSmith traces (tool calls, outcomes, and latency) for the projects you choose through the official LangSmith SDK, so a repository's docs reflect how its code actually behaves at runtime, not just what the source says.
Configure it during `openwiki --init` in `code` mode. From the source menu, add LangSmith, pick your workspace region (US or EU), and list the projects to document. OpenWiki writes a committed `openwiki/.langsmith.json` that names the workspaces and projects (never the key itself), so every teammate and CI run documents the same set. The API key is read from the environment:
```sh
OPENWIKI_LANGSMITH_API_KEY="<your-langsmith-key>"
```
Locally the setup wizard saves this to `~/.openwiki/.env`. In CI, set it as a repository secret and export it for the run.
> [!NOTE]
> A LangSmith key is workspace- and region-bound. To document projects across more than one workspace, add an entry per workspace, each with its own key named `OPENWIKI_LANGSMITH_API_KEY_2`, `OPENWIKI_LANGSMITH_API_KEY_3`, and so on. The connector only talks to the official US (`api.smith.langchain.com`) and EU (`eu.api.smith.langchain.com`) hosts.
## How it stays yours
Everything OpenWiki writes is plain Markdown you own and version alongside your code.
- **Agents read it as memory.** On each `code` run, OpenWiki maintains an `AGENTS.md` and `CLAUDE.md` at the repo root that point your coding agent at the wiki. It only rewrites its own `<!-- OPENWIKI:START -->…<!-- OPENWIKI:END -->` block and leaves the rest of each file untouched.
- **You set the brief.** Repository-specific instructions live in `openwiki/INSTRUCTIONS.md`, a user-authored file OpenWiki reads for scope and priorities but never rewrites during normal runs.
- **No-op runs are free.** After a run, OpenWiki snapshots the `openwiki/` directory and only records new metadata when something actually changed, so scheduled workflows never churn.
- **Local, private config.** Provider choice, keys, and optional LangSmith tracing are saved to `~/.openwiki/.env` on your machine.
## Open Knowledge Format
OpenWiki emits [Google Open Knowledge Format (OKF) v0.2](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md) bundles in both modes, so your wiki is portable to any OKF-aware tool.
- Every concept document carries YAML front matter with a non-empty `type`; all other standard fields are optional.
- Pages record their last meaningful change as `generated: {by, at}`; the legacy v0.1 `timestamp` field is still tolerated on existing pages.
- The optional v0.2 provenance, trust, and lifecycle families (`sources`, `verified`, `status`, `stale_after`) are validated when present.
- Standard Markdown links between concept documents express their relationships.
- `index.md` and `log.md` are reserved documents rather than concepts. The root index declares `okf_version: "0.2"`.
- Producer-defined extension fields are preserved across updates and migrations.
## Diagrams
OpenWiki embeds **Mermaid** diagrams wherever they make a concept clearer than prose: sequence diagrams for runtime flows, ER diagrams for data models, state diagrams for lifecycles, and flowcharts for control flow. Diagrams are grounded in the inspected source, added where they add signal, and kept in sync on `--update`. No configuration is required.
After each run, OpenWiki validates every `mermaid` fence. A diagram that fails validation is converted in place to a plain `text` fence with a short comment explaining why, so it degrades to readable text instead of a broken block. The next `--update` finds that comment and repairs the diagram, so quality recovers over successive runs.
> [!TIP]
> By default OpenWiki runs a lightweight, zero-dependency check that catches common breakages. For authoritative validation that matches exactly what GitHub renders, install the Mermaid parser wherever you run OpenWiki (for example in your scheduled workflow), and no broken diagram will ship:
>
> ```sh
> npm install mermaid jsdom
> ```
## Model providers
The onboarding default is OpenAI with `gpt-5.6-terra`. Every provider includes preset model options plus support for custom model IDs, and stores its credentials in `~/.openwiki/.env`.
| Provider | Credential |
| ------------------------------------------------------------ | --------------------------------------- |
| **OpenAI** _(default)_ | `OPENAI_API_KEY` |
| **OpenAI (ChatGPT login)** | Browser sign-in, uses your ChatGPT plan |
| **Anthropic** | `ANTHROPIC_API_KEY` |
| **Gemini** (AI Studio) | `GEMINI_API_KEY` |
| **Gemini Enterprise** (Vertex AI) | Google ADC, keyless |
| **AWS Bedrock** | IAM credentials |
| **GitHub Copilot** | GitHub CLI session |
| **OpenRouter** | `OPENROUTER_API_KEY` |
| **Nebius / Fireworks / Baseten / NVIDIA NIM** | Provider API key |
| **OpenAI-compatible** (LiteLLM, Ollama, LM Studio, gateways) | Base URL + key |
<details>
<summary><b>GitHub Copilot</b></summary>
<br/>
The GitHub Copilot provider routes inference through the OpenAI-compatible Copilot API (`https://api.githubcopilot.com`), so teams can reuse an existing Copilot subscription instead of provisioning a separate inference key.
1. Select `GitHub Copilot` during `openwiki --init`. If you have an active [GitHub CLI](https://cli.github.com) session, OpenWiki detects it and offers to reuse it. Otherwise, press <kbd>Tab</kbd> at the credential prompt to run `gh auth login` and sign in.
2. Choose a model (for example `gpt-5.5`).
OpenWiki leaves the token in the GitHub CLI's own credential store. For CI or another headless environment, set `COPILOT_API_KEY` to a GitHub **OAuth token**. Personal Access Tokens are rejected by the Copilot API for third-party integrations. The local config can stay token-free:
```env
OPENWIKI_PROVIDER="copilot"
OPENWIKI_MODEL_ID="gpt-5.5"
```
In CI, set the `COPILOT_API_KEY` repository secret and export `OPENWIKI_PROVIDER=copilot`.
</details>
<details>
<summary><b>AWS Bedrock</b></summary>
<br/>
The `bedrock` provider calls foundation models on AWS Bedrock using IAM credentials rather than a single vendor key:
```bash
OPENWIKI_PROVIDER=bedrock
BEDROCK_AWS_ACCESS_KEY_ID=your-access-key-id
BEDROCK_AWS_SECRET_ACCESS_KEY=your-secret-access-key
BEDROCK_AWS_REGION=us-east-1
OPENWIKI_MODEL_ID=anthropic.claude-sonnet-5
```
When explicit Bedrock credentials are not set, OpenWiki uses the AWS SDK default credential provider chain (OIDC/web identity, IAM roles, AWS profiles, ECS/EC2). The region resolves from `BEDROCK_AWS_REGION`, `AWS_REGION`, or `AWS_DEFAULT_REGION`. Available model IDs depend on which foundation models you have enabled in your account and region, so there is no preset list; paste the Bedrock model ID directly.
Some newer models only accept on-demand invocation through a cross-region inference profile. If you see `ValidationException: Invocation of model ID ... with on-demand throughput isn't supported`, prefix the model ID with the profile's region code, for example `us.anthropic.claude-sonnet-5`. Your IAM policy then also needs `bedrock:InvokeModel` / `InvokeModelWithResponseStream` on both the `foundation-model` and `inference-profile` resource types.
</details>
<details>
<summary><b>Gemini (AI Studio) and Gemini Enterprise (Vertex AI)</b></summary>
<br/>
**Gemini (AI Studio)** runs Google's Gemini models with a single API key:
```bash
OPENWIKI_PROVIDER=gemini
GEMINI_API_KEY=your-ai-studio-key
```
**Gemini Enterprise** runs models from the Gemini Enterprise Model Garden (formerly Vertex AI): Google's Gemini/Gemma, Anthropic's Claude, and partner/open-weight models (Llama, Mistral, DeepSeek, Qwen). It routes each model ID to the right API surface automatically and uses no API key. Authentication happens with Google Application Default Credentials (ADC):
- a service account key file via `GOOGLE_APPLICATION_CREDENTIALS=/path/to/key.json`,
- user credentials from `gcloud auth application-default login`, or
- workload identity when running on Google Cloud or in CI.
```bash
OPENWIKI_PROVIDER=gemini-enterprise
GOOGLE_CLOUD_PROJECT=your-gcp-project
GOOGLE_CLOUD_LOCATION=global # optional, defaults to global
```
Set `OPENWIKI_MODEL_ID` to any Model Garden model. Gemini and Claude ship as presets; partner models are reached by pasting their ID (for example `publishers/meta/models/llama-3.3-70b-instruct-maas`). The credentials need Vertex AI access (`roles/aiplatform.user`), and the models must be enabled in the Model Garden. The `global` endpoint serves Gemini and Claude with the best availability; set `GOOGLE_CLOUD_LOCATION` to a regional endpoint for data residency, and always set it explicitly for region-specific partner (MaaS) models.
For CI, authenticate before the update job runs (for example with [`google-github-actions/auth`](https://github.com/google-github-actions/auth)) and set `OPENWIKI_PROVIDER=gemini-enterprise` and `GOOGLE_CLOUD_PROJECT` in the job environment.
</details>
<details>
<summary><b>OpenAI (ChatGPT login)</b></summary>
<br/>
The `openai-chatgpt` provider calls OpenAI's Codex backend using your ChatGPT subscription instead of a metered API key, drawing on your Plus/Pro/Team plan's included Codex usage. It serves the same model list as the `openai` provider.
```bash
OPENWIKI_PROVIDER=openai-chatgpt openwiki code --init
# or
OPENWIKI_PROVIDER=openai-chatgpt openwiki personal --init
```
The wizard opens `https://auth.openai.com` in your browser (and prints the URL for headless/SSH use). After you sign in, OpenWiki captures the OAuth callback, shows the signed-in email and plan, and continues to model selection. It stores the access token, refresh token, expiry, account id, email, and plan in `~/.openwiki/.env`. These are managed for you and the access token is refreshed automatically, so you normally never edit them by hand. Treat the refresh token like a password.
</details>
<details>
<summary><b>OpenAI-compatible endpoints (LiteLLM, Ollama, LM Studio, gateways)</b></summary>
<br/>
The `openai-compatible` provider targets any OpenAI-compatible chat-completions endpoint via a required base URL. Set the model ID to whatever the endpoint exposes.
```bash
# Hosted gateway (for example Requesty, which fronts many upstream providers)
OPENWIKI_PROVIDER=openai-compatible
OPENAI_COMPATIBLE_API_KEY=your-gateway-key
OPENAI_COMPATIBLE_BASE_URL=https://router.requesty.ai/v1
OPENWIKI_MODEL_ID=openai/gpt-5.5
```
```bash
# Ollama, after `ollama serve` and `ollama pull llama3.2`
OPENWIKI_PROVIDER=openai-compatible
OPENAI_COMPATIBLE_API_KEY=ollama
OPENAI_COMPATIBLE_BASE_URL=http://localhost:11434/v1
OPENWIKI_MODEL_ID=llama3.2
```
```bash
# LM Studio, after starting the local server from the Developer tab
OPENWIKI_PROVIDER=openai-compatible
OPENAI_COMPATIBLE_API_KEY=lm-studio
OPENAI_COMPATIBLE_BASE_URL=http://localhost:1234/v1
OPENWIKI_MODEL_ID=your-loaded-model-id
```
Some local servers ignore the API key value, but OpenWiki still requires `OPENAI_COMPATIBLE_API_KEY` because the client expects one.
**Streaming-only gateways.** Some gateways serve only the streaming transport: a non-streaming request is either rejected outright (`Stream must be set to true`) or answered with HTTP 200 and empty content, which leaves you with a blank wiki and no error. OpenWiki issues non-streaming requests internally, so force the streaming transport for those endpoints:
```bash
OPENWIKI_OPENAI_COMPATIBLE_STREAMING=true
```
It stays off by default because this provider points at arbitrary third-party endpoints, where SSE is not guaranteed to survive proxies and load balancers. Enabling it also makes the client report estimated rather than server-reported token counts.
</details>
<details>
<summary><b>Alternative base URLs, OpenRouter pinning, and retries</b></summary>
<br/>
**Alternative base URLs.** Route a provider at a self-hosted or proxied gateway by setting its base URL alongside its key: `ANTHROPIC_BASE_URL`, `OPENAI_BASE_URL`, `BASETEN_BASE_URL`, `FIREWORKS_BASE_URL`, `NVIDIA_BASE_URL`, or `COPILOT_BASE_URL`. The `openai` provider routes tool calls through the Responses API (`/v1/responses`), which is useful for gateways that expose it.
```bash
OPENWIKI_PROVIDER=anthropic
ANTHROPIC_API_KEY=your-key
ANTHROPIC_BASE_URL=https://your-gateway.example.com/anthropic
```
**OpenRouter provider pinning.** When OpenRouter serves a model through multiple upstreams, restrict routing with a provider or comma-separated allowlist:
```bash
OPENWIKI_PROVIDER=openrouter
OPENROUTER_API_KEY=your-key
OPENWIKI_OPENROUTER_PROVIDER_ONLY=Novita
```
**OpenRouter output-token cap.** By default no `max_tokens` is sent, so OpenRouter's credit pre-check budgets for the model's full advertised output ceiling — on a low credit balance every request can fail with a 402 error. Cap the per-request output explicitly with:
```bash
OPENWIKI_OPENROUTER_MAX_TOKENS=8192
```
A cap trades those hard 402 failures for possible truncation when a long wiki generation genuinely needs more output tokens, so prefer the largest value your balance allows.
**Retry attempts.** OpenWiki uses LangChain's retry handling for transient provider errors. Override the retry count (default 3) with `OPENWIKI_PROVIDER_RETRY_ATTEMPTS=3` (a positive integer).
**Model output token limit.** Set `OPENWIKI_MAX_OUTPUT_TOKENS` (a positive integer) to override the maximum number of tokens generated in a model response, for example `OPENWIKI_MAX_OUTPUT_TOKENS=8192`. If unset, OpenWiki does not override the model client's output token limit. Provider and model limits still apply; unsupported values may be rejected, while very small values can truncate responses or tool calls.
**Bedrock stream idle timeout.** For the Bedrock provider, set `OPENWIKI_STREAM_IDLE_TIMEOUT` to control how long the client waits for the first or next streamed response chunk, for example `OPENWIKI_STREAM_IDLE_TIMEOUT=300000`. The value is milliseconds and must be an integer from `0` to `2147483647`. Set it to `0` to disable the watchdog. If unset, OpenWiki preserves the `@langchain/aws` provider default. Prefer a sufficiently long finite timeout over disabling the watchdog so a stalled stream cannot hang forever.
**Reasoning effort.** Set `OPENWIKI_REASONING_EFFORT` to configure reasoning for a supported provider and model. OpenAI GPT-5.6 models use the Responses API values `none`, `low`, `medium`, `high`, `xhigh`, and `max`. NVIDIA NIM's Nemotron 3 Super supports `none`, `low`, and `high`. In an interactive chat, use `/effort` to choose an available value or `/effort default` to restore the provider default. Leave the variable unset to preserve the provider default; invalid provider, model, or effort combinations fail before a request is sent.
</details>
> [!NOTE]
> If there is an inference provider or model you would like to see added, please open a PR.
## Ignoring paths
Create a `.openwikiignore` file in the repository root to keep generated docs from reading or describing private, generated, or irrelevant paths. The syntax supports comments, blank lines, `*` and `**` globs, directory rules, and `!` negation:
```gitignore
secrets/
*.log
!logs/keep.log
```
When `.openwikiignore` has active rules, OpenWiki filters filesystem discovery and restricts shell execute so ignored paths stay out of the run. This is a read boundary: ignored paths are never read, scanned, or reproduced in the docs. It does not guarantee a topic is never mentioned, since the agent may still infer an ignored area from other allowed evidence such as tests, the README, or commit messages.
## Command reference
```sh
openwiki # interactive chat, code mode, current repo
openwiki personal # interactive chat, personal brain
openwiki "generate docs" # start with an initial request
openwiki -p "what can you do?" # one-shot, print, and exit
openwiki --init # initialize code docs (personal: openwiki personal --init)
openwiki --update # update code docs (personal: openwiki personal --update)
openwiki visualize # interactive graph + live reader
openwiki visualize openwiki --export docs/openwiki-visualizer # static graph + reader
openwiki workspace ~/repos # document a folder of repositories with Copilot CLI
openwiki auth <provider> # authenticate a connector (slack, gmail, x, notion)
openwiki ingest <source> # run connector ingestion (all, or a connector/instance)
openwiki --help # full help
```
In chat, `/api-key` updates the current provider key and `/langsmith-key` updates or clears LangSmith tracing credentials, both with masked prompts.
## Telemetry
This fork sends none.
Upstream OpenWiki reports an anonymous `openwiki_run` event to PostHog. That path is removed here, not merely switched off: the analytics client, the event builders, the install-id file in `~/.openwiki/`, the first-run notice, and the `posthog-node` dependency are all gone, so there is no code left that could send anything and no flag that could turn it back on.
What remains under `src/telemetry/` is the local error taxonomy — the classification that lets the CLI tell you which stage a run failed in and who owns the fix. It never leaves the process.
## Contributing
Contributions are welcome. Please read [CONTRIBUTING.md](./CONTRIBUTING.md) before opening a PR. We intentionally keep PRs tightly scoped to one change each, and PRs that bundle unrelated changes may be closed with a request to split them.
## License
[MIT](./LICENSE)