DEV Community: CodeKing

"I Added a /yolo Button to My Local AI Assistant"

CodeKing — Mon, 15 Jun 2026 09:32:38 +0000

I like local AI assistants that ask before they do risky things.

I do not like approving the same task six times in a row.

That was the failure mode I kept hitting while working on CliGate. A normal task would start with one reasonable command, then another, then another, and every tiny step wanted a fresh confirmation.

So I added a blunt but useful switch:

/yolo

It sounds reckless, but the real goal was the opposite: make the assistant feel faster without training me to click through meaningless approval spam.

The bad version of safety was too chatty

The old loop looked safe on paper:

assistant picks a mutating tool
-> asks for confirmation
-> user approves
-> one tool runs
-> assistant continues
-> next tiny tool asks again

That is technically correct.

It is also miserable in practice.

A real task is rarely one tool call. Reading a document, checking a project, or sending a result through a channel usually means several small steps in a row. If every step interrupts the user, the approval system stops communicating risk and starts communicating friction.

That is when safety UI turns into background noise.

/yolo made the approval scope match the user's intent

The fix was not "remove approvals." It was "remember what the user actually meant."

In CliGate, /yolo flips a conversation-level flag:

later mutating tool calls in the same conversation auto-approve
the assistant stops asking for every tiny follow-up step
the user can turn strict mode back on with /safe

Under the hood, the flag lives on the conversation metadata as assistantCore.autoApproveTools, and both web chat and channel conversations read the same source of truth.

That detail mattered because I did not want one behavior in the web UI and a different one in DingTalk or Feishu.

Natural language mattered as much as the slash command

The more interesting part is that users do not always type /yolo.

They say things like:

"后续都同意"
"不要再问我了"
"直接执行"
"from now on, just do it"

So I added sticky-approval phrase detection too.

That means the assistant can recognize conversation-wide consent from normal language, not only from a command. But it still treats denial phrases separately, so "我不同意" does not accidentally enable auto-approve just because it contains the word "同意".

This turned out to be one of those small pieces of product logic that matters more than the model prompt.

I still kept a real high-risk boundary

The trap with a feature named /yolo is obvious: if everything gets auto-approved, then safety is fake.

So I kept one hard rule.

Routine local work can flow through auto-approve mode, but genuinely destructive or external actions still need a fresh explicit confirmation.

That means things like:

deleting files or directories
overwriting data in a destructive way
publishing outward
sending messages to other people or other conversations
submitting forms

still stop and ask.

That boundary is what makes the mode usable. The assistant can stop being noisy about low-level execution steps while still pausing when the consequence is actually irreversible or external.

One confirmation can now cover a whole batch

I also found a second bug while fixing this.

Sometimes one pending confirmation represented multiple queued tool calls. Historically, approving it only executed the first one, which silently dropped the rest.

The confirmation service now expands a pending action into all captured tool invocations and runs each of them in order. One approve means the whole batch gets executed, not just item one.

That sounds like an implementation detail, but it changes user trust a lot. If the UI says "confirmed," users expect the intended action to finish, not partially disappear.

The result feels less magical and more honest

My favorite part of this change is that it did not make the assistant feel more autonomous.

It made it feel more aligned.

The assistant now behaves closer to how a human collaborator would interpret the conversation:

if I said "just continue," it continues
if I said /yolo, it stops nagging me for every tiny step
if the next move is truly risky, it still pauses
if I want strict mode back, /safe restores it immediately

That balance is what I want from a local control plane: not maximum freedom, not maximum ceremony, just the right amount of friction in the right place.

CliGate is the open-source local control plane I use to route Claude Code, Codex CLI, channels, desktop control, and assistant workflows through one place: CliGate.

If you are building local agents, where do you draw the line between approval memory and real safety boundaries?

I Added WeChat to My Claude Code and Codex Workflow

CodeKing — Thu, 11 Jun 2026 07:47:14 +0000

The awkward part of local AI tooling is that "local" usually means "only useful while I am sitting at the keyboard."

That is fine when I am deep in an editor. It is less fine when Claude Code is waiting for approval, Codex finished a task, or I just want to ask "what happened?" from my phone.

I already had browser chat and a few external channels wired into CliGate. But for my daily workflow, one missing channel was obvious: WeChat.

The problem was not another bot

Adding a chat provider is easy if all you want is text in and text out.

That was not the workflow I wanted.

The useful version needs to preserve the shape of an AI coding task:

start a Codex or Claude Code run
keep follow-up messages attached to the same task
surface approvals when the runtime asks for permission
send progress and final results back to the user
remember whether the conversation is a new task, a status check, or a continuation

Without that, a WeChat integration would just become another notification pipe. Nice to demo, not very useful under pressure.

The painful case is familiar: a local agent starts doing real work, hits one approval prompt, and then silently waits in a terminal you are not looking at. The problem is not that the model cannot reason. The problem is that the control loop is trapped in the wrong place.

The fix was to treat channels as task surfaces

In CliGate, I ended up treating WeChat the same way I treat Telegram, Feishu, and DingTalk: not as separate products, but as surfaces over the same local task system.

The runtime is still local. Claude Code and Codex still run on my machine. The proxy, account routing, logs, approvals, and task records still live on localhost.

The channel only changes where I talk to the workflow.

That distinction matters. It means the WeChat provider does not need to know how to run Codex. It needs to know how to receive a message, map a user to a conversation, and hand that message to the same supervisor layer that the web chat uses.

The mental model looks like this:

WeChat message
-> channel gateway
-> supervisor conversation
-> Codex or Claude Code runtime
-> progress / approval / result
-> WeChat reply

The interesting part is the middle. A message like "status?" should not be forwarded to Codex as a random new prompt. It should be answered from the remembered task state. A message like "also update the docs" should usually continue the current task, not start from scratch with the default provider.

That task memory is what makes a channel feel like a real interface instead of a webhook.

