OpenHands stuck at 'Running task'? The first-chat stall

Model: Kimi K3 · ✓ Verified on OpenHands · 2026-09-23

OpenHands routes every model call through LiteLLM, so any OpenAI-compatible endpoint works — including kimi-k3, Moonshot AI's open-weight reasoning model.

Stuck at "Running task"? The short answer first

If your first OpenHands conversation sits at "Running task" / "Waiting for task" with no output: nothing is broken — the model call actually succeeded in the background, but the event channel between the agent sandbox and the UI gets rate-limited, so nothing renders. Fix: stop the conversation and start a fresh one. The second conversation runs normally. Independent proof the call went through: your provider's console shows the charge regardless of what the UI did. (Two related quirks, answered below: Conversation Metrics showing $0.0000 is a LiteLLM price-map gap, not free usage; and the Automations menu crashing is a known frontend bug in this build — your config is fine.)

Here for the setup instead? It takes five minutes — one saved LLM profile with three fields:

Custom Model:  openai/kimi-k3
Base URL:      https://api.wallabytoken.com/v1
API Key:       your Wallaby Token key

Everything below is the five-minute version: install, profile, verification. Disclosure: Wallaby Token sells API access to kimi-k3, and the endpoint shown here is ours. Tested on 2026-09-23 against the current OpenHands build (agent-server 1.36.0) — the UI changed significantly in recent releases, so the steps below follow the new profile-based settings, not the old "Advanced toggle" layout you may see in older guides.

What you need

  • A Wallaby Token API key (create an account at wallabytoken.com; new accounts receive $0.50 in free credit)
  • OpenHands running locally. Docker Desktop must be up — the agent executes tasks inside a sandboxed container, which is exactly where you want an autonomous agent. Then, per the official local setup:
uv tool install openhands --python 3.12
openhands serve

openhands serve checks Docker, pulls what it needs, and serves the UI at http://localhost:3000. First launch also pulls the agent-server image (about 5.5 GB) — that download is a one-time cost, so give it a few minutes.

Setting this up for a team? One account is enough — see the Rolling out to a team section at the end.

Setup: one LLM profile

  1. Open http://localhost:3000, click the gear icon for Settings → LLM, then Add LLM Profile.

OpenHands LLM settings showing the saved kimi-k3 profile marked Default

  1. Fill in the fields:

  2. Name (optional): anything recognizable, e.g. kimik3

  3. Custom Model: openai/kimi-k3 — the openai/ prefix tells LiteLLM to use the OpenAI-compatible request format; the part after the slash must be exactly kimi-k3
  4. Base URL: https://api.wallabytoken.com/v1
  5. API Key: your Wallaby key (shown as <hidden> once saved)

Profile fields filled: openai/kimi-k3, the Wallaby base URL, and the API key hidden

  1. Save Changes. The profile appears in the list with a Default badge and is used by every new conversation. Profiles persist in ~/.openhands, so this survives restarts and is shared with the CLI — the GUI documentation confirms serve uses the same configuration directory as CLI mode.

One deployment note: configure through the UI profile, not config files — file-based config.toml settings only apply when running OpenHands from source, and container installs ignore them.

Verify end to end

Start a new conversation (this matters — see the first troubleshooting entry) and send a minimal prompt:

Write a Python function that checks whether a string is a palindrome, then explain the time complexity.

What a healthy run looks like: a Thinking block appears first — kimi-k3 is a reasoning model, so a visible reasoning phase is expected behavior, not a stall — followed by the answer, and finally "Agent has finished the task."

A finished OpenHands conversation on kimi-k3: reasoning block expanded, answer delivered, task complete

Then check the billing side: your Wallaby console's Common Logs show itemized consume lines within seconds of each call. Our verification run produced three requests, the largest at 16,685 input + 803 output tokens for $0.0559 — the whole guide cost under six cents.

Troubleshooting

Only issues we actually hit, verbatim. For the full map beyond this guide — including the settings-layer bugs and what v1.25.0 fixed — see OpenHands with your own endpoint: every error we've hit, and the fix. Running the Model Router instead of a single profile? We logged what works and what isn't wired yet on your own endpoint.

"Settings saved. For old conversations, you will need to stop and restart the conversation to see the changes."

This toast means exactly what it says: LLM profile changes do not apply to conversations that already exist. Stop the current conversation and start a new one after saving your profile.

First conversation stalls at "Running task" — why?

A quirk of the current build: the first conversation can sit at "Running task" / "Waiting for task" with no visible output while the model call actually succeeds in the background — the event channel between the agent sandbox and the UI gets rate-limited, so nothing renders. Fix: stop the conversation and start a fresh one; the second conversation runs normally. If you want independent proof the call went through, your Wallaby console shows the charge regardless of what the UI did.

A first conversation stalled at "Running task" with no output

Conversation Metrics shows $0.0000 — is it free?

No. OpenHands computes cost from LiteLLM's built-in price map, which has no entry for kimi-k3, so it reports zero. The real, itemized cost is in your Wallaby console's Common Logs, and the rate card behind those numbers is Kimi K3 API pricing.

Conversation Metrics reporting $0.0000 for a kimi-k3 conversation

The first response is slow — is something stuck?

Probably not. OpenHands prepends a large system prompt — our first turn sent about 17,000 input tokens — and kimi-k3 then spends visible time reasoning before answering. Subsequent turns reuse cached input (billed at the cheaper cached-input rate) and feel noticeably faster.

Clicking "Automations" crashed the UI — did I break something?

No. In this build, opening the Automations section throws a generic frontend error page ("An error occurred / Uh oh, an unknown error occurred!"). Your configuration is fine — reload the page or open http://localhost:3000 directly and everything is back. Avoid that menu entry until OpenHands ships a fix.

Rolling out to a team

Each developer runs their own local OpenHands, and the account side carries the team mechanics: one prepaid balance as a hard ceiling on the whole team's spend, one named key per developer with its own dollar cap and optional expiry, and usage logs itemized per key so per-person cost attribution is the default view, not a spreadsheet project. There are no seat fees: adding a teammate costs exactly their token usage. The full walkthrough is in One endpoint, one bill.

Pricing

Per 1M tokens, as of September 2026 (current rates always on the pricing page):

Wallaby Official list
Input $2.70 $3.00
Cached input $0.27 $0.30
Output $13.50 $15.00

The $0.50 trial credit covers this entire guide many times over — our full verification run cost under $0.06. If you prefer working inside your editor over a standalone agent UI, the same endpoint works from VS Code with Cline — see Kimi K3 in Cline.

Get started

Create an account at wallabytoken.com, mint a key, save one LLM profile. Five minutes now, and every future conversation just works.

Tracking OpenHands releases? Our v1.25.0 quick look covers the settings-layer overhaul — bulk LLM profiles, the renamed routers, and the fixes that touch exactly the setup above.

Choosing between harnesses? We ran the same three-test task through OpenHands and OpenCode on the same Kimi K3 endpoint, three runs each, and counted what each one cost: OpenHands vs OpenCode on Kimi K3.

Why Wallaby

Every request lands on your invoice as an itemized line with token counts — no content logs, no training on your data, no usage reports built from your traffic. We host open-weight models only, keep a public status page, and run our own work through the same gateway we sell.

Live pricing · Status · Why we built Wallaby

Like the Dispatch? Add Wallaby as a preferred source on Google, or subscribe via RSS.
Did this help?