[MODEL] Claude stuck repeating same pattern multiple times

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

I was asking Claude to explain to me some details about how IMUs sensor fusion works.

What Claude Actually Did

1. Claude started explaining some of the concepts to me and how sensor fusion algorithms work
2. It explained the same thing once, and then kept repeating it

Example:

Your "if I'm tilted I can tell yaw" intuition is the geometric one: when tilted,
gravity in the world is not along my body z. True. But when you yaw (rotate
around world-z), you rotate the body without changing the angle between body and
world-z. The lean angle is preserved, just pointed in a different world
direction. In body coordinates, gravity stays in the same place.

Concrete: lean 30° forward (pitch). g_body ≈ [+0.5, 0, −0.866] — gravity has a
forward component in body. Now yaw 90° (rotate around world-z, keeping the lean).
You're still leaning 30° forward in your own body frame — your body x-axis still
points "downhill" by the same angle. So g_body is still [+0.5, 0, −0.866]. The
world direction your body x points has changed, but g_body hasn't.

That's why fusion algorithms can correct roll/pitch from accelerometers but not
the body without changing the angle between body and world-z. The lean angle is preserved,
just pointed in a different world direction. In body coordinates, gravity stays in the same
place.

Concrete: lean 30° forward (pitch). g_body ≈ [+0.5, 0, −0.866] — gravity has a forward
component in body. Now yaw 90° (rotate around world-z, keeping the lean). You're still
leaning 30° forward in your own body frame — your body x-axis still points "downhill" by the
same angle. So g_body is still [+0.5, 0, −0.866]. The world direction your body x points has
changed, but g_body hasn't.

That's why fusion algorithms can correct roll/pitch from accelerometers but not yaw: the
accel reads g_body, and g_body carries no yaw information.

R_z(ψ)ᵀ · [0,0,−1] = [0,0,−1]
Therefore g_body = R_tiltᵀ · [0,0,−1] — a function of tilt only, not of yaw.

Your "if I'm tilted I can tell yaw" intuition is the geometric one: when tilted, gravity in the world is not along my body z. True. But
when you yaw (rotate around world-z), you rotate the body without changing the angle between body and world-z. The lean angle is preserved,
just pointed in a different world direction. In body coordinates, gravity stays in the same place.

Concrete: lean 30° forward (pitch). g_body ≈ [+0.5, 0, −0.866] — gravity has a forward component in body. Now yaw 90° (rotate around
world-z, keeping the lean). You're still leaning 30° forward in your own body frame — your body x-axis still points "downhill" by thesame
angle. So g_body is still [+0.5, 0, −0.866]. The world direction your body x points has changed, but g_body hasn't.

That's why fusion algorithms can correct roll/pitch from accelerometers but not yaw: the accel reads g_body, and g_body carries no yaw
information.

Why the IMU's gyro is yaw-clean too

Gyro measurements are in the physical IMU sensor frame, which is the torso body frame (rigid mount). The orientation-tracker drift does not
touch the gyro samples — those are direct measurements off a spinning-mass / vibrating-structure rate sensor, regardless of what the
orientation tracker "thinks" yaw is. So ang_vel_T_T arriving at the network is the true body-frame angular velocity (modulo gyro bias, not
yaw drift).

So at deployment

• ang_vel_T_T: physically in body frame. Correct.
• projected_gravity_T: in body frame, depends only on tilt — identical whether or not the IMU's orientation has drifted in yaw.

Concrete: lean 30° forward (pitch). g_body ≈ [+0.5, 0, −0.866] — gravity has a forward component in body. Now yaw 90°
(rotate around world-z, keeping the lean). You're still leaning 30° forward in your own body frame — your body x-axis
still points "downhill" by the same angle. So g_body is still [+0.5, 0, −0.866]. The world direction your body x
points has changed, but g_body hasn't.

same angle. So g_body is still [+0.5, 0, −0.866]. The world direction your body x points has changed, but g_body hasn't.

That's why fusion algorithms can correct roll/pitch from accelerometers but not yaw: the accel reads g_body, and g_body carries no yaw
information.

Why the IMU's gyro is yaw-clean too

Gyro measurements are in the physical IMU sensor frame, which is the torso body frame (rigid mount). The orientation-tracker drift
the same angle. So g_body is still [+0.5, 0, −0.866]. The world direction your body x points has changed, but g_body hasn't.
same angle. So g_body is still [+0.5, 0, −0.866]. The world direction your body x points has changed, but g_body hasn't.

That's why fusion algorithms can correct roll/pitch from accelerometers but not yaw: the accel reads g_body, and g_body carries no yaw
information.

Why the IMU's gyro is yaw-clean too

Gyro measurements are in the physical IMU sensor frame, which is the torso body frame (rigid mount). The orientation-tracker drift
does not touch the gyro samples — those are direct measurements off a spinning-mass / vibrating-structure rate sensor, regardless of
what the orientation tracker "thinks" yaw is. So ang_vel_T_T arriving at the network is the true body-frame angular velocity (modulo
gyro bias, not yaw drift).

So at deployment

• ang_vel_T_T: physically in body frame. Correct.
• projected_gravity_T: in body frame, depends only on tilt — identical whether or not the IMU's orientation has drifted in yaw.

Expected Behavior

Only explaining it once

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

_No response_

Claude Model

Opus

Relevant Conversation

Impact

Low - Minor inconvenience

Claude Code Version

2.1.131

Platform

Anthropic API

Additional Context

It happened in the same conversation on the previous prompt already once, but only repeated a couple of times, I ignored it.

I remember it had also happened a few days ago, but couldn't find the chat, it was minor though.

The content of the conversation was completely different back then, and in this case it isn't really relevant for the issue, it's the repetition pattern that is unusual and frustrating since it makes me waste tokens for the same thing over and over