What changed in the workflow

Before this, I had a split-brain setup.

The desktop dashboard was where the real task state lived. My phone was mostly for checking messages. If an AI coding task needed a decision, I had to return to the browser or terminal.

Now the chat app can stay in the loop:

start a coding task from WeChat
receive progress as the local runtime works
answer approval prompts without finding the terminal
ask for a status update without interrupting the agent
continue the same task with a short follow-up

That does not make WeChat special. That is actually the point.

The more useful design is that the channel is replaceable. Telegram, Feishu, DingTalk, WeChat, and the web dashboard should all speak to the same task model. Users can pick the surface that matches their day.

Why I kept the tools unchanged

I did not want to build a fake Claude Code or a fake Codex inside a chat app.

Those tools already have their own strengths. The better layer is a local control plane around them: one place for routing, credentials, approvals, task records, logs, and channel delivery.

That is what CliGate is trying to be.

You still run it locally:

npx cligate@latest start

Then the same machine that owns your code can also own the coordination loop. No hosted relay is required for the core workflow, and the AI coding tools do not need custom provider configs for every channel you add.

The lesson

The main thing I learned is that "mobile support" for local agents is not just a smaller UI.

It is a continuity problem.

If the phone cannot see the task state, approvals, runtime choice, and final result, then it is only a remote text box. If it can see those things, it becomes a practical control surface for work that still runs safely on your own machine.

That is the direction I want local AI tooling to go: the work stays local, but the conversation can meet you where you already are.

The project is open source here: https://github.com/codeking-ai/cligate

If you use AI coding agents, where do you want their progress and approval prompts to show up: terminal, browser, Slack, Telegram, WeChat, or somewhere else?

My Coding Agent Asked Permission for Every Tiny Step

CodeKing — Tue, 09 Jun 2026 07:09:30 +0000

The most annoying bug in my local AI assistant was not that it refused to ask for permission.

It was that it asked too often.

I would give it a normal task like "read this PDF and tell me what is inside." The assistant would make a reasonable first move, ask for approval, run the command, and then immediately ask again for the next tiny probe.

One task turned into a permission treadmill.

The approval loop felt safe but unusable

Approval prompts are good. I want a local assistant to stop before it runs commands, writes files, opens apps, or touches the desktop.

The problem is that real work is rarely one tool call.

Reading a PDF might require checking whether Python exists, finding a converter, running the converter, reading the text output, and then summarizing it. A desktop task might require focusing a window, entering text, pressing a button, and verifying the result.

If every step asks the same kind of question, the user stops evaluating risk and starts clicking through interruptions.

That is worse than unsafe. It trains the user to ignore the safety system.

The bug was treating approval as a single event

The old flow in CliGate looked roughly like this:

assistant chooses tool
-> policy says confirmation required
-> user approves
-> tool runs
-> assistant continues
-> next tool asks again

That was technically correct. Each tool call had its own confirmation.

But it missed the shape of the user's intent. The user was not approving "run one tiny probe." They were approving the assistant to continue one bounded task.

So I changed the behavior after the first approved action in a chat conversation.

Once the user approves the first execution tool for the task, CliGate flips a conversation flag that lets later steps continue without another approval roundtrip. The assistant still feeds the real tool result back into the continuation run, so it can keep working from what actually happened instead of pretending the approval itself completed the task.

The escape hatch matters too:

/safe

That turns the conversation back into explicit confirmation mode.

The continuation had to carry the real result

There was another subtle part.

When a user approves a pending action, the system cannot just say "confirmed" and stop. It has to continue the original job.

The continuation prompt now tells the assistant that the previous tool call was approved, already executed, and produced a real result. That stops the assistant from asking for the same approval again or forgetting why the tool ran in the first place.

This made the assistant feel much less like a form with a chatbot attached to it. The flow became:

ask once for the risky boundary
execute the first step
continue the task with real observations
only interrupt again when the user explicitly returns to safe mode or a genuinely different boundary appears

The interesting part is that the fix is not "disable approvals." It is "remember what approval was for."

I also hit a language bug

This same continuation path exposed a smaller but very visible bug.

The continuation message was system-generated and written in English. When the original user task was Chinese, the assistant sometimes detected the system continuation as the latest "user" text and switched the next confirmation prompt to English.

That produced an ugly mixed-language workflow: first approval in Chinese, later approval prompts in English.

The fix was simple in principle: system-authored continuation turns should not decide the reply language. The assistant now looks back to the latest genuine user message in the conversation before choosing the response language.

That is the kind of detail that seems minor until you use the tool for a multi-step task. Then it is the difference between "this assistant is tracking me" and "this assistant is reacting to its own plumbing."

The rule I am keeping

I do not think agent approval should be all-or-nothing.

For local tools, the useful middle ground is task-scoped trust:

ask before crossing a meaningful boundary
remember that approval for the current task
keep an obvious way to return to strict mode
do not let system continuation messages masquerade as user intent

That is now how I am shaping approvals in CliGate, the local control plane I use for Claude Code, Codex CLI, Gemini CLI, desktop automation, channels, and model routing.

The project is open source here: CliGate.

If you are building local agents, how are you handling approval fatigue: per tool call, per task, per session, or something more granular?

I Wired Qwen and OpenRouter Into Claude Code and Codex Without New Configs

CodeKing — Fri, 05 Jun 2026 08:47:05 +0000

Every new model provider looks simple until it reaches your actual coding tools.

Qwen has DashScope's OpenAI-compatible mode. OpenRouter gives you one API for a huge list of models. Both sound like they should be easy to plug into an AI coding workflow.

Then the tools remind you that "OpenAI-compatible" does not mean "compatible with everything I use."

Claude Code expects Anthropic Messages. Codex expects the Responses shape. Other clients speak Chat Completions. A provider can have a perfectly good API and still force you into another round of base URLs, API keys, model aliases, and small wrapper scripts.

