## Summary

I connected a Lovense-style haptic device to a real-time avatar character chat system. The point was not the adult gadget itself, but the broader question: if conversation, speech, facial motion, video, and physical output all share one timeline, how much stronger does the sense of presence become?

The practical answer was clear. Giving everything to the language model was less stable than giving it a small haptic DSL. Current local LLMs are not good at imagining a full temporal intensity curve while also writing character dialogue. But when the model can choose from parts such as `wave`, `breathe`, `pulse`, and `loop`, even a weak local model can produce motion that feels intentional.

This is a note on an admin-only MVP. The topic is NSFW-adjacent, but the engineering subject is embodiment: how a character AI can acquire something like a body.

## Background: growth without dependency

Kotonia combines real-time avatars with character chat. Within my current field of view, few services offer high-quality image, voice, video, and chat in one coherent character experience.

The top of the funnel has started to work. Through articles, X posts, and organic search rather than paid ads, the service reached 70 registered users in roughly one month after Google started showing it. That suggests the entry hypothesis is not bad.

The payment wall is different. Paid users are still at zero, and strong dependency signals are scarce. In other words, "interesting" and "worth paying for every month" are separate states. I needed the next large product hypothesis.

There were two candidates.

The first was a developer-oriented service: APIs, SDKs, and eventually a serious Linux agent that runs in the browser while an avatar accompanies the workflow. Think of a Claude Code-like value proposition with a visible character layer.

The second was physical contact control. Lovense was a convenient starting point because it has large UX impact and fits the current asset base. The long-term target is probably not a haptic toy but a doll, robot, or embodied agent. Kotonia already invests heavily in real-time behavior extraction, so there may be a real path if the physical device layer is tuned well.

## The reference context

The direct spark was [Kyure_A's 2025 Hatena Blog article](https://kyre.hatenablog.jp/entry/2025/05/06/212549), which explored LLM-mediated adult device control through external tools.

My implementation chose a different interface. Instead of exposing the device directly to an MCP server, the character chat response can contain a structured haptic command. The visible text is cleaned for the user, while the command is returned to the frontend as data. That makes it possible to bind dialogue, speech playback, avatar speech, and haptics into one product experience.

This sits near earlier internal experiments such as [Voice-first local LLM](/en/articles/voice-first-local-llm/) and [when the features existed but UX was the bottleneck](/en/articles/features-existed-ux-was-the-bottleneck/).

## Haptics as a variable-length time series

The core model is simple. Haptic control can be represented as a two-dimensional sequence of time and intensity.

For example:

```text
3x2, 0x0.8, 5x4
```

This can mean "intensity 3 for 2 seconds, stop for 0.8 seconds, intensity 5 for 4 seconds." Even this is enough to approximate a haptic segment for an utterance.

But pleasant synchronization between dialogue and physical output needs more than a fixed sequence. Conversation has pauses. It has hesitation. It gets stronger, weaker, and stronger again. Users read intention from those changes.

So I added a minimal DSL:

```text
wave(6,1,7,4)
breathe(8,2,5)
pulse(2,7,0.25)
loop(2){breathe(6,2,5),0x0.6,wave(4,1,6,3)}
```

`wave` creates a curve over a duration, `breathe` creates a slower rise and fall, `pulse` creates short beats, and `loop` repeats an inner pattern. The model is not asked to design the full waveform. It is asked to combine components.

This helped more than expected. Even if the local LLM is not very smart, loops and breathing patterns make the output feel far less mechanical than a flat vibration.

## Estimating speech duration from text length

The exact audio duration is not always available before execution. For the MVP, I estimated speech duration from the length of the generated text, then allowed haptic commands to be stacked inside that approximate window.

This is not perfect synchronization. It is good enough for the first experience. The device moves while the character is speaking. It stops when the speech ends. Pauses, waves, and strength changes can appear inside the segment. That alone feels very different from a constant intensity.

The important point is not frame-perfect alignment. The important point is staying within the range where the user feels that the motion is responding to the current line.

## Extracting structure, not regex leftovers

At first, the chat response contained commands like this:

```text
{{TOY: loop(2){breathe(6,2,5),0x0.6,wave(4,1,6,3)}}}
```

But the existing chat pipeline already removed unknown command-like text before returning the final message. That was good for UI cleanliness, but bad for haptics: by the time the response reached the frontend, the command could be gone.

The fix was to treat visible text and haptic commands as separate structures. The user-facing message removes the marker. The frontend receives a field such as `toyCommands`. This avoids mixing UI rendering with device control.

After this change, ordinary chat responses could reach the frontend with haptic commands intact.

## Why loops broke

The most annoying bug was `loop`. The inner `loop(2){...}` has its own braces, and the outer `{{TOY: ...}}` marker also uses braces. A simple regular expression can easily stop at the wrong closing brace.

The model also tends to drop one closing brace. With nested loop syntax, a valid command can end with `}}}`. That is visually awkward, and weak models often output only two braces.

The parser moved to a scanner. Once it sees `{{TOY:`, it counts brace depth until the true end of the marker. If exactly one outer closing brace is missing and recovery is unambiguous, it repairs the command. That made nested `wave` and `breathe` calls inside `loop` reach the frontend reliably.

## What it felt like as a user

The surprising part was that raw strength was not the key factor. Pauses, weakening, and returning were more important.

If the device moves at a constant intensity throughout the line, it becomes mechanical very quickly. But if it stops briefly, breathes, or rises and falls with the utterance, it can feel as if the character is watching the timing. The model did not become smarter. The temporal structure became better.

This is the core lesson. A local LLM is not yet smart enough to jointly imagine the dialogue, speech length, user state, and physical time-space output. A lower-level DSL and a runtime that fills in time are useful precisely because the model is weak.

Instead of increasing intelligence, we can build a temporal structure that makes intelligence perceptible.

## Safety constraints

The MVP is admin-only. General release should be handled carefully. At minimum, I would keep these constraints:

- only explicitly enabled administrators can use it
- the UI shows device connection state
- maximum intensity, maximum duration, and continuous runtime are capped
- unknown commands are discarded
- an immediate stop button is always available
- adult contexts require age confirmation and consent
- logging policy separates what is stored from what must never be stored

This is not just a remote control. When conversational AI gains physical output, both UX intensity and risk increase at the same time.

## Next steps

The next layer is richer `wave` composition, multiple layers, conditional loops, and tighter alignment with speech segments. Speech start, endings, silence, and user interruption should become events that haptic patterns can attach to.

Eventually, the same timeline should control not only haptic devices but arms, expressions, posture, gaze, simple robots, and doll-like bodies.

Images, voice, video, and chat are already good enough to create a strong illusion. The remaining task is to integrate them as an embodied counterpart. This experiment was a small entrance to that problem.

## Takeaway

Physical-contact UX is not determined only by model intelligence.

Even a weak local LLM can produce a much stronger experience if haptic commands are structured, time and intensity are expressed through a DSL, and execution is synchronized with speech duration. Pauses, waves, breathing, and repetition matter a lot.

The next frontier of character chat is not only a bigger model. It is what the model does when it has a body: when it moves, how long it moves, and how its timing relates to speech.


An implementation note on connecting a Lovense haptic device to real-time avatar character chat, using a tiny DSL to compensate for weak local LLM timing.