Fixes#350 (API server fails to start on Windows because numpy has no cp314 wheels).
Caps `requires-python` to `>=3.10,<3.14` in pyproject.toml so uv resolves a Python that has working numpy wheels on Windows. Extends the `test-windows` CI matrix to run on both Python 3.12 and 3.13 to keep the cap honest.
Reported by @RizaldyMongi in #350. Thanks for the careful repro — the Windows-only fallout was tricky to reproduce on Linux/macOS and the issue gave us the exact symptom signature to triage from.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
A 27B local model (Qwen3.5-27B via vLLM) passed a 7-task coding suite cleanly
(create/edit/bug-fix/implement-to-pass-tests/multi-file, verified by running
code + pytest); an 8B model was unreliable. Document so users pick a capable
model for real coding work.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds an `OpenCodeAgent` (registry key `opencode`) that delegates coding tasks
to opencode (https://opencode.ai, MIT) while keeping inference local-first:
OpenJarvis's engine backs opencode via an OpenAI-compatible provider.
How it works:
- Derives an OpenAI-compatible base URL from the engine (e.g. Ollama/vLLM at
`<host>/v1`) and writes an `opencode.json` registering it as an
`@ai-sdk/openai-compatible` provider (`openjarvis/<model>`).
- Spawns a headless `opencode serve` (loopback, random port), waits for
`/global/health`, then drives a session: `POST /session` →
`POST /session/{id}/message` with `model={providerID,modelID}` + agent
(`build`/`plan`) → parses message `parts` (text → content, tool → tool_results)
into an `AgentResult`. `close()` disposes the server.
- opencode is an external binary (not bundled); `run()` returns a clear,
actionable error when it's missing, mirroring ClaudeCodeAgent's degradation.
Verified end-to-end against the real opencode binary wired to a stub
OpenAI-compatible engine: opencode called the local endpoint and the agent
parsed the response (content/finish/model) correctly. Unit tests cover part
parsing, base-URL derivation, provider-config writing (incl. merge), binary
detection, graceful degradation, and run() parsing with a mocked client — 15
passed, ruff clean. Registered via the standard try/except import in
agents/__init__.py; documented in docs/user-guide/agents.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
All three deployment methods bound 0.0.0.0:8000 with no API key, so following
the README produced a server reachable from any device on the network with no
auth. `check_bind_safety` already refuses to start a non-loopback bind without
a key (so these configs actually failed to start) — this wires the key in so
the documented path yields a *working, authenticated* server.
- docker-compose.yml: require `OPENJARVIS_API_KEY` via `${VAR:?...}` so
`docker compose up` fails fast when unset; added `deploy/docker/.env.example`
(un-ignored in .gitignore).
- systemd: add `EnvironmentFile=/etc/openjarvis/env` (no `-` prefix, so a
missing key file blocks startup rather than exposing an open server).
- launchd: bind `127.0.0.1` by default (the personal-device default — no
network exposure, no key needed) with a documented, commented opt-in to
0.0.0.0 + `OPENJARVIS_API_KEY`. Avoids shipping a usable default credential.
- Docs (docker/systemd/launchd) updated with the key-setup step.
- Tests assert each config can't reintroduce an open server, plus
`check_bind_safety` behavior across loopback/public × key/no-key.
Closes#221
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The installed desktop app polls `desktop-latest/latest.json`. Previously
every push to `main` (autotag -> v*.devN -> desktop.yml dispatch) rebuilt
and republished `desktop-latest` as a DEV prerelease, so stable users were
auto-updated onto unvetted dev builds, and any manual stable mirror was
clobbered on the next merge.
Split the streams so the app's channel only ever serves vetted stable:
- Dev/rolling builds (v* autotag + manual workflow_dispatch) now publish to
a new `desktop-edge` pre-release. The shipped app does not poll edge, so
dev builds never auto-install onto stable users.
- Stable `desktop-v*` builds publish the user-facing release as before, then
a new `refresh-stable-channel` job copies that release's signed
`latest.json` into `desktop-latest` (mirror; URLs already point at the
desktop-v* assets). Cut a `desktop-v*` tag to ship an update.
- `clean-release` now targets `desktop-edge`; `desktop-latest` is never
wiped by CI.
No app/tauri.conf.json change — the updater endpoint stays `desktop-latest`.
Doc updated to describe the now-implemented stable/edge split.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Every desktop download link in the docs was broken on two counts:
1. They pointed at the rolling `desktop-latest` prerelease, which had
been removed (404 for all of README, docs/index.md,
docs/downloads.md, docs/getting-started/installation.md).
2. They used the wrong version in the filenames (`OpenJarvis_0.1.0_*`)
— the actual published assets were never `0.1.0`.
Repointed all four files at the new stable `Desktop desktop-v1.0.2`
release with the exact asset filenames it ships
(`OpenJarvis_1.0.1_*` — the Tauri bundle version is 1.0.1, distinct
from the 1.0.2 Python/CLI release). This release also includes a
macOS universal `.dmg`, which the prior desktop releases lacked
(addresses #356 "No Mac Download") — so the macOS rows now say
"Universal" (Apple Silicon + Intel) instead of "Apple Silicon".
All five download URLs verified live (HTTP 200) against the
desktop-v1.0.2 release before committing.
Note: `docs/desktop-auto-update.md` still references the
`desktop-latest` rolling channel — that's the auto-updater's endpoint,
a separate concern from the manual download links, and is left as-is.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The documented install command pointed at `https://openjarvis.ai/install.sh`,
but that domain is community-operated (not controlled by this project) and
its TLS config broke — every new user hit `sslv3 alert handshake failure`
(#337, #352). Since we can't fix a domain we don't control, this moves the
installer onto infrastructure we DO control: the project's GitHub Pages
docs site.
Changes:
- **`docs/gen_install_script.py`** (new) + **`mkdocs.yml`**: a `gen-files`
hook copies `scripts/install/install.sh` verbatim into the built site at
`install.sh` on every `mkdocs build`. Single source of truth — the script
stays at `scripts/install/install.sh` (still bundled into the wheel as
`_install_scripts/`); the published copy can't drift. Verified locally:
`mkdocs build` emits `site/install.sh` byte-identical to the source.
New canonical URL: `https://open-jarvis.github.io/OpenJarvis/install.sh`
— HTTPS always valid (GitHub's cert), fully under project control.
- **`README.md`**: canonical command switched to the github.io URL for
both the Installation and Quick Start blocks. Also addresses the uv
discoverability gap — explicitly states the curl installer downloads uv
for you (no prerequisite), and that the Windows **desktop .exe** expects
uv to be installed first, with the exact PowerShell command.
- **`docs/getting-started/{install,wsl2,macos,linux}.md`**: canonical URL
switched to github.io. `install.md` gains an "Install URL" info note
explaining the github.io URL is canonical and that the older
`openjarvis.ai` URL is community-operated with intermittent TLS issues.
- **`scripts/install/install.sh`** + **`jarvis-wrapper.sh`**: usage comment,
the WSL re-run hint (added in #399), and the wrapper's re-install message
all updated to the github.io URL.
Migration note for maintainers: ask whoever operates `openjarvis.ai` to
CNAME it to `open-jarvis.github.io`. Once they do, `openjarvis.ai/install.sh`
will serve this same GitHub Pages content with a valid GitHub-managed cert,
and the nicer brand URL can become canonical again with zero further code
changes. Until then, the github.io URL works and is under our control.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Addresses #337 (also reported as #352).
`curl -fsSL https://openjarvis.ai/install.sh | bash` — the documented
one-liner — currently fails with:
curl: (35) ... sslv3 alert handshake failure
Reproduced from this machine just now; @kumanday and @filactre both
report the same against different OpenSSL and LibreSSL versions. The
underlying SSL issue is on the openjarvis.ai server (cert / TLS
config) and needs an operational fix at the infra layer — not
something a code change in this repo can resolve.
What this commit *can* do is unblock users immediately:
- `README.md` (under "Installation"): callout pointing at issue #337
and the GitHub-mirror fallback.
- `docs/getting-started/install.md`: same callout as a
Material-for-MkDocs `!!! warning` admonition.
Both link to the canonical script at
`https://raw.githubusercontent.com/open-jarvis/OpenJarvis/main/scripts/install/install.sh`.
The script is identical content — it's the same `scripts/install/install.sh`
served from GitHub's CDN instead of openjarvis.ai. Once the
installer runs, it pulls everything else (`uv` from astral.sh, the
project source from `github.com/open-jarvis/OpenJarvis.git`, Ollama
from `ollama.com`) — none of which depend on `openjarvis.ai`. So
the rest of install proceeds normally.
When the openjarvis.ai SSL issue is fixed at the server / DNS layer,
both callouts can be removed and the canonical URL becomes the only
documented path again.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* feat(mining): add Pearl model conversion workflow
* test(mining): tolerate missing Docker device request type
* docs(mining): record Gemma and Qwen conversion evidence
* docs(mining): record Qwen local validation evidence
---------
Co-authored-by: krypticmouse <herumbshandilya123@gmail.com>
Reported via twitter (issue #269): the macOS install guide and other
docs recommend a 4B model on CPU but the README and quickstart pull /
ask a much larger model (qwen3:8b) — confusing and slow for first-time
CPU-only users.
Switch the README quickstart and the docs/getting-started/quickstart.md
'Chat with Any Model' tile to qwen3.5:4b, with an inline note that GPU
users can scale up to qwen3.5:9b or larger. This matches the existing
chat-simple preset and the macOS guide's CPU recommendation.
Closes#269
The project had two overlapping directories: desktop/ (Tauri Rust backend +
stale React components) and frontend/ (real React app + dead Tauri stub).
This consolidates everything under frontend/:
- Move desktop/src-tauri/ → frontend/src-tauri/ (the real 1,720-line Rust
backend with Ollama sidecar, backend lifecycle, cloud keys, overlay, etc.)
- Preserve 9 old desktop React components in frontend/src/components/Desktop/
(excluded from TS build — APIs have drifted, kept for future integration)
- Delete the old frontend/src-tauri/ stub (246 lines, never compiled)
- Delete desktop/ entirely
- Fix tauri.conf.json frontendDist path (../../frontend/dist → ../dist)
- Update CI workflow, bump script, .gitignore, and docs paths
- Rename setup/ → Setup/ for consistent PascalCase component directories
Update all human-readable strings (docstrings, comments, descriptions,
log messages, TOML config descriptions) to correctly say
"DeepResearchBench" instead of "LiveResearchBench" for the
deep_research_bench benchmark. Class names and file paths are
unchanged for backward compatibility.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Move download/clone/star badges from docs/index.md to README.md
- Use TRAFFIC_TOKEN secret instead of GITHUB_TOKEN for Traffic API
(requires admin-level access that GITHUB_TOKEN doesn't provide)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
openjarvis was already taken on PyPI, so the package is registered as
OpenJarvisAI. Update pyproject.toml and docs badges to match.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Four new docs matching the morning-digest.md pattern:
- deep-research.md — multi-hop research with document indexing
- code-assistant.md — orchestrator with code execution + file I/O
- scheduled-monitor.md — persistent operative on cron schedule
- chat-simple.md — lightweight chat, simplest setup
Updated quickstart with tabs for all agent types and expanded
starter configs table from 3 to 7 presets. Updated MkDocs nav
and index page to link all 5 user guides.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
README now shows a table of example configs with copy commands, plus
a full list of built-in agents (morning_digest, deep_research,
monitor_operative, orchestrator, etc.) with descriptions.
Quickstart page adds a "Morning Digest" tab and Starter Configs
table with links to example config files.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Link morning-digest.md in the User Guide nav section. Also add
all existing user-guide pages that were missing from the nav.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
These were force-added previously but are already in .gitignore.
Files remain on disk but are no longer tracked in git.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Full morning digest system:
- MorningDigestAgent, DigestStore, digest_collect tool, TTS backends
- Connectors: Oura, Strava, Spotify, Google Tasks, Apple Health, Apple Music
- CLI `jarvis digest` command + FastAPI /api/digest endpoints
- Cartesia, Kokoro, OpenAI TTS backends with persona prompts
Unified OAuth setup across all surfaces:
- Generic OAuthProvider registry for Google, Strava, Spotify
- CLI auto-opens browser + catches callback (no more paste-code)
- Server /oauth/start + /oauth/callback endpoints for desktop/browser
- Frontend OAuthPanel with popup + polling
Apple connectors:
- Apple Health reads from HealthKit DB or iPhone export XML
- Apple Music queries Music.app via AppleScript
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix(evals): add tool_choice=auto + fix traces thread safety
Two fixes for eval accuracy and stability:
1. TauBench agent: add tool_choice="auto" to match tau2's native
LLMAgent behavior. Without this, Qwen and GPT-5.4 score 10-14pp
below leaderboard because the models don't receive explicit
tool-calling guidance.
2. SystemBuilder: apply self._traces flag to config.traces.enabled.
Previously builder.traces(False) was a no-op — traces stayed
enabled, creating SQLite connections in the main thread that
crashed when accessed from ThreadPoolExecutor worker threads
in GAIA evals ("SQLite objects created in a thread can only be
used in that same thread").
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* feat: enrich inference events with model response content and add Trace.messages
Add content, tool_calls, and finish_reason fields to INFERENCE_END events
published by InstrumentedEngine. For non-instrumented engines, BaseAgent._generate()
now publishes INFERENCE_START/END events with the same rich data. Add _message_to_dict
helper and messages field to Trace dataclass for full conversation capture.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* feat: enhance TraceCollector with rich content, tool details, and messages
Capture model response content, tool_calls, and finish_reason in GENERATE
steps; store tool arguments and result text in TOOL_CALL steps; extract
conversation messages from AgentResult.metadata into Trace.messages; and
implement the last_trace property. Also adds a messages column to the
TraceStore schema so messages survive the SQLite round-trip.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* feat: agents store conversation messages in AgentResult.metadata
Both NativeReActAgent and MonitorOperativeAgent now serialize their
internal messages list via _message_to_dict and include it in the
returned AgentResult.metadata under the "messages" key. This enables
TraceCollector to capture full conversation traces.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* feat: wire TraceCollector into system._run_agent and JarvisAgentBackend
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* feat: persist rich trace data in eval trace JSONL files
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* feat: add TerminalBench config for Qwen 3.5-122B
* fix: add SQLite migration for traces.messages column on existing databases
* fix: check trace_store instead of shared config for trace enablement
* feat(evals): add ToolCall-15, LiveCodeBench, LiveResearchBench + telemetry
Three new benchmark integrations and full telemetry wiring for the
NeurIPS 2026 IPW/IPJ experiments.
## New Benchmarks
### ToolCall-15
15-scenario tool calling accuracy benchmark across 5 categories.
All scenarios defined inline with deterministic scoring (0/1/2 per
scenario). Fast to run (~5min/model) — ideal for optimization loops.
### LiveCodeBench
Competitive programming from LeetCode/AtCoder/CodeForces via
HuggingFace dataset. Sandboxed code execution with per-test
timeouts. Single-turn generation via jarvis-direct backend.
### LiveResearchBench
100 expert-curated deep research tasks. LLM-as-judge scoring
across 4 dimensions (comprehensiveness, insight, instruction
following, readability). Uses web_search tool for live research.
## Telemetry Wiring
- FLOPs estimation: 2 * active_params * total_tokens (MoE-aware)
- Energy/power capture flows from InstrumentedEngine through
backends to EvalResult and RunSummary
- New telemetry_summary section in output JSON with IPW/IPJ
- JarvisDirectBackend now propagates gpu_metrics flag
- TauBench forwards telemetry flags to SystemBuilder
## Experiment Plan
Added docs/experiments/neurips-2026-plan.md tracking the full
experiment matrix: 9 models x 7 benchmarks across NVIDIA, AMD,
and Apple hardware stacks.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Jon Saad-Falcon <jonsaadfalcon@gmail.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Closes#158 — the README and installation docs assumed uv was already
installed without explaining how to get it, creating a barrier for new
users (especially on macOS). Adds a prerequisites table to both the
README and docs/getting-started/installation.md with platform-specific
install commands, and links to the existing macOS step-by-step guide.
- Skip SetupWizard on launch, go straight to Chat page
- Add Data Sources page with sidebar nav (separate tabs for data sources + messaging channels)
- Add "Connect your data" banner + quick-action buttons on Chat empty state
- Add hint on deep research agent pointing to Data Sources + Messaging tabs
- Consistent naming: "Data Sources" and "Messaging Channels" everywhere
- Fix Apple Notes / iMessage setup (remove broken system prefs link)
- Fix Slack data source: auto-join public channels, rate limit retry, is_member filter
- Add channels:join scope to all Slack manifests + docs
- Fix Gmail: use gmail_imap connector (IMAP + app password), increase limit to 5000
- Fix sync endpoint: run in background thread, return immediately
- Show sync progress with progress bar, error messages, Sync Now / Re-sync / Retry buttons
- Add triggerSync() API + SyncStatusDisplay component
- Rewrite all connector setup instructions with precise click-by-click steps
- Notion: share all pages at once via top-level page sharing
- Obsidian: show how to find vault path via Obsidian UI or Finder
- SendBlue: add link to API Credentials page, add ngrok webhook step
- Slack messaging: add Copy button for JSON manifest
- Add OpenJarvis Slack icon asset
- Shorten deep research template description
- Fix desktop app port (8222 → 8000 to match server default)
- Disable auto-updater for local dev builds
- Register Slack, Outlook, GCalendar connectors in __init__.py
- Auto-create default agent when setting up messaging channels
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Roadmap: updated messaging status (iMessage/SMS + Slack working,
WhatsApp Baileys blocked, Meta Cloud API planned).
Testing plan: 12 query types across 3 platforms (Interact, Slack,
iMessage/SMS) with execution phases and success criteria.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Added SendBlue (iMessage/SMS) and Slack messaging setup with detailed
step-by-step instructions, App Manifest JSON, webhook registration,
and troubleshooting tables. Reorganized doc into two sections:
Messaging Channels (talk to agent) and Data Connectors (search data).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Register sendblue in channels/__init__.py so ChannelRegistry works
- Auto-restore SendBlue bindings on server startup from database,
re-creating ChannelBridge + DeepResearchAgent so webhooks survive
server restarts
- Add sendblue to CLI channel_cmd.py (_get_channel, help text) and
SystemBuilder._resolve_channel() for config.toml support
- Health check endpoint GET /v1/channels/sendblue/health returns
channel_connected, bridge_wired, ready status
- Frontend: SendBlueWizard checks health on mount, shows
"Disconnected" badge with "Reconnect" button when bridge is dead
- Docs: CLI usage, server restart behavior, ngrok re-registration,
troubleshooting table, health check endpoint
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