That was the part I wanted to avoid.

The annoying part was not the API key

Adding one more key is easy.

The mess starts when every tool wants to own the provider decision.

If I want to try Qwen for cheap coding tasks, I do not want to edit Claude Code's environment, then Codex's config, then a chat client's model list. If I want to test an OpenRouter model slug like anthropic/claude-3.7-sonnet, I do not want a routing layer to accidentally remap it because it looks unfamiliar.

The shape I wanted was simpler:

tools keep pointing at localhost
providers are added once
model names are mapped or passed through in one place
protocol conversion happens behind the gateway

So the latest CliGate change adds Qwen and OpenRouter as provider presets instead of making them another pile of one-off config.

The fix was a preset, not another bespoke provider

CliGate already runs as a local control plane for AI coding tools. Claude Code, Codex CLI, Gemini CLI, OpenClaw, and OpenAI-compatible clients can point at one local server, while CliGate owns credentials, routing, logs, and model mapping.

For Qwen and OpenRouter, the interesting part is that they are both OpenAI Chat-style providers. That means the new provider definition can be mostly data:

{
  id: 'qwen',
  apiFormat: 'openai_chat',
  baseUrl: 'https://dashscope.aliyuncs.com/compatible-mode/v1',
  models: ['qwen-max', 'qwen-plus', 'qwen-turbo', 'qwq-32b'],
  tiers: { standard: 'qwen-plus', fast: 'qwen-turbo' }
}

OpenRouter gets the same treatment, with one important rule: model ids containing / pass through as native model slugs. If I ask for openai/gpt-4o-mini or qwen/qwen-2.5-72b-instruct, CliGate should not pretend it knows better and remap that into a generic tier.

That small rule matters because OpenRouter is not one model family. It is a catalog.

The protocol bridge is the real feature

The provider preset is only half the story.

Qwen and OpenRouter expose Chat Completions. Claude Code does not speak Chat Completions. Codex may enter through a Responses-compatible path. So the gateway now treats these providers as chat-native upstreams and bridges the tool-facing protocols around them.

For Claude Code, CliGate translates Anthropic Messages into OpenAI Chat, sends the request to Qwen or OpenRouter, then translates the answer back into an Anthropic-style message. Tool calls and tool results are preserved in the translation.

For Codex, CliGate deliberately does not pretend these providers have a native /responses endpoint. It leaves native Responses support disabled, so the existing Responses-to-Chat fallback handles the request through Chat Completions instead.

That detail is boring in the best way. The tools keep speaking their own protocols. The provider only has to support the API it actually supports.

What setup looks like now

The user-facing setup is intentionally small:

npx cligate@latest start
# Add a Qwen or OpenRouter key in API Keys
# Keep Claude Code and Codex pointed at localhost:8081

After that, routing can happen inside CliGate. Qwen can fill a cheap fast or standard tier. OpenRouter can be used when you want to try a specific upstream model slug. Existing OpenAI, Anthropic, Gemini, Azure OpenAI, DeepSeek, Vertex, and local routes can stay in the same dashboard.

No CLI needs to know which provider won the route.

Why this feels better than another config file

The main win is not that CliGate supports two more providers.

The win is that adding a provider no longer means teaching every tool about that provider.

Qwen and OpenRouter are now just credentials and routing choices inside the local control plane. Claude Code can still think it is talking to an Anthropic-shaped API. Codex can still enter through its expected path. OpenAI-compatible clients can still use Chat Completions directly.

The provider decision moves out of the tool and into the layer that can actually inspect, route, price, and log the request.

Source: github.com/codeking-ai/cligate

How are you handling OpenRouter-style model catalogs in your AI coding setup? Do you pass model slugs through directly, map everything into tiers, or keep separate configs per tool?

"My AI Assistant Needed a Control Plane, Not a Bigger Loop"

CodeKing — Wed, 03 Jun 2026 08:34:33 +0000

I kept trying to make my AI assistant smarter by adding more tools to the same loop.

That worked for a while. Then the assistant had to do normal user things: continue a Codex task from chat, answer a status question from DingTalk, remember how a desktop workflow succeeded, wait behind another run that was using the mouse, and still route Claude Code traffic through the same localhost server.

At that point the problem was no longer "how many tools can one agent call?"

The problem was architecture.

The loop got too many jobs

The first shape was simple:

user message -> assistant loop -> tools -> answer

That is fine for a demo. It is not fine for a resident assistant.

A resident assistant has to know whether a message is a new task, a follow-up, a status check, a correction, or a cancellation. It has to avoid stealing the desktop from another running task. It has to remember procedures without shoving every old transcript into context. It has to delegate coding work to Codex or Claude Code without pretending it is the executor.

Those are different jobs. When I kept them inside one loop, every fix made the loop more capable and less understandable.

So I stopped thinking about the assistant as one agent and started treating it as a local control plane.

The split that made the system easier to reason about

In CliGate, the architecture now looks more like this:

Experience Plane
  -> Assistant Control Plane
  -> Runtime Execution Plane
  -> Proxy / Model Access Plane

Observation Plane + Memory / Policy Plane sit across the side.

The names sound formal, but the boundaries are practical.

The experience plane owns where the user is talking from: dashboard chat, assistant tasks, Telegram, Feishu, DingTalk, scheduled jobs.

The assistant control plane decides what kind of work this is. Should it answer from state? Should it start a task? Should it continue an existing one? Should it wait because the desktop is already held by another run?

The runtime execution plane is where Codex and Claude Code live. They do the actual coding work. The assistant can dispatch, continue, summarize, and coordinate them, but it does not need to become a worse version of them.

The proxy/model access plane handles the boring but necessary provider work: protocol translation, account pools, API keys, routing, model mapping, request logs, and usage.

The side planes are what keep the assistant sane:

