Performance Optimization Strategies for OpenWork: Session Management and Split-Screen Architecture

OpenWork minimizes memory usage and eliminates redundant network requests by implementing lazy-loaded session read models with automatic idle cleanup, paired with a Zustand store that isolates split-screen pane state to prevent cross-contamination between views.

OpenWork is an open-source AI workbench designed for complex multi-session workflows. The repository different-ai/openwork employs specific performance optimization strategies for OpenWork to maintain responsiveness when users work across multiple contexts simultaneously.

Session Lifecycle and Caching Architecture

OpenWork treats each interaction as a distinct session tied to a unique sessionId. The architecture separates active sessions from idle ones to conserve memory.

Lazy Loading with SessionReadModel

The SessionReadModel loads data only when a session becomes visible. Located in [dev/apps/app/src/react-app/domains/session/read-model.ts](https://github.com/different-ai/openwork/blob/dev/dev/apps/app/src/react-app/domains/session/read-model.ts), this model subscribes to session event streams and caches results in memory only for active panes.

When a user switches to a different session, the model marks the previous session as idle. A background timer monitors idle duration; if a session remains inactive beyond the configured idleTimeoutMs, the read model purges its cached data and notifies the UI to display an unloaded placeholder.

// read-model.ts – fetches data only when the pane becomes visible
export const useSessionReadModel = (sessionId: string) => {
  const [state, setState] = useState<SessionState>("idle");

  useEffect(() => {
    if (state !== "active") {
      // Load data the first time the session appears
      loadSessionData(sessionId).then(() => setState("active"));
    }
    return () => {
      // Mark idle when the pane is hidden
      setState("idle");
    };
  }, [sessionId, state]);

  return { state };
};

Idle Session Cleanup

The cleanup routine runs on navigation events within session-surface.tsx. The workbench-store.ts implements a background interval that clears stale sessions from the global cache:

// workbench-store.ts – timer that clears old sessions
const cleanupIdleSessions = () => {
  const now = Date.now();
  Object.entries(sessionCache).forEach(([id, meta]) => {
    if (meta.lastActive + idleTimeoutMs < now) {
      delete sessionCache[id]; // free memory
    }
  });
};

setInterval(cleanupIdleSessions, idleTimeoutMs);

This pattern ensures long-running client sessions do not accumulate unbounded memory usage.

Split-Screen State Management

OpenWork supports side-by-side session comparison through a split-screen view. Rather than duplicating component trees, the architecture uses a minimal global store to track which session occupies the secondary pane.

The Workbench Store Pattern

The useWorkbenchStore hook in [dev/apps/app/src/react-app/domains/session/chat/workbench-store.ts](https://github.com/different-ai/openwork/blob/dev/dev/apps/app/src/react-app/domains/session/chat/workbench-store.ts) holds only the splitSessionId—the identifier for the secondary pane. This Zustand store prevents duplicate data fetching by checking if a session is already loaded before mounting the secondary view.

When setSplitSessionId is called, the store updates the global state, triggering a re-render of the surface component without reinitializing the primary session's state.

Isolated Pane Rendering

The SessionSurface component in [dev/apps/app/src/react-app/domains/session/surface/session-surface.tsx](https://github.com/different-ai/openwork/blob/dev/dev/apps/app/src/react-app/domains/session/surface/session-surface.tsx) renders each pane with its own sessionId and independent read model. This isolation prevents the two panes from sharing React state such as model pickers or composers, ensuring that updates in one pane do not force re-renders in the other.

// session-surface.tsx – simplified rendering logic
const splitSessionId = useWorkbenchStore(state => state.splitSessionId);
const isSplit = Boolean(splitSessionId && splitSessionId !== selectedSessionId);

return (
  <>
    {/* Primary pane */}
    <SessionPane sessionId={selectedSessionId} />

    {/* Secondary pane – rendered only when a split session is active */}
    {isSplit && <SessionPane sessionId={splitSessionId} className="split-pane" />}
  </>
);

The secondary pane uses lazy mounting—it only enters the React tree when the user explicitly opens a session in split view, keeping initial render costs minimal.

UI Integration for Split Views

The sidebar interface handles user actions for opening and closing split views without creating duplicate tabs.

Opening Sessions in Split View

The context menu in [dev/apps/app/src/react-app/domains/session/sidebar/app-sidebar.tsx](https://github.com/different-ai/openwork/blob/dev/dev/apps/app/src/react-app/domains/session/sidebar/app-sidebar.tsx) provides "Open in split view" functionality. The menu logic checks whether the target session is already the primary or secondary pane before calling setSplitSessionId:

// In the session sidebar menu (app-sidebar.tsx)
const openInSplitView = () => {
  // `sessionId` is the ID of the clicked session
  useWorkbenchStore.getState().setSplitSessionId(sessionId);
};

// Menu item that triggers the above
<DropdownMenuItem data-session-menu-open-split onClick={openInSplitView}>
  {t("session_management.open_in_split_view")}
</DropdownMenuItem>

Preventing Duplicate Sessions

The UI guards against duplicate tabs by comparing the clicked sessionId against both the primary selectedSessionId and the splitSessionId stored in the workbench store. If the session is already visible in either pane, the action focuses that pane rather than creating a new instance.

Server-Side Session Validation

Every request to OpenWork's MCP backend includes a mcp-session-id header. The type definitions in [dev/packages/types/src/openwork-context.ts](https://github.com/different-ai/openwork/blob/dev/dev/packages/types/src/openwork-context.ts) enforce that this identifier is a non-empty string, ensuring the server can validate and isolate state changes per session.

Summary

• Lazy-loaded read models fetch session data only when panes become visible, reducing initial load times.
• Idle session cleanup automatically purges cached data after a configurable timeout, preventing memory leaks during long work sessions.
• Zustand workbench store tracks only the splitSessionId, enabling split-screen views without duplicating component state.
• Isolated pane rendering ensures primary and secondary sessions maintain independent React trees, eliminating cross-pane re-renders.
• Lazy mounting delays the secondary pane's initialization until explicitly requested by the user.

Frequently Asked Questions

How does OpenWork prevent memory leaks when users open many sessions?

OpenWork implements an idle timeout mechanism in the session read model. When a session pane is hidden, the SessionReadModel marks it as idle and starts a timer. If the user does not return to that session within the configured idleTimeoutMs, the model clears the cached data from memory and notifies the UI to show an unloaded placeholder.

Can the same session be opened in both split-screen panes simultaneously?

No. The UI logic in app-sidebar.tsx checks whether a session ID matches either the primary selectedSessionId or the splitSessionId before opening it. If the session is already active in one pane, the interface focuses that pane rather than creating a duplicate view, preventing state synchronization issues.

What triggers the secondary pane to render in split-screen mode?

The SessionSurface component monitors the splitSessionId value in the Zustand workbench store. When setSplitSessionId updates this value (typically via the "Open in split view" menu action), the component evaluates isSplit and conditionally renders a second SessionPane with the new session ID, mounting it lazily to avoid upfront rendering costs.

Why does OpenWork use separate read models for each split-screen pane?

Each pane receives its own sessionId and instantiates an independent SessionReadModel. This architectural decision isolates state changes between panes, ensuring that updates to the model picker, message history, or composer in one pane do not trigger unnecessary re-renders or network requests in the other pane. This separation is critical for maintaining 60fps interactions during heavy multi-tasking workflows.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}