hob

hob is an independent workspace for professional agent work, built for engineering teams that need control. It is aimed at developers who already use agent CLIs such as Claude Code, Codex, or OpenCode as part of real engineering work rather than casual prompting. hob does not provide model access of its own; instead it gives the tools a team already pays for a durable, local-first place to run. Multiple models, terminals, repositories, and parallel agent sessions live inside one workspace, and agents can shape that workspace around each task, coordinate through it, and guide the developer inside it. The stated purpose is to let teams run, review, automate, and recover agent work in the same system, directing more parallel work without piecing together the infrastructure themselves. Agent CLIs are powerful tools, but they were not designed to be a workspace. Running several of them across several repositories turns into a logistics problem: sessions scatter, context is lost when providers change, and returning to work in progress means hunting through terminal windows. Testimonials on the site describe exactly this. One user says they used to run more than six Claude Code instances in a terminal and that coming back to them was a nightmare; another says that with how fast agentic coding changes, staying current used to be a pain. hob answers that gap by separating the model layer from the workspace layer, so the workspace holds parallel sessions, terminals, local history, remote access, and project context across whatever providers a team already pays for. Independence from any single provider is the first pillar of the product. hob works with the inference your team already uses, naming Claude Code, Codex, and OpenCode among the agents it supports. Because subscriptions stay separate from the workspace, switching agent, provider, account, or model is one click, and work no longer lives inside one provider's ecosystem. The workspace runs many models and keeps workflows independent of each other, so a change in one agent does not disturb the others. hob is explicit that it is not a model provider and does not resell tokens: teams bring the agent CLIs, model accounts, API keys, and routing choices they already use, and hob supplies an independent workspace around them. The product describes itself as built from scratch for agent work and always at the frontier of agentic coding, so the work stays consistent and predictable, gets easier, and lets developers do more. Automations are a core part of doing real work in hob. They are used to automate recurring work, such as reviewing and addressing user feedback, and the steps are defined once so that every run does exactly the same thing. That repeatability is the point: a recurring job stops being a manual chore and becomes a defined process that behaves identically each time it runs. Secrets hold the keys an automation needs, and no agent gets them, so no provider does either, meaning credentials stay inside the workspace rather than travelling into a model provider's environment. hob also supports auto-starting anything that needs to stay on while the project is open, so long-running pieces of a workflow come back up with the project. Pull request work happens where the work happens. hob lets you open pull requests, comment on them, and close them, keeping the diff, the conversation, and the change in one place instead of spread across tools. You can run hob pr from an agent, or drive the pull request surface by hand, so the same surface serves automated and manual workflows. Remote issues extend this to the issue tracker: create, comment on, and close issues on GitHub, Gitea, or Forgejo without leaving hob, then hand any of them to an agent to fix. Agent-made issues stay linked to the conversation that produced them, so the reason a change exists does not get lost between the tracker and the agent session. The agent control surface is what makes hob different from a terminal multiplexer. Every agent you run can operate hob itself, not just edit your files, so agents open the files, diffs, and panes you need instead of leaving you to hunt for them. One agent can hand work to another, and both keep running side by side, which supports multi-step jobs where different agents own different parts. An agent can also explain how something works by walking you through the interface, which turns the workspace itself into something an agent can navigate and describe. Together these capabilities make the workspace a shared surface that both the developer and the agents act on, rather than a static container for terminal sessions. Remote access puts the full workspace in a browser and adds a phone companion for steering agents on the move. It drives your actual desktop session rather than a copy of it, so what you see remotely is the same workspace you left. Traffic runs through an encrypted relay and hob never opens a port to the public internet. Worktrees handle isolation on the local side: agents can be given separate worktrees when their tasks need isolation, the main tree stays clean, and parallel edits stay out of each other's way. When the work lands you can keep the branch; when it does not, you throw the worktree away. Together, remote access and worktrees let a developer supervise and separate many concurrent streams of agent work. Privacy is described as a matter of architecture rather than policy. hob runs locally and stores agent conversations in a local database on your device. Regular hob service traffic is limited to read-only checks such as app updates and model-list updates, and agent work travels between you and whatever agent provider you already use, such as Anthropic or OpenAI; hob describes itself as the interface, not the middleman. Pro+'s remote access uses a managed relay at roam.hob.dev, where frames are end-to-end encrypted by hob on top of WebSocket TLS before entering the relay, which forwards encrypted frames only and does not hold the plaintext needed to read workspace or session data. The stated consequence is simple: the hob team cannot read your panes, agent sessions, files, or history. Overall, hob works by taking the infrastructure concerns of agent work and putting them into one local application. You download hob for Linux or request a demo, point it at the agent CLIs, model accounts, and API keys you already use, and the workspace becomes the place where sessions, terminals, history, automations, pull requests, and issues are managed. Agents are not boxed into the workspace passively; they are given the ability to operate it, coordinate with each other, and guide you through it. Because the workspace layer is independent of the provider layer, swapping a model or an account does not require rebuilding a workflow. The same system is used to run work, review it, automate it, and recover it, which is what the product means when it says the tools the job needs are already there. The promised outcomes are control, continuity, and portability. Control comes from keeping subscriptions, provider choices, and credentials separate from the workspace, so a provider change is one click rather than a migration. Continuity comes from local history and persistent workspaces: users describe being able to shut a laptop and return to every workspace exactly where they left it, ready to resume, instead of rebuilding context. Portability comes from the local database, which stays on the machine and remains accessible regardless of subscription status, so if you cancel, your conversations, workspaces, and history remain yours. Reviewability comes from having diffs, conversations, and changes in one place, and recoverability comes from worktrees that can be kept or discarded depending on whether the work landed. Several concrete workflows are described on the site. Teams automate recurring work such as reviewing and addressing user feedback, defining the steps once so each run is identical. Developers open, comment on, and close pull requests from inside hob, or run hob pr from an agent, keeping the diff and its discussion together. Issues on GitHub, Gitea, or Forgejo are created, discussed, and closed inside hob, then handed to an agent to fix while staying linked to the conversation that produced them. Parallel agent work is isolated using worktrees so the main tree stays clean. Developers steer agents from a phone or a browser through encrypted remote access, and can ask an agent to walk them through the interface when they need to understand how something works. The vendor also notes when hob is not worth it: if you only use AI coding tools occasionally or mostly chat with one model in one app, the organizational benefits do not apply. hob's stated audience is developers who already use agent CLIs as part of real engineering work, not casual prompting, specifically people who run Claude Code, Codex, OpenCode, terminals, multiple repos, or parallel agent sessions daily. Integrations mentioned in the content include Claude Code, Codex, and OpenCode for agents; GitHub, Gitea, and Forgejo for remote issues; and the inference providers a team already uses, with Anthropic and OpenAI given as examples of where agent work goes. The Linux build is distributed directly, and a demo can be requested. The content references a plan called Pro+, whose remote access uses the managed relay at roam.hob.dev, and notes that subscription status does not affect access to local data. hob does not include Claude, Codex, or model access and does not resell tokens. In short, hob is an independent, local-first workspace that gathers the tools of professional agent work, models, sessions, automations, pull requests, issues, remote access, and isolation, into one place. It leaves model access and routing with the providers a team already pays for, and keeps the workspace itself under the team's control.