observation turns scattered runtime events into small structured facts
memory stores reusable facts, directives, workflows, and references
policy decides whether an action is allowed, queued, or needs approval

Observation-first changed the behavior

The biggest improvement came from making the assistant consume observations instead of raw logs.

If a Codex run is waiting for approval, the assistant should not read a giant transcript to rediscover that. It should see a compact fact:

"Task X is waiting for approval to run command Y."

If another assistant run is currently driving the desktop, a new run should not guess from chat history. It should see a resource holder:

"desktop is held by run R."

That one change made status questions, cancellation, follow-ups, and concurrent runs much less fragile. The assistant no longer has to infer the system state from the last few messages. The system gives it a state model.

Memory is not just longer context

I also learned that "remembering" is not the same as stuffing more chat history into a prompt.

For this assistant, memory is file-based and scoped. It can store a workflow, a fact, a standing directive, or a reference. On the next similar request, the prompt only gets a small memory index. If the assistant thinks one entry matters, it explicitly recalls the body.

That keeps the default context small while still letting the assistant learn things like:

how a desktop publishing flow finally worked
which project rule the user wants preserved
where an internal document lives
what not to try again

For procedure memories, the rule is verify-then-trust. Try the remembered steps, but confirm the UI still matches. If it changed, explore again and update the memory after success.

That is closer to how I want a practical assistant to evolve: not by growing a huge transcript, but by distilling successful work into reusable units.

Why this matters for local AI tools

Local AI tooling is messy in a specific way.

The user may have Claude Code, Codex CLI, Gemini CLI, OpenClaw, a browser session, a desktop app, a Telegram channel, and several provider accounts. The hard part is not only making one model call. The hard part is keeping all of those pieces coordinated without turning the assistant into an opaque supervisor that hijacks every message.

That is why CliGate still keeps a direct runtime path. If the user is already talking to a Codex session, the message can go straight there. The assistant control plane is for explicit coordination, background tasks, memory, policy, desktop work, and cross-channel workflows.

The split is not glamorous, but it is the difference between an impressive demo and a tool I can leave running.

The takeaway

I used to ask: how do I make the assistant loop smarter?

Now I ask: which plane should own this responsibility?

That question has prevented a lot of accidental complexity. It keeps provider routing out of the assistant loop, execution inside dedicated runtimes, observations out of raw logs, and memory out of unbounded chat history.

The project is open source here: CliGate.

If you are building agents around existing tools, are you putting everything inside one loop, or are you starting to split control, execution, observation, and memory too?

"I Stopped Letting Every AI CLI Own Its Provider Config"

CodeKing — Tue, 02 Jun 2026 07:27:37 +0000

AI coding tools keep getting better.

The setup around them keeps getting worse.

Claude Code wants one style of config. Codex CLI wants another. Gemini CLI has its own path. OpenClaw has a different provider file again. Each tool makes sense in isolation. Together, they turn provider management into a small pile of duplicated state.

That was the part I wanted to stop.

The real problem is ownership

The annoying part is not that every tool needs a base URL or an API key.

The annoying part is that every tool starts acting like it owns your provider strategy.

If I change from OpenAI to Azure OpenAI, I should not have to remember which CLI has which config file. If I want Claude Code on one account and Codex on another provider, that should not become a weekend of shell variables, TOML edits, and half-forgotten JSON.

The tool should own the developer experience.

The local control plane should own routing.

What I changed

I built that rule into CliGate.

CliGate runs locally on localhost:8081. Claude Code, Codex CLI, Gemini CLI, and OpenClaw point at the same local gateway. After that, provider decisions move out of the individual tools and into one dashboard.

The setup becomes boring:

npx cligate@latest start

Then each tool only needs to know one thing:

use localhost:8081

The gateway handles the rest: account pools, API keys, model mapping, app-level bindings, fallback order, usage logs, and cost visibility.

Why this feels different

Before, switching providers meant touching the tools.

After, switching providers means changing a route.

For example, I can bind:

Claude Code to a Claude account pool
Codex CLI to Azure OpenAI
Gemini CLI to Gemini API keys
quick fallback requests to cheaper or free models

The CLIs do not need to know that decision changed. They keep speaking the protocol they already speak. CliGate translates and routes behind them.

That is the point: I do not want four AI tools to become four configuration databases.

The useful boundary

This is the boundary that made the project simpler:

Tools should be replaceable.

Providers should be replaceable.

Routing should be inspectable.

Once those three things are separated, a lot of annoying workflow problems get smaller. A key expires in one pool? Replace it in one place. A provider gets expensive? Move that app to another route. A model name does not match the upstream deployment name? Map it once.

No drama. No config archaeology.

Who needs this

If you use one AI CLI with one API key, you probably do not need a gateway.

If you use Claude Code, Codex CLI, Gemini CLI, local models, work credentials, personal accounts, and a few free provider keys, you probably already feel the problem.

The sharp version is this:

Your AI CLI should not own your provider strategy.

It should send the request. A local layer should decide where that request belongs.

That is the part CliGate is trying to make normal.

How are you handling provider config across AI coding tools right now: one config per tool, one wrapper script, or a local gateway?

"My AI Agent Kept Missing Buttons, So I Used Windows UI Automation"

CodeKing — Wed, 27 May 2026 05:53:52 +0000

The first time you let an AI agent control a desktop, it feels impressive.

Then it misses a button by 40 pixels.

Or it clicks the window behind the window. Or it types into the wrong field because a notification stole focus. Or it spends ten seconds looking at a screenshot just to decide where a textbox probably is.

That was the part of desktop automation that bothered me. The model was not really failing at reasoning. It was being forced to reverse-engineer an application from pixels.

Screenshot-first is the wrong default

The common loop looks like this:

screenshot -> model guesses UI -> model guesses coordinates -> click -> screenshot again

It is useful as a fallback, but it is a bad default for normal desktop apps.

