OpenMake01 / Process
How these notes are made
After code lands, we reconstruct the story from its commit, diff, tests, and runtime evidence. The result becomes a durable technical document for users and contributors.
OpenMake Engineering Log
Build notes backed by code and tests
Not a changelog echo. Each entry explains the problem, the design decisions, the implementation boundary, the evidence, and the trade-offs behind a shipped OpenMake change.
02 / Team
Team identity and project roles
OpenMake Team is the community identity; openmake_llm is the software project; OpenMake is the product name. Non-developer maker riskpw leads openmake_llm through vibe coding, and professional developer rocky supports its development.
Engineering deep dive
Latest entry
Six months serving vLLM on a DGX Spark: what one memory pool teaches you
A Mac mini runs the app, a DGX Spark runs the models, and one 127.5 GB pool holds everything on the far side. Here is where that went wrong over six months — a model swap that stayed invisible because an alias was doing its job, a fan-out that met real rate limits, and a bottleneck that turned out not to be memory at all.
Read the engineering note
There was nothing you could do after it failed
1.23.0 is not a release that added features. It is the release that decided what a user and an operator can each do when the answer is wrong, the task is dead, or the records have vanished entirely.
Read the engineering note
All four times, the tests were green
The four deep dives written so far have something in common. Something we believed was in place was not, and what told us was never the test suite — it was production.
Read the engineering note
Connecting the plan to the execution, in three increments
The roadmap names the Execution Graph as the next step. Rather than building it in one pass, we split it into three increments that measure first and fix second. The first measurement came back at 45%, and the cause was not the code.
Read the engineering noteUploading beyond the proxy limit without bypassing the proxy
How OpenMake changed large agent-task attachments from one oversized request into an authenticated, resumable-by-chunk protocol while preserving the existing task file contract.
Read the engineering note
We built isolation, and in production it did nothing
We shipped OS-level isolation for external MCP servers in a day, then deleted it the next morning. The tool we had chosen turned out to quietly do nothing on the host we actually run on.
Read the engineering noteWe swapped the inference backend in a day, then spent thirteen paying the bill
The code was tied to one server's dialect. A compatible signature let us move 100-plus call sites in a single day and delete 4,500 lines, but clearing what that compatibility layer left behind took another thirteen.
Read the engineering note2026 / W04–W37
Weekly development archive
W18 (April 27 – May 3) is missing from this list because there were no commits that week. An empty week is left out rather than written up.
Weekly development log 2026‑W37: Compare models, then route work by capability
W37 moved from guarding individual model settings to making model choice and multimodal execution visible. Compare mode put two answers side by side; Agent Tasks exposed parallel progress; and the model layer became a Planner-led capability path for text, image, vision, audio, video, and web work. From September 7 through 13, main added 86 commits and produced 35 tagged releases from 1.48.0 through 1.62.3.
Read the engineering note
Weekly development log 2026‑W36: Read Korean government documents, fit the new local model, close the security review, launch Bench
From August 31 through September 6, GitHub main added 95 commits. On Thursday, in a separate repository, OpenMake Bench was built and put up at bench.openmake.cc: a measurement tool that runs the same prompts across models and routes under identical conditions, and benchmarks your own models through chat account SSO. The previous week's leftovers, 1.35.0 and 1.35.1, were cut in the small hours of Monday, and nineteen releases followed, 1.36.0 through 1.47.0. Three threads overlapped. HWP, HWPX, and HML documents, which the app accepted but could not read, are now extracted, and that work exposed a context-overflow error presented as a transient failure and a token underestimation, both fixed alongside. The local default model changed to qwen3.8-27b, local models are now discovered from the gateway instead of a static catalog, and the sampling defaults, reasoning preservation, and image-count issues found while checking the new model were handled in sequence. On the external side, hasa and B.AI arrived as BYOK providers, Discussion and Deep Research gained per-provider concurrency and 429 backoff so a free key's per-minute limit no longer collapses them, and the three-step reasoning-effort control is actually forwarded to external models. In between, three high, one medium, and many low findings from an apps/api security review were closed over two days, the routing golden set grew to 150 cases and routing accuracy went from 77.5% to 100%, and a nightly real-model evaluation was put on the operations Mac. From Thursday evening to Saturday midnight, work of a different character followed. Six Deep Research consistency defects were closed at once, the language drift that answered Korean questions in English was caught on two fronts, and the same Instrument design tokens were laid down across web, iOS, and Bench. The socket problem that lost the in-flight response when a tab was switched was fixed with stream detach/resume, and in the prompt-trimming work the first post-deployment measurement reversed the design twice in a row. On the site, a Simplified Chinese locale went up, making four languages. Sunday, the last day, had a character of its own. It began by closing memory defects an external review had flagged, cut four releases in a single day (1.45.0 through 1.45.3), and closed with agent-task coding work grounded in 30 days of production measurement plus a code-navigation tool that runs without an approval prompt (1.46.0 and 1.47.0).
Read the engineering note
Weekly development log 2026‑W35: Make agent work resumable, shareable, and inspectable
From August 24 to 30, GitHub main added 81 commits and three releases: 1.33.0, 1.33.1, and 1.34.0. After the previous week's feature run, the work moved toward making agent work recoverable and legible: local tasks can be resumed, inspected, and shared as read-only work; a shared artifact viewer keeps published output on an isolated origin; and read-only tools can run in parallel within one turn. Later in the week tool failure gained a denominator, and a circuit that cuts off repeatedly failing external tools was put in place with the gate off by default. The same pass tightened the extension and MCP boundaries, removed mock-only administrator surfaces, stopped expired sessions from polling forever, and moved task workspaces and logs out of ephemeral /tmp onto a persistent path.
Read the engineering note
Weekly development log 2026‑W34: From the phone screen to the CLI on your own machine
One hundred and fifteen commits shipped nine releases this week, 1.26.0 through 1.32.1. Answer rendering was rebuilt for phone screens and the phone gained maps, location, and a camera, while OpenMake Code opened a path for running tools on the user's own machine and closed it out with an audit trail and a single bridge core. The desktop moved its centre of gravity: the Electron shell was frozen and a SwiftUI native companion took over. On the last day the direction turned once more, from trusting written configuration to trusting the model itself - capability and context length are measured at boot, reasoning effort became a user choice, answer verification arrived, and every LLM call was routed through a single LiteLLM path. In parallel, quietly leaking boundaries - skill injection, SSRF, API key scopes - were tightened and unused code and the GitHub integration were removed.
Read the engineering note
Weekly development log 2026‑W33: From Extensions to iOS: Expanding OpenMake into a Unified Platform
This week (44 commits) surfaced extension bundles, the marketplace, and workspace sharing into the product, consolidated OpenAPI contracts as the single source of truth, and opened the first work on iOS authentication and a SwiftUI MVP. At the same time we strengthened large-repo skill installation and hardened boundaries around citations, OAuth, and session recovery to raise scalability and reliability.
Read the engineering note
Weekly development log 2026‑W32: Complete running scanned PDF OCR in production
This week we tightened orchestration reliability and frontend/backend feature consistency, implemented chunked upload for large attachments that exceed Cloudflare request limits, and completed an analysis path that handles scanned PDFs with no text layer. Small documents fall back to multi-page native OCR; large documents are split so a sandbox targets only the necessary pages for OCR. We then retroactively analyzed 20 failed Agent Tasks and added exponential-backoff retries for transient LLM errors and a demotion that removes approval-required tools when approval responses time out repeatedly, allowing completion with the available information. These changes, along with integrating Agent Tasks into history, were released as 1.21.0.
Read the engineering note
Weekly development log 2026‑W31: Clarified provider, Desktop, and inference gateway architecture
In the last week of July we focused on structure rather than feature additions. We reviewed provider contracts, the Desktop boundary, MCP, operations, and LiteLLM·vLLM topologies to ensure orchestration control remains with OpenMake.
Read the engineering note
Weekly development log 2026‑W30: Connect Agent Task to GitHub and External Authentication
At the end of July we connected autonomous tasks to real projects and authentication boundaries. We worked in parallel on Agent Task’s Git capabilities, OAuth, a comprehensive source audit, Cloudflare migration, release documentation, and desktop recovery.
Read the engineering note
Weekly development log 2026‑W29: Measuring model roles, Discord, routing, and self-learning
We added a new gateway and stronger chat behavior while explicitly changing model assignments. Work progressed on Discord, provider roles, execution plans, routing measurement, and self-learning evaluation, balancing the associated trade-offs.
Read the engineering note
Weekly development log 2026‑W28: Parallel work on MCP catalog, Agent design, and a comprehensive audit
In the second week of July we advanced implementation and deep review in parallel. We worked on the MCP catalog, Agent task design, self-learning measurement, a frontend audit, and an interactive log tool, documenting both achievements and remaining failures.
Read the engineering note
Weekly development log 2026‑W27: Transitioning the June runtime into July operations
As we moved into July, we wrapped up work on web execution, artifacts, and Agent Task items, then returned to real chat and authentication behavior. From this period, Claude session records with precise project paths began to reappear.
Read the engineering note
Weekly development log 2026‑W26: Unifying Sandbox, Artifacts, MCP, and Web Execution
In the busiest week of June we expanded execution scope beyond simple conversation. We tied task sandboxes, browser and web paths, artifacts, attachments, MCP, and chat orchestration together into a single runtime.
Read the engineering note
Weekly development log 2026‑W25: Elevating Security and Observability Alongside Features
As features increased, we strengthened guardrails. We improved security fixes, API key controls, in-depth research, caching, design consistency, and usage visibility.
Read the engineering note
Weekly development log 2026‑W24: Connecting Deep Research, Evaluation, and Rich Chat
Search and answer quality were the focus. We connected deep research, evaluation hooks, prompts, chat behaviors, artifacts, and agent tasks into a grounded answers pipeline.
Read the engineering note
Weekly development log 2026‑W23: Making Agent Tasks an Independent Workflow
In the first week of June we elevated Agent Tasks from a simple chat mode to an independent feature. We added task execution, management, and routing, and redesigned the UI to provide a dedicated surface for long-running autonomous work.
Read the engineering note
Weekly development log 2026‑W22: Shifting Artifacts and Routing to the Core of the Product
At the end of May we focused on artifacts, chat routing, sockets, and structural cleanup. We clarified the lifecycle of generated outputs and narrowed the gap between model decisions and the user-facing screens.
Read the engineering note
Weekly development log 2026‑W21: Turning MCP and skills into a platform
This was the week with the most commits during the audit period. We connected individual features into a manageable platform through MCP collection, skill creation, agent collection, the model catalog, navigation, and GDPR-related work.
Read the engineering note
Weekly development log 2026‑W20: Reassessing the new foundation
In the week following large provider and UI work, we focused on review and cleanup. We reduced the risks introduced by the prior volume of changes through reviews of security and configuration assumptions and by refactoring LLM integration code.
Read the engineering note
Weekly development log 2026‑W19: Rebuilding Providers, Models, and Interfaces
Development velocity increased significantly in early May. We revamped provider integrations, model selection, brand presentation, and the main chat screen to connect the matured backend to a product users can understand.
Read the engineering note
Weekly development log 2026‑W17: Wrapping up the April stabilization cycle
In the final active week of April, we closed storage fixes and addressed small feature gaps. All changes were recorded based on Git to avoid inventing an unverifiable AI collaboration narrative when no matching Claude session existed.
Read the engineering note
Weekly development log 2026‑W16: Strengthening CSP, CSRF, Storage, and Security Headers
Security requirements were translated into concrete implementations. We strengthened the Content Security Policy (CSP), WebSocket settings, CSRF defenses, storage rules, and response headers across public-facing and authentication screens.
Read the engineering note
Weekly development log 2026‑W15: Refining Infrastructure and Operations Documentation
Even during a period when no matching local Claude Code session could be found, development in Git continued. The repository contains changes to infrastructure, configuration, and operations documents, so this weekly entry is compiled solely from the Git record.
Read the engineering note
Weekly development log 2026‑W14: Maintenance week: organizing between major changes
We intentionally operated at a smaller scale during the transition from March to April. We整理ed prior stabilization efforts through documentation, configuration, and maintenance work, preparing for the next infrastructure phase.
Read the engineering note
Weekly development log 2026‑W13: Strip legacy paths and simplify the core
Advanced agent and routing behavior while removing outdated abstractions. By eliminating the legacy A2A route, we made the remaining execution model easier to understand and operate.
Read the engineering note
Weekly development log 2026‑W12: Focused week to harden the product end-to-end
One of the busiest weeks in March, with broad fixes and refactoring across the codebase. Defects related to API keys, memory, agents, RAG, MCP, and user-facing screens were handled as a single reliability-improvement effort.
Read the engineering note
Weekly development log 2026‑W11: Stabilizing Providers and Branches
Focused on relatively small-scale bug fixes, provider behavior, and integrating parallel branches. It was a week spent maintaining platform consistency in a fast-changing environment rather than delivering notable new features.
Read the engineering note
Weekly development log 2026‑W10: Connecting Search, Rendering, and Feature Control
In early March we focused on operating rich answers reliably. We reviewed and stabilized Firecrawl, cache, MCP and AI feature toggles, ES module cleanup, Mermaid, and KaTeX.
Read the engineering note
Weekly development log 2026‑W09: Expanding the surfaces of skills, memory, and tools
OpenMake has begun moving beyond basic chat. We added skills, memory, schemas, upload security, MCP controls, and deeper tests to build components of a scalable AI workspace.
Read the engineering note
Weekly development log 2026‑W08: Polished authentication, sessions, and server reliability
Focused on the boundaries users encounter first — login, anonymous sessions, route behavior, and server reliability. Through refactoring and bug fixes, we began turning initial features into a platform that can withstand everyday use.
Read the engineering note
Weekly development log 2026‑W07: Documenting and Stabilizing the Platform Foundations
In the second week of February, we expanded the initial platform and overhauled project documentation to prepare for faster iterative development. The focus was on foundational work that makes the system understandable before broadening functionality.
Read the engineering note
Weekly development log 2026‑W06: OpenMake LLM Appears in Git History
On February 3, the first commit for OpenMake LLM 1.5.0 was recorded. The design explorations from January have become a milestone in the codebase that anyone can revisit.
Read the engineering note
Weekly development log 2026‑W05: Moving the investigation into actual routing implementation
In the final week of January we moved beyond structural analysis into concrete implementation sessions to resolve router collisions. Provider flows and responsibility boundaries were clarified, but the public repository history had not yet begun.
Read the engineering note
Weekly development log 2026‑W04: Mapping the Product Before the First Commit
January's entry starts not with repository milestones but with preliminary research. We reviewed existing OpenMake screens, deployment assumptions, and routing conflicts to define the system boundaries that must be understood before actual implementation.
Read the engineering note