Repository navigation
Merge 2.0.0-GA branch back to main - #14
Merged
Merged
Conversation
Synced from locallmlab-sdk. The example made its own MCPServerManager next to LocalLMLab's. It now adds Deepwiki to lab.mcp, enables the tools it uses (a new server's tools start disabled; read_wiki_contents stays off) and calls lab.makeSession(route:instructions:includeMCPTools: true). Same tools offered, now tagged as MCP for policy and records. README: the diff table against repo-qa, and the verified-live transcript (Deepwiki's tool is now ask_wiki_question). Package.swift: header comment only. Builds against 1.0.0-RC.1; verified live with Qwen3-8B (facebook/react). Co-Authored-By: Claude <noreply@anthropic.com>
Synced from locallmlab-sdk. AIQL made its own MCPServerManager and wrapped the server's tools with FileBackedTool.mcp. It now adds the server to lab.mcp, enables its top 4 data tools, sets lab.mcp.setFileBackedOutput(MCPFileBackedOutput(root:...), server:) for the run's folder, and lets makeSession(includeMCPTools: true) offer them with saveAs. Servers from an earlier Go are disconnected so their tools don't reach the model. setFileBackedOutput is new in 2.0, so Package.swift defaults to 2.0.0-dev (new knownSDKReleases entry; checksums from the release's .sha256 files). Kept 1.0.0-RC.1 as the previous release, dropped 1.0.0-beta.4. README mirrored. swift build and xcodebuild (AIQL.xcodeproj) succeed against v2.0.0-dev. Not run end to end. Co-Authored-By: Claude <noreply@anthropic.com>
Brings in the 1.0.0-GA branch's release commits (GA checksum cascade, GA docs, CHANGELOG) that 1.1.0-dev was cut before. Conflict in examples/aiql/Package.swift: kept defaultSDKVersion 2.0.0-dev (AIQL needs setFileBackedOutput); knownSDKReleases is now 1.0.0-GA (previous) + 2.0.0-dev, RC.1 dropped. GA checksums match the v1.0.0-GA release's .sha256 files. Co-Authored-By: Claude <noreply@anthropic.com>
…rotocol parts) - docs/migrating-to-2.0.md: what breaks (per-server tool authorization with the 1.0 -> 2.0 mappings, two new MCP enum cases, MCPServerState decoding), what behaves differently (sessions follow lab.mcp, trusted servers ask only before destructive tools, app-only tools hidden, widget answers remembered), the one-declaration APIs, and what's new (chat-app pieces, MCP Apps / MCPAppsHost, per-server trust). - CHANGELOG: 2.0.0 (unreleased) entry with the same structure. - MCP protocol 2026-07-28 items are left as marked placeholders for the MCP protocol session to fill. Co-Authored-By: Claude <noreply@anthropic.com>
… and CHANGELOG sdk-guide §3a/§3c and the §12 MCP reference still described a 2025-11-25 ceiling and a handshake-only connection mode. Documents stateless mode, server/discover negotiation (MCPVersionNegotiation via MCPSettings), MRTR, live updates (MCPLiveUpdates, listen(filter:)), the dropped 2024-11-05 support, and the new diagnostics lines.
- sdk-guide.md: new §3f "MCP Apps: showing a server's interactive views" (declaring support, rendering with LocalLMLabSDKMCPAppsHost, a view's calls through the session's authorizer, the live-view pool and re-creation, what a view may do); new §6a subsection "Building a chat app" (hostTranscript, streamResponse, replyInProgress, turnContext, reopening a conversation); makeSession text for 2.0 (one function, tools follow lab.mcp, restoring:, mcpAppHints:, languageModelSession as the escape hatch); lab.mcp + MCPSettings as the one MCP manager. - §12 reference: Configuration(mcp:), MCPSettings, makeSession, LocalLMLabSession (turnContext, hostTranscript, respond/streamResponse, callMCPTool, updateModelContext), HostTranscript, ToolCallRecord, MCP Apps fields on MCP types, MCPClientHandlers.extensions, and a new "MCP Apps (LocalLMLabSDKMCPAppsHost)" block. - migrating-to-2.0.md links to the new sections. Co-Authored-By: Claude <noreply@anthropic.com>
…ssion 2.0 (docs/21 #7): a turn run on languageModelSession skips the context-overflow retry, the per-turn MCP tool refresh and the host transcript. session.events progress is unchanged. Verified live: AIQL's pipeline code, run headless against econ-index.mcp.claude.com with Qwen3-8B ("every country and its usage index, highest first, top 10"): the data tool saved 129 KB to raw/data.json via saveAs, loadTable + one sqlQuery wrote the right top-10 out.csv, and the file-backed setting was cleared after the run. Co-Authored-By: Claude <noreply@anthropic.com>
§7c lever 2 rewritten for 2.0: ConfirmingToolAuthorizer(channel:policy:hostTools:timeout:), per-server trust / approval on lab.mcp (settings table), ToolPolicy, fail-closed rules, live reads, persistence after restore, cross-process approvals. §12: PendingToolCall / Summary with initiator + serverApproval, ToolCallInitiator, MCPServerTrust, ToolApproval, ToolApprover, ToolPolicy, ToolPolicyDecision; RuleBasedToolAuthorizer and Requirement removed; MCPServerManager setTrust / setToolApproval / toolApproval(server:); MCPServerState trust fields. §11 / Components: the picker's trust and approval row and notices. Co-Authored-By: Claude <noreply@anthropic.com>
Synced the example's sources and README from the SDK repo: Todoist's approval is set on lab.mcp (setToolApproval: nil = ask, .allow = don't), Calendar's is the authorizer's hostTools, and the authorizer is ConfirmingToolAuthorizer(channel:hostTools:) — the 1.x requirement closure is gone. annotated-examples.md re-quotes DemoPolicy and run() from the migrated code and updates the tally. Package.swift is unchanged (still defaults to the 1.0.0-GA binaries, like Components/Package.swift). Co-Authored-By: Claude <noreply@anthropic.com>
…val (2.0) From locallmlab-sdk: a radio-group auth picker, per-server Trust and "Before a tool runs" approval controls, and notices when none of a server's tools are on or a trusted server's tools changed. Comment citing a private doc scrubbed. Builds against 2.0.0-dev; 39 tests pass. Co-Authored-By: Claude <noreply@anthropic.com>
…geModelSession 2.0: the escape hatch skips the context-overflow retry and the per-turn MCP tool refresh. Same answer text; README diff row updated. Co-Authored-By: Claude <noreply@anthropic.com>
knownSDKReleases in Components and the 12 other SDK examples (aiql was already done) is now 1.0.0-GA (previous) + 2.0.0-dev; defaultSDKVersion = "2.0.0-dev"; 1.0.0-RC.1 dropped. Each module's checksum is from the v2.0.0-dev release's .sha256 (Core ae20766f, Inference 014bcbf3, Remote 88f8145f, Claude 5986c09b). examples/README.md: this branch builds against 2.0.0-dev, and its knownSDKReleases / .sha256 samples. Built: Components, components-demo, components-updates-demo and every SDK example with swift build (clean .build: an incremental build keeps objects from the 1.0.0-GA interface and fails to link), VistaNova with xcodebuild. Co-Authored-By: Claude <noreply@anthropic.com>
From locallmlab-sdk: `ui://` widget metadata and resource loading, MCPAppsBridge (the widget<->host JSON-RPC state machine, with policy and audit sink), the sandboxed MCPAppViewController / MCPAppView, MCPAppsSessionBackend (a widget's calls through the LocalLMLabSession), and the widget lifecycle (MCPAppWidgetCache, MCPAppViewPool, MCPAppRecreation). Tests included. Package.swift rewritten for the public tree: Core comes from ../Components (which declares the binary target and re-vends it), so no checksum of its own. Comments citing private design docs, phases and prototype IDs scrubbed. Builds against 2.0.0-dev; 85 tests pass (same as the SDK repo). Co-Authored-By: Claude <noreply@anthropic.com>
Synced from locallmlab-sdk: Sources, packaging, README. A tool call whose tool links an MCP App shows the server's widget inline; the widget's own calls go through the session, so they meet the same per-server trust / approval as the model's. Qwen3-8B via MLX by default. Package.swift rewritten for the public tree: Core + Components from ../../Components, MCPAppsHost from ../../MCPAppsHost (both source), and its own Inference binaryTarget with the usual SDKRelease / knownSDKReleases / failManifest gate. Only 2.0.0-dev is known: the app does not build against 1.0. Three comments naming private-only examples or docs scrubbed. Verified: swift build against v2.0.0-dev; packaging/build-and-sign.sh (ad hoc, debug) embeds and signs both frameworks and the app launches. Also: README.md lists MCPAppsHost and mcp-chat; examples/README.md adds mcp-chat to the catalog and the "what each example needs" table; security-demo README (mirrored) links the SDK guide's 7c instead of a private doc, so check-public-hygiene.sh is clean. Co-Authored-By: Claude <noreply@anthropic.com>
Adds an examples/mcp-chat section to annotated-examples.md: ChatModel.swift, WidgetSlot.swift and MCPChatApp.swift in full, the SDK-facing views of ChatViews.swift (plain SwiftUI elided), every SDK line marked. New marker `// ← SDK (MCPAppsHost)` for the MCP Apps package; legend, size table and intro updated. Tally: 139 marked lines (86 SDK, 39 MCPAppsHost, 4 Inference, 10 Components). Co-Authored-By: Claude <noreply@anthropic.com>
…e in §6 - api-surface.md regenerated from the v2.0.0-dev release xcframeworks (was still 1.0.0-GA): 2.0 folds, per-server trust/approval, chat-host and MCP Apps APIs, MCP 2026-07-28; MCPAppsHost listed like Components. - sdk-guide.md §6: an app that uses LocalLMLab uses lab.mcp, not its own MCPServerManager. Co-Authored-By: Claude <noreply@anthropic.com>
…ource Checked every MCP-using example's annotated code against its current source (code only; markers, comments, joined lines and elisions ignored). - repo-qa-local, aiql: re-quoted from the 2.0 source — the server goes into lab.mcp and makeSession(includeMCPTools: true) offers its tools (aiql: setFileBackedOutput instead of wrapping with FileBackedTool.mcp); turns run on session.respond. Prose, tallies and size-table rows rewritten (repo-qa-local 96/129, aiql 402/459). - plate-today: the error path uses GenerationErrorDescription (tally 18). - code-buddy: Ctrl-C watch moved into startSigintWatch(_:), `default:` over SessionEvent, current git/test tool descriptions. Unchanged and already current: repo-qa, plate-today-tools, components-demo, workspace-buddy-local, security-demo, vistanova, mcp-chat (their remaining differences are deliberate line-joins, shortened prompts and excerpt ordering). Co-Authored-By: Claude <noreply@anthropic.com>
- code-buddy, workspace-buddy-local, mlx-control-room (synced from the SDK repo, fb3424c): stream with session.streamResponse, which yields the reply so far as a String, instead of languageModelSession — the escape hatch that skips the SDK's turn handling. - vistanova (this repo's copy): the plain-text search turn and the summary turn use session.respond. The guided-generation search turn (respond(to:generating:)) stays on languageModelSession — there is no SDK turn method for guided generation — with a comment saying so. - annotated-examples.md updated to match. Built against the published v2.0.0-dev binaries: code-buddy, workspace-buddy-local, mlx-control-room (swift build, clean) and vistanova (xcodebuild — its manifest only vends the binaries, so swift build never compiled the app). code-buddy run live on Qwen3-8B. Co-Authored-By: Claude <noreply@anthropic.com>
…pe hatch - sdk-guide.md §6a: new subsection "Running a turn, and when to use languageModelSession": a table of what a turn gets each way (tool approval / records / events work both ways; message at turn start, replyInProgress, turnContext, widget context, MCP tool refresh, overflow retry, on-device sampling, citations, cancel() only via respond/streamResponse), when the escape hatch is right (guided generation, reading the raw transcript, other Apple APIs), and what changes coming from Apple's methods (String results, error wrapping). - A short mention with a link where each affected feature is covered: makeSession (tool refresh + run-every-turn paragraph), sampling, "Building a chat app" (transcript, turnContext), events (.contextCompacted / .serverToolCall), RetryPolicy (1.x "wrappers" wording replaced), web-search citations, §3f widget context, capabilityProbe (.guidedGeneration), §12 languageModelSession. - migrating-to-2.0.md links the table. Co-Authored-By: Claude <noreply@anthropic.com>
… Claude) All four 2.0.0-dev xcframeworks were rebuilt and re-uploaded on 2026-10-03 02:42–02:47 UTC (Core now carries the MCP MRTR Cancel/Decline fix and the MCP.mrtr log category). The pins from 8d5b7d7 no longer match the assets, so a fresh SwiftPM resolve would fail on checksum. Values are the release assets' SHA-256 digests.
XcodeGen spec (project.yml) and the generated, committed MCPChat.xcodeproj so the example opens in Xcode and Runs. Sandboxed with network.client, automatic signing, mcpchat: OAuth URL scheme. Package.swift vends LocalLMLabSDKInference as a library product for the project to depend on. README gains an "Open in Xcode and Run" section. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CHANGELOG 2.0: defaulted maxModelCallsPerTurn parameters (breaking, shape); real MLX usage, the 16-call tool-loop stop and up-front prompt refusals (behavior); new "Added - local (MLX) models" (MLXUsageMetadataKey, MLXPrefillMonitor, maxModelCallsPerTurn); new "Fixed" (contextBudget). migrating-to-2.0.md: the same behavior changes under "What behaves differently", including how to raise the call limit, and usage/prefill reporting under "What's new". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SwiftPM stores each cached artifact as a zip file named after its URL, but the script only removed directories, so it reported "(nothing cached)" and a rebuild kept failing on the old checksum after a republish. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… Claude) All four 2.0.0-dev xcframeworks were rebuilt and re-uploaded on 2026-10-04 02:22–02:26 UTC (Core and Inference now carry the decision API: question sets, answer sets, lab.evaluate, DecisionCalibration, OpenJevDecisionProvider(mlx:tunedWith:)). Values are the release assets' SHA-256 digests; Components and the 14 examples pinning them build against them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Write noul / choice / score questions, run them on a local MLX model (OpenJevDecisionProvider) and on hosted Jev (TypeSafe via OpenRouter, Featherless) side by side, score a batch against marked answers, fit calibration, append runs to a results CSV, import/export answer sets, and export the tested questions for an app (DecisionQuestionSet). GUIDE.md is a plain-English developer's guide to building with decision models. Package.swift declares Core, Remote and Inference binary targets for SDK 2.0.0-dev. Verified: release build, --check on Qwen3-4B-4bit and --check-remote on the Featherless demo. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
XcodeGen project.yml + generated JevDK.xcodeproj: ad-hoc signed, not sandboxed, so it shares the Hugging Face cache and Keychain keys with the swift build binary. Package.swift vends the three SDK binaries as library products for it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
--check-remote read API keys from ./.env. JevDK no longer reads any key file: keys come from the Keychain (saved in Backends) or, for CI, OPENROUTER_API_KEY / FEATHERLESS_API_KEY. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The docs said how to fit a calibration but not clearly how it reaches an app. Now each says: fit it in JevDK, then either Export Questions (the .decisions.json carries it, and OpenJevDecisionProvider(mlx:tunedWith:) applies it) or Copy code (the three values plus the system instructions they were fitted with, for init(mlx:wrapper:calibration:)). No fitting code in the app; refit and re-export when the model or instructions change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A marked screenshot of JevDK's Calibrate sheet: the Temperature column of the Fitted table (X yes/no, Y choice, Z score; a kind with no questions stays 1.0) and the same values in the Copy code snippet. Code examples use X, Y, Z placeholders to match. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The X/Y/Z screenshot now has a "where to find them" line (in JevDK: Batch, mark answers, Calibrate…, Fit calibration) and a caption that names the window and its two parts, for readers who haven't used JevDK. "Calibrate sheet" is now "Calibrate window" throughout. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The "calibrate in JevDK, use it in your app" text assumed readers knew JevDK and the SDK. It now leads with what a calibration is (three numbers that tone a local decider's confidence down or up, one per kind of question, worked out once in JevDK), then how to get them, then two plain options: let them travel with the exported questions file, or paste Copy code's code. API names follow as a footnote, not as the explanation. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A decider sees only the input and the questions, so routing that depends on knowledge about the app (which component a bug is in, who owns it) needs a pattern. Best first: classify the component and map component -> team in code; put the knowledge in the option descriptions; send the app's own context with the input as JSON; retrieve the relevant part first for large knowledge. Not in the local-only system instructions. In the JevDK guide (with code), jev.html (plain English) and SDK guide §6c (short). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- File → Export Server Config… (For your app) writes or updates a jev-serve config (JevServeConfig in OpenJevKit): listen address, optional token (offered when the file is new), and this question set's model, version, system instructions and calibration as one entry; other entries are kept. Written readable only by the user. - A green confirmation after Export Questions / Export Server Config names the model, the version it's pinned to, and whether it's calibrated. - The model's version (Hugging Face commit, short) shows in Models, the model tooltip, the status bar and the Calibrate window; an out-of-date calibration names both versions. - README Files section: five kinds of file; a note on model versions. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… Mac jev-serve takes OpenRouter's /api/alpha/decisions and Featherless's /v1/classifier requests and answers them with OpenJev on a local MLX model, from the config JevDK exports (File → Export Server Config…): each model pinned to its tested version (downloaded if missing), its system instructions and calibration, an optional token. Loopback by default; inputs never logged. JevServeKit is a library with tests that run without a GPU; --self-check verifies live. The SDK binaries come from ../jevdk's products. Needs an SDK release with JevWire. Docs: examples README, README, CHANGELOG, SDK guide §6c, the SDK skill, JevDK's README and guide. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… Claude); API surface All four 2.0.0-dev xcframeworks were rebuilt and re-uploaded on 2026-10-05 13:22–13:25 UTC (Core now has JevWire; Remote's JevDecisionProvider uses it). Values are the release assets' SHA-256 digests. Components and all 16 examples build against them, including jev-serve (13 tests pass; --self-check passes live on Qwen3-4B-4bit). api-surface.md regenerated from those binaries (interfaces byte-identical to the release assets): JevWire, and the Workspace / FileBackedTool changes from a733ab8. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…n either repo - jev-serve/scripts/release_macos.sh: builds against the published SDK binaries, stages the binary with LocalLMLabSDKCore/Inference frameworks, NOTICE and a README, signs inside-out with the hardened runtime, smoke-tests, zips (no AppleDouble entries) and notarizes; .sha256 alongside. - jev-serve --version (stamped by the release script; "dev" from source). - jevdk/scripts/release_macos.sh: the SDK NOTICE is one level up in ancientcomputing/jevdk, two in locallm; it looked only two up. - jev-serve logging is a @sendable function value (no concurrency warning). - JevDK README: the SDK-version link reads right in both repos. scripts/sync-jevdk-repo.sh: copies examples/jevdk and examples/jev-serve into a clone of ancientcomputing/jevdk (unchanged), refreshes NOTICE, builds both and runs jev-serve's tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A jev-serve zip downloaded in a browser fails Gatekeeper: its loose frameworks are quarantined and can't carry a notarization ticket, so macOS refuses to load them. The DMG script now builds jev-serve from ../jev-serve and embeds it at JevDK.app/Contents/MacOS/jev-serve, using the app's frameworks (rpath @executable_path/../Frameworks), signed with the app and covered by its stapled ticket. A new app-menu item links it into /usr/local/bin (administrator prompt), with a copy-the-command fallback and a move-to-Applications check. Docs: jev-serve comes with JevDK. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- jevdk: 2,819 / 3,080 lines, 15 files. Excerpts regenerated from the current source (two had drifted): model versions in the model list, Export Questions with its confirmation, Export Server Config, Open reading an exported set; intro covers MLXModelProvider's versions and the app carrying jev-serve. Tally 21 Core, 9 Inference, 8 Remote. - jev-serve (new): 591 / 640 lines, 4 files, 13 tests. Excerpts: the decision route (JevWire decode, limits, decideWithDiagnostics, encode) and the Decider protocol from Service.swift; model readiness (pinned MLXModelProvider, availability, validate, download) and the providers from main.swift. Tally 16 Core, 15 Inference. - Summary table rows for both; jev-serve in the legend. Every excerpt checked as an exact contiguous copy of the source. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ith it Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… to change it) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…MG show it The icon is drawn in code and was only set on the running app's Dock tile. The release script now runs JevDK --write-iconset, makes AppIcon.icns with iconutil and sets CFBundleIconFile, before signing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
knownSDKReleases in Components and the 15 SDK examples is now 1.0.0-GA (previous) + 2.0.0-GA; defaultSDKVersion = "2.0.0-GA"; 2.0.0-dev dropped (jevdk and mcp-chat list 2.0.0-GA only). Each module's checksum is from the v2.0.0-GA release's .sha256, verified against the downloaded zips (Core faa92a02, Inference fde8babb, Remote d54f02c9, Claude 7afe7d79). "Requires SDK 2.0.0-dev or later" comments (jevdk, mcp-chat, aiql, MCPAppsHost) and the examples READMEs now say 2.0.0-GA; examples/README.md's knownSDKReleases / .sha256 samples too. Built: Components, MCPAppsHost and every example with swift build (fresh scratch path), VistaNova with xcodebuild. check-public-hygiene passes. Co-Authored-By: Claude <noreply@anthropic.com>
README's DMG link and toolkit/README's latest download, verify and unzip steps -> v2.0.0-GA assets (were 1.0.0-GA). migrating-to-2.0 section 2: knownSDKReleases entry, tag and LOCALLM_SDK_VERSION are 2.0.0-GA (2.0.0 is not a known version in the manifests). Co-Authored-By: Claude <noreply@anthropic.com>
api-surface.md synced from locallmlab-sdk, regenerated from the published v2.0.0-GA xcframeworks (surface unchanged since 2026-10-05; only the version line differs). tested-models: the 2026-10-03 decider run was on a 2.0.0-dev pre-release build and has not been re-run on 2.0.0-GA. Co-Authored-By: Claude <noreply@anthropic.com>
Fixed: a streamed .anthropicMessages turn crashed the process (usage update sent input 0; FoundationModels traps when a streamed turn's input goes down). Checksums: Core, Claude, Inference from the v2.0.0-GA release; Remote pending its re-publish with the fix. Co-Authored-By: Claude <noreply@anthropic.com>
All four v2.0.0-GA xcframeworks were re-published on 2026-10-08 (Remote with the Anthropic streaming fix; Core, Claude, Inference rebuilt with it). Each checksum is from the release's .sha256, verified against the downloaded zip: Core 246bad16, Claude e1c50ad8, Inference 60d3f367, Remote 901198d2. 25 pins in Components and the 15 SDK examples; examples/README.md's samples; CHANGELOG 2.0.0 checksum table (Remote filled in) and heading note the re-publish; api-surface version line (surface unchanged). Built: Components, MCPAppsHost and every example with swift build (fresh scratch path, after scripts/flush-sdk-cache.sh), VistaNova with xcodebuild. Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
Measured with a headless copy of the pipeline (fixed loadTable): 3/3, 4 calls, ~37 s, following every step and keeping every requested column; the 14B default 10/10, 3 calls, 14 s. 15 GB of weights clears the 70% preflight on a 24 GB Mac. Co-Authored-By: Claude <noreply@anthropic.com>
All four v2.0.0-GA xcframeworks re-published on 2026-10-09; Core carries the loadTable recordsAt fallback. Checksums from the release's .sha256, verified against the downloaded zips: Core 5f9418a6, Claude f235480f, Inference d2ed4a02, Remote 1e809cff. 25 pins in Components and the 15 SDK examples; examples/README.md samples; CHANGELOG checksum table and heading; api-surface version line (surface unchanged). Built: Components, MCPAppsHost and every example with swift build (fresh scratch path, after scripts/flush-sdk-cache.sh), VistaNova with xcodebuild. AIQL's walkthrough on the published Core + Inference (headless copy of its pipeline, Qwen3-14B-4bit): 3/3, 3 model calls, 14 s. Co-Authored-By: Claude <noreply@anthropic.com>
…t on swift run README's "Getting the SDK" said the example tracks and builds against 1.0.0-RC.1; it builds against Components' default, 2.0.0-GA. Launched with swift run there's no app bundle, so the window could open behind the terminal; the app now claims regular-app status and activates at launch (same as mlx-control-room), and the README says so instead of "click it". Co-Authored-By: Claude <noreply@anthropic.com>
The Add model id box wants the provider's API id, not its display name; OpenRouter's is vendor/model (openai/gpt-6.1-sol, not "GPT-6.1 Sol" or gpt-6.1-sol) and is copied from the model's page on openrouter.ai. A table of format, example and where to find it per provider; Test connection checks each id. Co-Authored-By: Claude <noreply@anthropic.com>
…r access The WorkspaceAccess passage called the tools "FoundationModels Tools", which read as if Apple ships them; they're Core's, conforming to FoundationModels' Tool protocol. It also said WorkspaceAccess owns the security-scoped-bookmark bracket; the app does (picker, bookmark, startAccessingSecurityScopedResource — §8), and WorkspaceAccess keeps each read and write inside that folder. Examples line: workspace-buddy-local added, and which tools each example offers. Co-Authored-By: Claude <noreply@anthropic.com>
…ation first Python and Swift: localai-cli always uses the AI Models choice, from LocalLM Lab's own app-config.json, even with a different --config file, and ignores a request's "model" (verified: "model": "system" still answered on the app's MLX model); every response's "model" says which one answered. Setup step 2 leads with this repo's releases (1.0.0-GA on); locallm-releases and toolkit/ are listed as the places for older versions. Co-Authored-By: Claude <noreply@anthropic.com>
What the file is, in two sentences; the markers as a table (marker, what it marks, which examples use it — Path A included); why they're comments; and plate-today / plate-today-tools / repo-qa as "two ways to give the model tools". Same facts, shorter paragraphs. Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge 2.0.0-GA branch back to main for the 2.0.0-GA release.