Most buttons, inputs, tabs, menus, and labels already exist in a semantic tree before they become pixels on the screen. The operating system exposes that tree for accessibility tools: screen readers, magnifiers, automation software, and anything else that needs to understand the UI without guessing from a bitmap.

On Windows, that layer is UI Automation.

So I stopped treating screenshots as the first source of truth.

The loop I wanted

For CliGate's desktop agent, I wanted a local loop that worked more like this:

list windows -> focus app -> find control -> set value -> send key -> read text

That is a different kind of automation.

Instead of "click around until something happens," the agent can ask Windows for visible windows, focus the right one, find an Edit control, set its value through ValuePattern, invoke a button through UIA, or read text from a matching control.

Coordinates still exist, but they become a fallback. If the app exposes accessibility metadata, the assistant should use the semantic route first. If the app is custom-rendered, Canvas-heavy, or not exposing useful controls, then it can capture a screenshot and fall back to visual inspection.

The important rule is:

Observe semantically first. Use pixels only when the semantic layer is missing.

How I wired it into CliGate

CliGate is already a local gateway for Claude Code, Codex CLI, Gemini CLI, OpenClaw, account pools, API keys, runtime sessions, and channel workflows.

The desktop part adds a small local companion service that runs in the user's interactive desktop session. The assistant talks to it through local tools:

list visible windows
launch or focus an app
find one control or all matching controls
click a control through UIA
set an input value without relying on clipboard focus
send control keys like Enter
read visible text or values
capture a screenshot when UIA is not enough

That means the agent can stay inside one local control plane. It can work in a repo, continue a Codex or Claude Code runtime session, and still operate the desktop app that owns the last step of the workflow.

Why local matters

I do not want desktop control to depend on a hosted relay.

The desktop is full of sensitive state: open apps, browser sessions, account consoles, chat windows, clipboard contents, and local files. Keeping the control service on localhost keeps the automation close to the machine that owns that state.

It also makes the loop simpler. The assistant can inspect, act, and verify against the actual window in front of the user without shipping a stream of screenshots to a separate service.

This fits the rest of CliGate's design: local server, local dashboard, local runtime orchestration, local desktop bridge.

What changed

The big change was not speed, although UIA calls are much faster than screenshot-model-click loops.

The bigger change was reliability.

A textbox is no longer "some rectangle near the bottom of the screenshot." It is an Edit control. A button is no longer "probably the blue thing." It is a control with a name, bounding box, state, and supported patterns.

Screenshots are still useful. Some apps do not expose good accessibility metadata. Some content is graphical by nature. But for normal desktop and browser workflows, UIA-first makes the assistant feel less like a demo and more like an operator.

The project is open source here: CliGate on GitHub

If you are building desktop-capable agents, are you starting with screenshots, accessibility trees, browser automation, or something else?

"My AI Assistant Could Code, But It Couldn't Operate My Desktop"

CodeKing — Tue, 26 May 2026 09:51:16 +0000

My assistant could already read files, run shell commands, and delegate coding work to Claude Code or Codex.

But the moment a workflow hit a real desktop app, the illusion broke.

A browser needed a click. A page needed a scroll. A field needed real text input. A task could finish the hard part and still get stuck on the last two seconds of UI.

That felt like a fake kind of automation.

The problem wasn't coding

The hard part here wasn't generating code. It was crossing the gap between "I know what should happen next" and "I can actually operate the window in front of me."

In practice, that gap showed up in small but annoying ways:

a browser tab needed Ctrl+L and a URL paste
a page exposed no reliable accessibility selector, so a screenshot was needed first
a long form needed scrolling inside the right pane, not the whole desktop
a final publish step still depended on one visible button

So the assistant didn't need another coding loop. It needed a safe desktop-control layer.

The local control loop I added

I added a small set of desktop tools around a companion agent running on the same machine.

The assistant can now do things like:

list windows
focus a specific app
find accessible controls when UI Automation is available
set input values directly
send hotkeys like Ctrl+L
capture screenshots before pixel-based actions
click, move, and scroll with explicit coordinates only after visual confirmation

The key constraint is simple: observe first, then act.

If selectors are available, use them. If they are not, capture the window, inspect what is actually visible, and only then click. That rule matters more than any single tool because it keeps desktop automation from turning into random coordinate guessing.

What changed in the workflow

Before this, the assistant could help me prepare a task but not finish anything that crossed into a real app.

Now the same local loop can cover more of the actual workflow:

inspect window → focus app → locate control or capture screenshot → act → verify

That sounds small, but it changes what "assistant" means in practice.

It is no longer limited to code and terminal state. It can handle the messy last mile where real work often stalls.

Why I kept it local

I did not want this running through a hosted browser service or a remote desktop relay.

Desktop control touches exactly the kind of things that should stay on the machine that owns them: open apps, visible windows, clipboard state, local sessions, and personal accounts.

Keeping it local also makes the loop faster. The assistant can inspect, act, and verify against the current desktop state without shipping screenshots or UI events to another service first.

That local-first constraint fits the rest of CliGate anyway. The gateway, the assistant, the runtimes, and now the desktop-control layer all live on the same box.

What I learned

The interesting lesson was that "assistant capability" is not just about better reasoning or better code generation.

A lot of workflows fail because the assistant cannot cross boundaries between tools.

Terminal-only automation is useful. But if the real workflow ends in a browser, settings window, login dialog, or web app form, then desktop control becomes part of the product surface whether you planned for it or not.

So this update was less about making the assistant smarter and more about making it less incomplete.

If you're building local AI tooling, where does your automation still stop — at the terminal, at the API, or at the desktop?

Repo: https://github.com/codeking-ai/cligate

"My AI Assistant Could Code, But It Couldn't Operate My Desktop"

CodeKing — Tue, 26 May 2026 09:10:44 +0000

Most AI coding agents are good until the task leaves the terminal.

They can edit files. They can run tests. They can explain a diff. Then the work hits a desktop app, an OAuth approval screen, a native settings window, or a web UI that was not designed for API access. Suddenly the agent is not stuck on intelligence. It is stuck on reach.

That was the gap I kept running into while building my local AI setup. I had Claude Code, Codex CLI, Gemini CLI, local models, provider keys, and account pools. The missing piece was not another model.

It was an operator.

The Problem Was The Boundary

My old workflow had two separate worlds.

In one world, coding agents lived inside terminals and repos. They could reason about code, run commands, and keep a session alive.

In the other world, real work still happened through desktop apps, dashboards, browser windows, chat clients, and provider consoles. A human could jump between those worlds without thinking. An agent could not.

That made the assistant feel smaller than it should:

It could fix a bug, but not always finish the setup.
It could tell me where to click, but not click safely.
It could generate a workflow, but not reliably drive the app that owned the workflow.
It could reuse project knowledge, but only if I remembered to paste it in.

So I changed how I think about CliGate.

CliGate is no longer just a local API gateway for AI tools. It is becoming a local control plane for agent work.

What CliGate Does Now

CliGate still starts as one localhost service for AI coding tools.

You can point Claude Code, Codex CLI, Gemini CLI, and OpenClaw at the same local server, then manage provider keys, account pools, routing, usage, logs, and local runtimes from one dashboard.

But the newer assistant layer sits above that.

It has two modes:

Direct runtime: keep talking to the current Codex or Claude Code session.
Assistant collaboration: ask CliGate Assistant to inspect state, choose a runtime, continue a task, handle a blocked run, or summarize what happened.

That split matters. I do not want every normal message to be intercepted by a clever supervisor. Sometimes I just want to continue the current runtime session. Other times I want an assistant that can see the bigger picture.

The assistant is not trying to replace Codex or Claude Code. It coordinates them.

Skills Made It Less Generic

The second piece is skills.

A skill is a local package of instructions, scripts, templates, and references. The assistant does not need every detail in context all the time. It can see a short description first, then read the full SKILL.md only when the task matches.

For example:

skills/
  devto-publisher/
    SKILL.md
    publish.js
    templates/

That turns the assistant from "a general chat box with tools" into something closer to a teammate with reusable procedures.

One skill can know how to publish a Dev.to article. Another can know how to build a spreadsheet. Another can know the conventions of a local repo. The key is that these are local, inspectable, and executable through the same permission system as the rest of the agent.

It is not magic. It is just a better way to keep operational knowledge out of one giant prompt.

The Desktop Part Is The Big Unlock

The part I am most excited about is desktop control.

The first naive version of desktop automation is usually visual: take a screenshot, ask the model where to click, move the mouse, repeat. That works for demos, but it is fragile. Small buttons, focus changes, DPI scaling, popups, and animations can break it.

CliGate's desktop agent takes a different default path on Windows: UI Automation first, screenshots second.

Instead of guessing pixels, the assistant can ask the operating system for the UI tree:

list windows -> focus app -> find input -> set value -> send Enter -> read text

That means it can find a textbox by control type, set its value through the accessibility API, invoke a button, read visible text, and only fall back to screenshots when the app does not expose useful accessibility metadata.

This is the bridge I wanted: a coding assistant that can work in repos, but also operate the desktop applications that surround the repo.

Where This Is Going

The current shape is:

CliGate routes AI coding tools through one local server.
Runtime sessions keep Codex and Claude Code work alive.
The assistant watches, coordinates, and summarizes.
Skills give it reusable procedures.
Desktop control gives it a path into native apps and GUI workflows.

That combination changes the product from "proxy for AI tools" into "local operator for developer workflows."

I think the desktop-control layer deserves its own post, because "AI can operate any app through the OS accessibility tree" is a deeper topic than I can fit here.

The project is open source here: CliGate on GitHub

How are you handling the boundary between coding agents and the desktop apps they still need to interact with?

DeepSeek's API Price Cut Changed My Claude Code and ChatGPT Math

CodeKing — Mon, 25 May 2026 08:37:24 +0000

The DeepSeek API price cut made me rethink a habit I had quietly accepted: choosing an AI coding tool and then living with whatever model economics came with it.

Claude Code is great when I want a strong terminal-native coding agent. ChatGPT and Codex are great when I want OpenAI's workflow and model stack. But when a provider like DeepSeek suddenly drops API pricing, the obvious question is not just "is this cheap?"

It is: can I actually use the cheaper model from the tools I already use?

The Price Cut Is The Interesting Part

As of May 25, 2026, DeepSeek's pricing page lists V4 Flash at:

$0.14 per 1M input tokens
$0.0028 per 1M cached input tokens
$0.28 per 1M output tokens

It also lists V4 Pro at the 75% discounted rate, with a note that after the promotion ends on May 31, 2026, the API price will still be officially adjusted to one-quarter of the original price:

$0.435 per 1M input tokens
$0.003625 per 1M cached input tokens
$0.87 per 1M output tokens

The part that matters for coding agents is cached input. Coding tools resend a lot of repeated context: system prompts, repo summaries, conversation history, tool schemas, and task state. If cache hits are cheap enough, repeated agent loops start looking very different economically.

I checked the current public pricing pages before writing this: DeepSeek API pricing, Claude plans, Claude API models, ChatGPT plans, and OpenAI API pricing.

That is why this cut is more than a nice model announcement. It changes where I want routine coding traffic to go.

The Comparison I Actually Care About

Claude Code pricing is predictable if you use a subscription: Claude Pro is $20/month when billed monthly, and Max starts at $100/month. On the API side, Anthropic lists Claude Opus 4.7 at $5 input and $25 output per 1M tokens, and Sonnet 4.6 at $3 input and $15 output.

ChatGPT has the same split. Plus is the familiar $20/month plan, Pro tiers go much higher, and OpenAI API pricing for flagship GPT models is still priced like premium infrastructure. GPT-5.5 is listed at $5 input, $0.50 cached input, and $30 output per 1M tokens.

Those plans can be worth it. I am not pretending DeepSeek replaces every hard reasoning workload.

But for coding-agent traffic, the uncomfortable truth is that a lot of tokens are not "hard reasoning" tokens. They are:

reading files
rewriting boilerplate
producing test scaffolds
formatting docs
classifying intent
continuing a known task

That is exactly the kind of traffic I want to route to a cheaper model first.

The Annoying Part: Tools Do Not Make This Easy

The problem is that Claude Code, Codex, and ChatGPT-style workflows do not all speak the same protocol.

Claude Code expects Anthropic-shaped requests.

Codex expects OpenAI-shaped requests.

Other tools may expect Gemini-style routes or their own local configuration. So even when DeepSeek exposes low-cost models, the practical setup can still turn into a mess of environment variables, API keys, base URLs, and wrappers.

That is the gap I built CliGate to fill.

What Changed With CliGate

CliGate is a local AI gateway that runs on localhost. Instead of pointing every tool directly at a provider, I point the tools at CliGate once:

# Claude Code
export ANTHROPIC_BASE_URL=http://localhost:8081
export ANTHROPIC_API_KEY=any-key

Codex can also point at the same local gateway through its OpenAI-compatible configuration.

From there, CliGate handles the important layer:

route Claude Code, Codex CLI, Gemini CLI, and web chat through one local control plane
keep account pools and API keys in the same routing layer
map model names and app-level routes
send routine traffic to DeepSeek when cost matters
keep premium models available for the tasks that actually need them
show usage, request logs, and cost views in the dashboard

That means I do not have to decide "Claude Code or DeepSeek" as a tool choice. I can keep Claude Code as the interface and route some of its traffic through DeepSeek. I can keep Codex as the workflow and still move compatible requests to a cheaper upstream.

The Real Advantage Is Not Just Cheap Tokens

Cheap tokens help. But the bigger advantage is optionality.

I want to be able to say:

use DeepSeek V4 Flash for cheap routine work
use DeepSeek V4 Pro when I want stronger low-cost reasoning
keep Claude for difficult multi-file edits
keep GPT for workflows where OpenAI's stack is the right fit
keep local models for private or offline tasks

Without a routing layer, that sounds like a spreadsheet and a pile of config files. With a local gateway, it becomes an operations problem: add keys, set routing, inspect usage, adjust when the bill or quality tells you to.

That is the product advantage I care about. CliGate does not ask me to abandon Claude Code or ChatGPT-style tools. It lets those tools reach low-cost DeepSeek models without changing how I work.

My New Default

After this price cut, my default is no longer "pick one premium coding assistant and pay whatever it costs."

It is:

keep the coding tools I like
route routine traffic to the cheapest good-enough model
reserve expensive models for the tasks that justify them
watch usage and pricing in one place

That feels like the right shape for AI coding in 2026.

The models will keep changing. The prices will definitely keep changing. The part I do not want to keep changing is every CLI config on my machine.

CliGate is here if you want to inspect the implementation: https://github.com/codeking-ai/cligate

How are you handling model cost now: one subscription, direct API usage, or routing per task?

"My Web Chat Wasn't a Real Channel. That Broke My Agent Pipeline"

CodeKing — Fri, 22 May 2026 11:35:09 +0000

I thought my web chat was the simplest surface in the whole product.

Telegram, Feishu, and DingTalk were the complicated ones. Web chat was just the dashboard. Same browser, same server, same app. What could possibly go wrong?

A lot, apparently.

The bug looked random from the UI

A task would start from the web chat UI just fine.

The runtime session existed. The conversation existed. The task existed. The logs looked healthy enough.

And then the delivery pipeline tried to send a follow-up update back into the conversation and got:

conversation_not_found

Which made no sense, because the conversation definitely existed. I had just used it.

This is the kind of bug that wastes time because every individual subsystem looks half-correct.

The real problem: I treated web chat like a page, not a channel

The architecture in CliGate already had a channel model.

Telegram is a channel. Feishu is a channel. DingTalk is a channel.

Those inbound messages go through the same supervision and delivery machinery:

conversation store
scheduler
delivery sender
assistant orchestration
runtime session binding

But web chat had slowly drifted into a special-case path.

That felt harmless at first. Web chat lived inside the same app, so it was easy to give it a little custom state and a few convenience wrappers.

That was the mistake.

What actually broke

The old version of chat-ui/conversation-store.js exported its own store instance.

Meanwhile, the delivery and orchestration path used the shared channel conversation store.

So both sides were reading and writing "conversations," but not the same in-memory array.

That meant:

the chat UI could create a conversation
the route handler could see it
the runtime could bind to it
but the scheduler could still fail to find it later

The comments in the fix say it more plainly than I can:

// chat-ui and agent-channels each held a SEPARATE in-memory
// `conversations` array, even though both wrote to the same JSON file on disk.
// After server start, a chat-ui conversation created at runtime was visible to
// chat-ui-route but NOT to message-service, so scheduler deliveries hit
// `conversation_not_found` and silently dropped notifications.

That is exactly the sort of bug you get when a "small UI shortcut" quietly forks your domain model.

The fix was not complicated

I did not need a new abstraction.

I needed one source of truth.

Instead of exporting a dedicated chat-ui conversation store in production, I attached chat-specific helpers to the shared singleton used by the channel system:

installChatUiHelpers(agentChannelConversationStore);

export const chatUiConversationStore = agentChannelConversationStore;

That one change matters more than it looks.

Now web chat is not pretending to be adjacent to the channel system. It is part of the channel system.

Why this changed more than delivery

Once I stopped treating web chat as a special page, a lot of other decisions became cleaner.

A chat-ui conversation now behaves like a real peer of the other channels:

it has the same conversation identity model
it uses the same assistant delivery state
it flows through the same runtime binding logic
it can receive scheduler-driven updates without weird bridging code

That matters because a multi-surface assistant only stays sane if all entry points agree on what a conversation is.

If one surface has its own special rules, you do not have one product anymore. You have one product plus one exception that keeps leaking.

The other important fix: seed assistant mode from the start

There was a second detail hidden in the same file.

New chat-ui conversations now start with assistant control mode already set:

assistantCore: buildAssistantCoreDeliveryState(
  existingAssistantCore,
  { controlMode: CONVERSATION_ASSISTANT_CONTROL_MODE.ASSISTANT }
)

That matters because web chat should enter the same top-level assistant orchestration path as the messaging channels.

If the first message from the web UI skips that and goes straight to the bound runtime, you get behavioral drift:

web chat behaves one way
Telegram behaves another way
Feishu behaves another way

Then every bug becomes impossible to reason about because the surfaces are no longer comparable.

The test I actually wanted

I have learned to distrust fixes like this unless there is a test that proves the behavioral contract.

The right question was not "does chat-ui store still work?"

The right question was:

does a chat-ui conversation participate in assistant behavior like a real channel?

That is why the surrounding tests focus on assistant-mode behavior and persisted conversation semantics instead of only checking helper methods in isolation.

The implementation detail was a store instance bug.

The product bug was channel inconsistency.

What I learned from this

When you build multi-channel agent systems, the browser UI is seductive.

It feels local. It feels simple. It feels close enough to the app that you can justify giving it custom flow control, custom state, or custom routing.

That instinct is expensive.

If the browser chat can start tasks, receive async updates, carry conversation identity, and interact with the same supervisor as your mobile or messaging surfaces, then it is not "just a page."

It is a channel.

And if you do not model it that way, the architecture will eventually make you pay for the lie.

Are you treating your web chat as a first-class channel, or as a special case that has not failed loudly yet?

Repo: github.com/codeking-ai/cligate

"My Coding Agent Remembered Sessions, Not Work. That Was the Bug"

CodeKing — Thu, 21 May 2026 03:46:07 +0000

The first version of my coding agent had a very common bug: it remembered the conversation, but not the work.

That sounds fine until the agent has to do something real.

I would start a task from the web UI, continue it from a mobile channel, approve one command, ask for progress later, and then discover that the system was mostly guessing from the last few messages. It knew there was a session. It did not really know what job that session belonged to.

That is the difference between a chatbot and a working assistant.

The Problem Was The Unit Of Memory

Most agent systems begin with a simple shape:

conversation -> runtime session -> messages

That works for demos because the user does one thing at a time.

It breaks when the user behaves normally:

"continue the routing task"
"use Claude Code to review what Codex just changed"
"what happened with the thing from yesterday?"
"retry that, but keep the same working directory"

None of those are really about a chat session. They are about work.

A runtime session can crash. A user can switch from web to Telegram or Feishu. Two agents can work on the same issue from different roles. If the system treats the runtime session as the main identity, every one of those cases becomes fragile.

The Fix: Split Work From Execution

In CliGate, I started moving the design toward a different model:

Person
  -> Project
    -> Task
      -> Execution
        -> RuntimeSession

The important part is not the diagram. It is the boundary.

A Task is the thing the user thinks they are doing: "fix routing", "review the auth change", "write release notes", "check why the build failed".

An Execution is one concrete attempt to move that task forward. It may be Codex acting as the editor, Claude Code acting as a reviewer, or another provider doing a focused job.

A RuntimeSession is just the current process or provider session underneath that execution.

That means the assistant can say: this is still the same task, even if the runtime process has changed.

Why This Matters In Real Use

The most annoying bugs came from follow-ups.

When I typed:

make the button green

I did not mean "start an unrelated new job." I meant "continue the last task with the same context."

When I typed:

use cc to review it too

I did not mean "replace the current agent." I meant "spawn a second execution under the same task, with a reviewer role."

Those two messages look similar if all you have is chat history. They are very different if the system has a task model.

Once the assistant can distinguish task identity from execution identity, a few things become much easier:

status questions can be answered from task state
provider preference can follow the work instead of the channel
a dead runtime can be replaced without pretending the task is new
multiple agents can collaborate without sharing one messy transcript
web UI and mobile channels can show different levels of detail

That last point surprised me. On mobile, I want a short answer: "Codex is waiting for approval." In the web UI, I may want the full timeline: user message, assistant decision, runtime event, command output, file changes, approval, result.

Same task. Different presentation.

The Rule I Wish I Had Started With

If the user can reasonably ask "what happened with that thing?", that thing deserves an identity outside the chat transcript.

For my project, that identity became Task.

The runtime session is still useful. It preserves provider context and lets the agent resume efficiently. But it should not be the thing the product uses to understand the user's work.

Sessions are implementation details. Work is the product surface.

What Changed

I am still iterating on the architecture, but the direction already cleaned up several design decisions:

follow-ups route to tasks, not just the latest session
retries can keep the same task identity
reviewer agents can attach to the same task as editor agents
approvals can be remembered at task or project scope
channel messages can stay short without losing full traceability in the dashboard

This also made failure handling less awkward. If a runtime dies, the assistant does not need to tell the user "your session is gone, please start over." It can start a new runtime under the same execution or create a fresh execution under the same task, depending on what actually failed.

That is a small implementation detail with a large UX effect.

The Takeaway

I used to think agent memory meant better summaries of previous messages.

Now I think the more important question is: what are you summarizing into?

If everything collapses back into a conversation, the assistant will eventually lose the shape of the work. If the product has explicit projects, tasks, executions, and runtime sessions, the agent has somewhere stable to put its memory.

That has become one of the design principles behind CliGate.

If you are building coding agents, how are you modeling the difference between a conversation, a task, and a runtime session?