DEV Community: orca forge

Why gpu-unlock Speeds Up RTX 3090 Prefill but Barely Changes Decode

orca forge — Mon, 26 Oct 2026 13:03:59 +0000

TL;DR gpu-unlock changes FP16/BF16 instruction throughput on some RTX 3000-series GeForce cards. An RTX 3090 report measured 33% faster vLLM prefill and 24% less time to the first token. Decode changed by only 1.2%, because it is limited by memory bandwidth.

What Was Being Held Back

According to the README, the affected cards are RTX 3000 series GPUs based on GA102, GA103, GA104, and GA106. It says the unlock doubles the instruction issue rate for FP16/BF16 multiply-accumulate operations using FMA, where the results are accumulated in FP32. In the README’s words, this makes them “as fast as their professional equivalents.” It does not speed up the whole GPU; only this type of operation gets faster. README

According to the explanation of how it works, the signed firmware that runs during Ampere startup—the Booter running on SEC2—has a buffer overflow vulnerability. This can be used to execute code via ROP. Through that path, the module changes write permissions for registers that drivers normally cannot write to, then changes the value that controls the instruction issue rate. The rate is selected using a 4-bit value, with options such as full speed and half speed. How it works

The module is loaded before the NVIDIA driver connects to the card. It changes the setting, performs an FLR (a per-card reset), and then hands control to the unmodified driver. It is neither a UEFI app nor a modified driver. For that reason, the README says there is no need to reapply patches every time a new driver comes out. The module only runs when the target card is specified on the kernel command line; removing that setting restores the original behavior. README

What Gets Faster—and What Doesn’t

The top of the README lists numbers for an RTX 3090 Ti. They are the median of five runs of a dense 8192³ GEMM at 450 W, with results accumulated in FP32.

Numbers in the README (reported in issue #1)	Before	After
FP16	87.46 TFLOPS	118.39 TFLOPS
BF16	87.50 TFLOPS	157.41 TFLOPS
TF32	42.58 TFLOPS	82.61 TFLOPS

These numbers weren’t measured by the repository’s author. They came from someone who posted in issue #1 and tested an experimental fork with RTX 3090 Ti support. The setup included a “modified NVIDIA 610.43.02 driver” and a custom startup script. The same issue also reports tests with the unmodified package and a standard driver. In those tests, BF16 performance rose from 63.0 to 105.9 TFLOPS. However, the power limit also changed from 300 W to 380 W, so the conditions weren’t the same before and after.

A GEMM speedup doesn’t translate directly into an application speedup. The README says workloads with a lot of matrix computation get faster. It lists LLM prefill, image generation (diffusion), and FlashAttention. LLM decode is limited by memory bandwidth, so it barely changes. INT8 computation is also unchanged. One report comparing outputs found them identical down to the bit. README

Reports from users show a more nuanced picture:

A vLLM report showed prefill getting 33–36% faster, with similar results at 8K, 32K, and 128K context lengths. issue #15
On the same card, a GGUF engine showed no change at 8K and a 12–13% speedup at 32K and 128K. The reporter noted that gains depend on the engine and kernels, and that short prompts may see no change at all. issue #15
Two reports on an RTX 3090 showed 14–16% faster prefill at 16K, with no change at 4K. One MoE model showed no change with a very long prompt of around 32K, because loading experts from RAM took longer. issue #9 issue #33
Decode was within the margin of error in every report. INT8 GEMM also showed no change in reports that measured it for comparison. issue #15 issue #33

Another factor affecting the results is the power limit. During GEMM, the card stays at its power limit, so the clock drops when it does more work per clock cycle. In one report with the limit set to 220 W, the SM clock fell from about 1,720 MHz to about 1,330–1,365 MHz. Even with roughly 1.9× more work per clock cycle, the real-world speedup doesn’t reach that level. The README also notes that its smallest gain, +25%, came from a card capped at 225 W. issue #15 README

Which Cards Have Been Reported

The compatibility table in the README summarizes reports from users. The reported BF16 GEMM gains come from different benchmarks, so they can’t be compared side by side.

Card	BF16 GEMM gain (reported)	Source
RTX 3090 Ti	+68–80%	#1
RTX 3090	+25–67%	#9 #25 #33 and others
RTX 3080 Ti 20 GB (OEM)	Some reports say it remains at half speed; others report about 2×	#28
RTX 3080 10 GB	+70–73%	#14
RTX 3080 20 GB (memory-modified)	+56–59%	#10 #15
RTX 3070	+73–81%	#10 #12
RTX 3060 12 GB	About +80%	#13 #31

The RTX 3070 Ti has not been tested with this module. There are no reports yet for GA103 cards.

The results are mixed for the OEM RTX 3080 Ti 20 GB. In the first report, the unlock appeared to succeed and the setting’s value remained changed, but BF16 was still running at half speed. Downgrading the driver to 610.43.03 raised performance to about 65% of full speed, but it still didn’t reach full speed. Another user with two cards of the same model reported about 2× performance with driver 610.43.03. The other card, which was not unlocked, remained at its original speed. The two users’ cards have different board IDs. As of October 26, the cause is still unknown. issue #28

Things to Consider Before Installing

This article doesn’t cover the installation steps. Please read the README. Instead, here are the points that stood out to me after reading the primary sources.

The primary sources say nothing about warranty coverage. Check with your card’s manufacturer or retailer.

The boot process also changes. In the reports I read, everyone had Secure Boot disabled. Because this loads an unsigned kernel module, the kernel is marked as tainted. issue #9 issue #25 Whether you can unlock the card again after a warm reboot depends on the board. Some users report success, while others only use it after a cold boot. issue #1 issue #25 You can also use it with a card that’s driving a display. However, the screen goes blank between the reset and when nvidia-drm takes over. You’ll need to unlock the card again after resuming from suspend, and hibernation isn’t supported. README

Its relationship to NVIDIA’s terms is unclear. The firmware used by the module is extracted from the NVIDIA driver package and is subject to the NVIDIA driver license agreement. The NOTICE states that permission to redistribute it publicly has not been obtained. The primary sources I read contain no record of NVIDIA commenting on this module. The mechanism itself exploits a vulnerability in NVIDIA-signed firmware. firmware/NOTICE.md

Power consumption and stability are also worth considering. As noted above, gains are small when the power limit is low. Reported figures with a higher limit vary widely in their testing conditions. The longest stability report describes more than eight hours of mixed workloads without errors. issue #25 Another user wrote, “a few hours, not weeks.” issue #33 We still don’t know what happens with long-term use.

Key takeaways

Measure whether prefill or decode is the source of your wait time.
Compare reports with similar cards, power limits, drivers, and engines.
Do not expect decode token/s to improve from this module.
The README lists image generation as a workload, but the issues reviewed here provide no before and after performance numbers.
Check Secure Boot requirements, kernel tainting, and the limited long-term stability reports.

How to Catch Japanese Text in Automated dev.to Crossposts

orca forge — Mon, 26 Oct 2026 13:01:18 +0000

TL;DR A Japanese blog was translated and automatically posted to dev.to, but its title and description remained in Japanese. The English body and generated devto.md made the post look ready, so the check for total translation failure did not stop it. A pre-post check now inspects the title, description, body, and tags, while people still review meaning and numbers.

When the Body Is in English, It Slips Through

If translation failed, no file for posting was created. That safeguard existed. But it only stopped the process when the entire translation failed and no file was produced.

In a case like this one, the body was in English while only the title and description remained in Japanese. The English body had been generated, and so had devto.md. From the perspective of the downstream crosspost.mjs, it looked like a post-ready article was available.

The rule “don’t create the file if English translation fails” assumed that failure would affect the article as a whole. In reality, each field could succeed or fail independently. The body could be translated while the title and description were left behind. There was no check to catch that partial success.

It wasn’t just the title. The article also had a Japanese table and timeline inside a code block. For example, this section with the numbers:

YouTube Shorts
  Impressions        Approx. 2,900
  Views                       279   (continued viewing: 9.5%)
  Average view duration      0:13   (about 85% of a 15.3-second video)

Even when the body paragraphs had been translated into English, blocks like these weren’t necessarily in English too. Code blocks aren’t only for programs; they can also contain logs, tables of numbers, and processing timelines. Reading just some of the visible paragraphs wasn’t enough to know the state of the article as a whole.

The English Translation Had Other Errors, Too

The articles I reviewed around the same time also contained mistranslations in the body text.

The output token count, “134万” (1.34 million), had become 134,000 in English. “二次関数的に膨らむ” (grow quadratically) had been translated as exponentially, and “制限にはかかっていません” (it is not subject to the limit) as it is not being used. Even when the meanings seem close, they do not describe the same state or value.

The code block language tags were wrong, too. Every log or text block was tagged python. Checking only whether the text had become English could not tell us whether the numbers were preserved, the meanings were accurate, or the block types were correct.

There were limits to checking translation success with a single indicator. The fact that a file had been created did not mean that every part of the article had been translated correctly.

Natural-Sounding English Errors Can’t Be Found by Checking the Characters Alone

On October 2, 2026, a person spotted and corrected another article’s title before it was published.

The article was about classifying utterances, not speech recognition. The English phrasing wasn’t unnatural. That’s exactly why checking only for leftover Japanese characters can’t catch this kind of error. The tags also contained the same value twice: "llm, llm".

A person caught the title before it went live. That made one thing clear: if we rely on pre-publication review, we could miss another error. We need to catch leftover Japanese, but we also need to block anything we can validate mechanically at the entry point to the publishing process.

Still, character checks can’t catch every mistranslation. Speech Recognition is natural English. The number 134,000 also looks like a natural English number. Checking only the character types won’t reveal a mismatch with the original meaning.

Inspect the Article Itself Right Before Posting

On October 3, 2026, I added a pre-post check to crosspost.mjs. It checks the title, description, body, and tags in the actual devto.md being sent—not whether the translation process succeeded.

If the title or description contains hiragana or katakana, the post is held. If any Japanese remains at the point of posting, it is not sent as is. For the body, the check excludes code blocks and inline code, then holds the post if three or more lines contain kana or katakana.

The body threshold is not zero. It allows one or two lines of Japanese, such as in data examples or quotations. Code blocks and inline code are also excluded from the body check. That way, Japanese characters or values there alone are not treated as a translation failure across the entire body.

The check also holds the post if tags are duplicated. When a post is held, the reason is logged and a notification is sent to the Mac. If the content has been reviewed, it can still be posted with --force. After automatically stopping a post, there’s still a way to review the content and let it through.

Results from Checking 94 Articles

After adding the checks, I reviewed 94 existing articles. None had Japanese text left in their titles or descriptions.

This means no Japanese text was found in the titles and descriptions of the 94 articles reviewed. It does not mean there were no mistranslations in the body text or that all the numbers were correct. We need to distinguish what the checks can verify from what still requires a person to read and review.

This setup can catch hiragana or katakana in titles and descriptions, substantial amounts of hiragana or katakana left in the body text, and duplicate tags. It cannot identify mistranslations that read naturally in English or numbers that have been transcribed incorrectly. A person still needs to read the articles to check for those issues.

This check also cannot detect text embedded in PNG diagrams, so the text in those diagrams remains in Japanese. If we create diagrams in SVG or HTML, we can replace the text and export English versions. We have decided to take that approach, but the process for creating English diagrams has not yet been implemented.

Key takeaways

Check the title, description, body, and tags in the output immediately before posting.
Hold posts when the title or description contains hiragana or katakana, or when three or more body lines contain them outside code.
Hold duplicate tags, log the reason, and send a Mac notification; reviewed posts can be sent with --force.
Human review is still needed for mistranslations and number changes that look natural in English.
The check does not inspect text embedded in PNG diagrams; the English diagram workflow is not implemented yet.

How to Recover 13 Deleted DNS Records in 11 Minutes

orca forge — Mon, 26 Oct 2026 13:00:03 +0000

TL;DR We selected a live domain beside the intended domain in the DNS management UI and deleted 13 records. AXFR was refused, but the pre-deletion list and authoritative DNS data were still available. We enumerated names, queried them with dig, cross-checked public DNS caches, and manually restored the records in about 11 minutes.

Conclusion First

If you accidentally delete DNS records, the last known list and values retrieved from the authoritative DNS server (the server that returns the domain’s official DNS information) can help you restore them. AXFR was refused in this case, but by enumerating names, querying them with dig, and cross-checking public DNS caches, I manually restored 13 records in about 11 minutes.

Where the DNS Records Were Before Deletion

Thirteen records were deleted: 11 A records, one CNAME record, and one MX record. The recovery source was a complete list that another operator had copied from the management console just before deletion. They were working in a separate AI session.

After deletion, it becomes difficult to remember the original values one by one. In this case, the list had been saved, so there was enough information to re-create all 13 records manually.

However, the list alone could not confirm the state of the authoritative DNS. Immediately after the deletion request was submitted, the update to the authoritative DNS was delayed. Running dig still returned every record that existed before deletion.

How I Verified Every Record After AXFR Was Denied

The AXFR request to transfer the entire DNS zone was denied. So I enumerated the names and queried them with dig, then checked the results against a recently copied list and the records retrieved from the authoritative DNS server.

I also compared them with public DNS caches—temporarily stored DNS information. I used results from 8.8.8.8 and 1.1.1.1 to double-check, and verified what was visible through those separate caches instead of relying only on the list retrieved from the authoritative DNS server.

I had three sources to guide the manual restoration: the surviving list, the full set of records retrieved from the authoritative DNS server right after deletion, and the public DNS cache results.

Verifying Recovery Time Using TTL and SOA Serial

The A record’s TTL (the length of time DNS information is kept in cache) was 3,600 seconds, and the negative cache TTL (how long a “does not exist” response is cached) was 300 seconds. The SOA serial (the zone’s update number) showed that the zone became empty at 10:06 and was restored by re-registration at 10:17. According to the records, recovery took about 11 minutes.

Recovery depended on more than the TTL values. Even after deletion, we could retrieve all records from the authoritative DNS server and compare them with the previous list and the results from public DNS caches. This let us verify what to enter manually.

We didn’t undo the deletion in the admin console. Instead, we gathered information to verify the records and re-registered them manually. Because the original values were still available, we could proceed.

How to Avoid Accidentally Deleting DNS Records

This mistake happened while I was working with domains that had similar names on the same screen. I meant to delete an unused domain, but selected the adjacent one that was still active. The lesson: don’t manage similarly named domains on the same screen, and export the entire zone before deleting anything.

Even when you try to retrieve every record in a zone with AXFR, the request may be denied. That happened here, so I enumerated the names and queried them with dig. Keeping a copy of the list before deleting records means you won’t have to start from scratch searching for their values afterward.

I restored everything in 11 minutes, not because I found a special recovery feature, but because I had a recently copied list, could retrieve every record with dig while the changes were still propagating to the authoritative DNS servers, and could cross-check the results against public DNS caches.

Key takeaways

Check for a pre-deletion record list in the management UI.
If authoritative DNS propagation is delayed, enumerate names and use dig to see whether all records can be retrieved.
Cross-check results against the public DNS caches at 8.8.8.8 and 1.1.1.1.
Manually re-register the verified values and check the time with the SOA serial.
Before the next deletion, identify the target domain and export the full zone.

Why MediaRecorder Turns a 190-Second Recording Into 92 Seconds

orca forge — Sun, 25 Oct 2026 13:19:57 +0000

TL;DR MediaRecorder delivers recording data in chunks, and processing them is asynchronous. If stopping closes the file before pending chunk sends finish, the final data is lost. Silent audio and a stop check that misses the studio avatar's voice can also cause empty files or cut speech.

Conclusion First

The reason a roughly 190-second recording with MediaRecorder lasted only 92 seconds was that the system didn't wait for the final chunk processing upon stopping, no audio data was sent during silence, and the stop logic did not account for the end of the studio-side audio. I implemented fixes to wait for the chunk transmission to complete, stream silence using a ConstantSource, and ensure the recording continues until the studio-side audio track has actually finished. After these fixes, a 60-second recording of silence was saved correctly with 60.49 seconds of video and 60.48 seconds of audio.

Why the last data was missing after stopping the recording

The reason for the missing last data was that the main side was notified of the recording stop before finishing processing the chunks.

MediaRecorder divides the recorded data into chunks and passes them on. Even after receiving a chunk, the process of converting its contents to a byte array is asynchronous (a method that proceeds to the next process without waiting for completion). Right before stopping, the last chunk had arrived, but I didn't wait for the processing to finish and notified the main side to stop the recording.

The main side receives the stop instruction and closes the file. Even if the chunk processing is completed afterwards, the destination for writing is already closed. Although it seems like the recording was working until the end, the last data is not saved.

In the fix, I processed the chunks in the order they were received and sent the next one after the previous chunk's transmission was completed. When stopping, I wait until all pending transmissions are finished. What was necessary was not the fact that the stop was called, but that the processing started before the stop was completed.

Why My 60-Second Voiceless Recording Resulted in a 0-Byte File

The reason the voiceless recording came out as a 0-byte file was that no data was flowing through the audio channel.

When I examined the case where I recorded for 60 seconds without any voice, I found that no audio data was being transmitted through the audio track used for the recording until a voice actually entered. With the audio input empty, the MediaRecorder did not write anything, resulting in a 0-byte file even after stopping the recording.

I had assumed that only the video was being captured. In reality, the recording input included an audio track (the audio data intended to be included in the recording), and this audio channel remained empty during periods of silence.

I connected a ConstantSource (an audio source that continuously outputs a constant value) to the audio channel, outputting a value of 0. This ensures that silent audio data is always flowing. The purpose is to continue passing the audio track to the recording even during moments when no voice is present. I discussed this mechanism in a previous article. What I discovered this time is that waiting for 60 seconds without any voice resulted in a 0-byte file, and that the root cause was the lack of incoming data on the audio channel. Even if the intent is to record video only, when using a recording setup that combines an audio track, the state of the audio input can significantly affect the final output.

Why the last voice of the studio-side avatar was cut off

The reason why the last word was cut off in the middle is that the recording stop judgment was not looking at the voice of the studio-side avatar.

The stop judgment was looking at the voice sounding in the avatar window on the desktop. However, the voice of the avatar that appears only on the broadcast screen is on the studio side. The window being looked at by the stop judgment does not have the end time of that voice.

I thought that if the side that determines the stop of the recording judges that "it's quiet now", it would also think that the voice on the studio side has ended. However, that premise was incorrect. Even just before stopping the recording, there were cases where the voice on the stage was still sounding. In fact, in a scene where the last word lasted for about 34 seconds, it was cut off after about 2 seconds.

So, I made the studio side have the end time of the voice for each avatar. When stopping the recording, it waits until the time when the last voice ends plus 1.5 seconds. However, this waiting time has an upper limit of 120 seconds. I also extended the main side's save wait time from 15 seconds to 150 seconds. This is to prevent the main side's wait from being cut off first while the studio is waiting for the end of the voice.

How the Recording Time and Audio Length Changed After Fixes

After the fixes, the video and audio lengths were almost aligned, and the final subtitles fit within the video.

Recording 60 seconds without speaking resulted in a video length of 60.49 seconds and an audio length of 60.48 seconds. A recording with six dialogue exchanges resulted in a video length of 171.42 seconds and an audio length of 171.37 seconds.

The alignment was achieved by revisiting the processing at three points before stopping the recording: waiting for chunk transmission, streaming silence in the audio path during silent periods, and waiting for the avatar's voice to end in the studio before deciding to stop. Fixing only one of these would still result in gaps in the remaining paths.

The recording time and the saved video length are not always the same. It was necessary to track not only the time when the stop was called but also the ongoing processes before and after, as well as which audio the termination judgment was monitoring.

Key takeaways

Process chunks in order and wait for all pending sends before stopping.
Feed silent data into the audio path with ConstantSource when no one is speaking.
Use the studio avatar's voice end time in the stop check.
Cap the studio wait at 120 seconds and extend the main save wait from 15 to 150 seconds.

Why a VRM Right Hand Disappeared: Empty Cuff Ring and NaN

orca forge — Sat, 24 Oct 2026 13:04:39 +0000

TL;DR A VRM export made only the right hand disappear, even across edits and poses. The shared cuff position found no right-hand vertices, leaving an empty ring. Its mean produced NaN values that spread to the pivot and finger bones.

Conclusion First

The disappearance of the right hand in the VRM was caused by the right hand's vertices failing to reach the common cuff position for both arms, which allowed NaN (Not a Number) values to propagate from an empty loop. We fixed this by ensuring that scaling transforms are not baked into the vertices, and by adding a safeguard that halts the process if NaN values are detected in empty loops or bones.

Was the Disappearing Right Hand a Display or Pose Issue?

On October 5 at 17:01 UTC, a user reported an issue: only the right hand was missing on screen, both in an unedited state and regardless of the pose. My first thought was that it was a visibility toggle or posing issue.

When I inspected the VRM exported at 17:11 UTC, the Hands mesh had 1,462 vertices. Of those, 711 vertices—accounting for the entire right hand—had their positions set to NaN. The renderer simply doesn't draw vertices with NaN coordinates. The invisible hand wasn't a rendering bug after all.

Initially, I checked component visibility toggles, edit operations, weight sources, poses, and culling. (Weights define how much a bone influences vertices.) The hand's scale was also set to 1. None of these were the culprit.

At which stage was NaN born?

I investigated the pipeline—the processing flow up until export—stage by stage. The files were normal up until the manual adjustment stage. Starting from the files in the synchronization stage, the rest matrix (a matrix representing the reference pose of the bones) and lengths for the 15 bones of the right finger were NaN.

NaN did not suddenly appear during export. Even before the synchronization stage, the input for the coordinate generation process was already corrupted.

Why the Ring at the Cuff's Vertex Became Empty

The data before modification was normal. The change began with the influence of the 3D editing done afterwards.

In the modification, a shrink transformation was attached to the Hands object. In world coordinates (coordinates based on the entire scene), it changed from -0.586 to +0.662, and the right hand was shifted about 7cm inward.

After that, step 1 of replacing the head bakes the transformation of all objects into the vertices. Baking refers to the process of reflecting the transformation attached to an object into the vertex coordinates. Although step 2 of synchronization also has a process called matrix_world = Identity, it is after baking, so the transformation cannot be restored here.

The problematic calculation was in step 6. The cuff position was determined by a common value for both left and right sides.

cuff = max|x|  # approximately 0.63
x_start = approximately 0.61

The right hand only reaches up to -0.586. Even if we search for vertices on the cuff side from approximately 0.61, there are no corresponding vertices for the right hand. The ring (a collection of vertices along the cuff) on the right became empty.

Taking the average of an empty ring results in NaN. The pivot (the reference point for transformation) becomes NaN from that value, and NaN spreads to the 15 bones of the right fingers as well. The direct cause of the destruction of 711 vertices was handling different ranges on the left and right with a common cuff value.

How to Stop the Empty Loop and NaN in Bones

The correction was done in two stages.

In the stage of replacing the head, the hands are excluded from the conversion target. The reduction that was attached to the hands was prevented from being baked into the vertices.

In the synchronization stage, a process was added to raise a RuntimeError if the loop is empty. Furthermore, if there is an NaN in the bones, it is stopped by an assert (a check that confirms the condition and stops the process if it is not met). This is to detect abnormal values before proceeding and exporting VRM.

Re-execution took real 0m21.657s and exited with 0. The log output included "hands ×0.924 (from sleeve to fingertips 0.134 m)". In the confirmation output, the number of NaNs in the 1462 vertices of the Hands mesh was 0.

It was confirmed that the hands were restored. However, this alone did not reveal other problems in the processing system.

Why Python Errors Don’t Stop Execution in Our Pipeline

In a related log from another day, a 3D editing application was returning exit code 0 despite encountering Python errors. Relying solely on the exit code meant the calling process couldn’t detect the anomaly.

On 10-06, I added --python-exit-code 1 to some steps. By 10-07, all steps were routed through a common function, using both --python-exit-code 1 and set -e -o pipefail. The grep command for log verification was wrapped in { grep … || true; } to prevent the entire process from halting if no results were found.

Additionally, I introduced a FAIL_AT=<step> option for testing. Setting FAIL_AT=ring intentionally triggered a failure, confirming that the process stopped with exit code 1 and subsequent steps were skipped.

This exit code issue is separate from the problem of the missing right hand. However, if a pipeline detects an anomaly but continues processing, corrupted values will propagate downstream. It’s essential not only to log errors but also to ensure the process halts at the correct point when anomalies occur.

How to Verify Values Are Created at the Right Stage

Simply chasing NaN vertices didn't lead to the root cause of the disappearing right hand. It was only after comparing each stage in order—applying transforms, baking transforms, and defining the cuffs—that I finally tracked it down to an empty loop.

When processing values shared between the left and right sides, you can't assume both sides will have the same range of data. To fix this, I made sure the calculation aborts if the loop is empty and added validation for the bone values as well.

Finally, I intentionally induced failures to confirm whether the pipeline truly stops when a step returns an error. The fix wasn't complete just by bringing the right hand back; it was about ensuring we never miss an anomaly the next time one occurs.

Key takeaways

Check whether the issue affects only the right hand and reproduces across edits and poses.
Check the exported VRM Hands mesh for NaN values.
Compare files before hand editing, after transform baking, and at the sync stage.
Stop when the cuff ring is empty, and check bones for NaN values.
Make Python errors return exit code 1 and confirm later pipeline steps do not run.

Why uvx MCP servers fail with Pydantic 2.14

orca forge — Fri, 23 Oct 2026 13:07:17 +0000

TL;DR: Older mcp<1.10 servers load Pydantic's internal eval_type_backport function.
Pydantic 2.14 no longer has that function, so startup fails with an ImportError.
Add --with "pydantic<2.14" to the applicable uvx configuration, then check each server's initialize response after reconnecting.

Conclusion First

Old mcp<1.10 MCP servers started with uvx fail to launch due to ImportError: cannot import name 'eval_type_backport' with Pydantic 2.14. Add --with "pydantic<2.14" to pin Pydantic below 2.14, then reconnect and verify the per-server initialize response.

Why Pydantic 2.14 Causes an ImportError

The target server was pinned to mcp<1.10, which belongs to an older mcp release line. The constraint mcp<1.10 specifies using a version lower than 1.10. This version line imports an internal function called eval_type_backport from Pydantic. However, that function was removed in Pydantic 2.14.

As a result, the server fails with an ImportError when attempting to import the missing function. Both the SQLite and Hacker News configurations where this error occurred were being launched via uvx.

The workaround is to pin Pydantic to below 2.14 in addition to the older mcp version. Add the following flags to your configuration:

--with "mcp<1.10" --with "pydantic<2.14"

The new addition here is pydantic<2.14. The mcp<1.10 constraint was already in place to maintain compatibility with older servers.

Adding Pydantic <2.14 Specification to uvx Arguments

If you're separating commands and arguments in configuration screens, add --with and the package specification to the uvx arguments. For a SQLite server, for example, it would look like this:

command: uvx
args: ["--with", "mcp<1.10", "--with", "pydantic<2.14", "mcp-server-sqlite", "--db-path", "<SQLite DB path>"]

Replace <SQLite DB path> with the location of your existing database. In the startup arguments, pass this value after --db-path.

Apply the same fix to the Hacker News server. The package name to start is mcp-hn.

command: uvx
args: ["--with", "mcp<1.10", "--with", "pydantic<2.14", "mcp-hn"]

If --with "mcp<1.10" is already present, leave that specification as is and add --with "pydantic<2.14". Review the entire configuration to ensure there are no duplicate Pydantic version pins.

Verify MCP Server `initialize` Response After Reconnection

After saving your configuration, reconnect to the target MCP server. A simple "connected" status doesn't confirm that the initialization request (initialize) was successful. You'll need to verify the response on the client side.

Check SQLite and Hacker News separately. Even if one initializes successfully, it doesn't guarantee the other has as well. If errors disappear and both respond to initialization, you've avoided the startup ImportError.

If you want to verify using only locally available dependencies, you can use uvx --offline. Our records show that both SQLite and Hacker News respond to MCP initialization offline. However, this method may not work in environments without locally installed packages.

Which Existing Configurations to Add Pydantic Specifications To

Some older configurations only pinned mcp<1.10. In those cases, add the Pydantic specification. However, for configurations where users have already specified their own Pydantic version, do not alter that value.

The target for modification is configurations that start with uvx, include --with mcp<1.10, and do not yet have a Pydantic specification. Only add it to servers that meet these conditions. Do not mechanically apply the same change to configurations with different startup commands or those that already specify Pydantic.

This error was related to compatibility between dependency packages rather than the server's startup command itself. When eval_type_backport is not found, check if an older version of mcp is being used. If so, pin Pydantic to below 2.14 and verify the initialize response for each server.

Key takeaways

Check that the affected server starts with uvx and specifies mcp<1.10.
Add --with "pydantic<2.14" only when the configuration has no Pydantic version specified.
Reconnect and check the initialize response for SQLite and Hacker News separately.
Use uvx --offline to check with local dependencies when available.

Why Ollama Tool Calls Fail at a 4,096 Context Length

orca forge — Thu, 22 Oct 2026 13:07:46 +0000

TL;DR The app passed 29 tools and expected a context window of 16,384, but the model ran at 4,096. The OpenAI-compatible API path did not apply the expected window during model loading, and oversized input was truncated without a 400 response. Routing tool calls through /api/chat and setting options.num_ctx to 16,384 aligned the request path with the model context setting.

Conclusion First

In Ollama, the tool wasn't invoked, and the response was cut off mid-way. However, when using the OpenAI-compatible API (a connection method that sends requests in OpenAI's API format), the input was truncated from the beginning without returning a 400 error. The cause was that the window, which was expected to be 16,384, wasn't reflected when loading the model, and it was actually running with the default value of 4,096. I also sent the tool invocation to /api/chat and verified by specifying options.num_ctx (the context window setting value passed when loading the model) as 16,384.

Why Didn’t I Get a 400 Error and Couldn’t Pinpoint the Cause?

Initially, I thought the tool descriptions were too long and assumed reducing their number would solve the issue. Previously, I fixed a case where a 400 error was returned when the context window was exceeded. From the error message, I remembered the window size and reduced the number of tools in the next request. Additionally, if the window was exceeded, I truncated the old results and resent them.

With this mechanism, a 400 error could serve as a clue. However, in this case, no 400 error was returned, and even reducing the tools didn’t clarify what was happening. I couldn’t determine whether the model wasn’t calling the tools, the tool definitions weren’t reaching it, or the conversation history was being cut off midway—the response alone didn’t provide enough information.

So, I suspected that the estimated window size might be too small and investigated how the app determined this value.

Why the limit changed from 16,384 to 4,096

In our initial window estimation, we compared the value obtained from the model information with 16,384 and used the smaller of the two. Since the model information specified 262,144, the app was expected to use 16,384. Here, tokens refer to the units the model uses to process text.

However, when the model was actually loaded, the context_length was 4,096.

This wasn't just a simple estimation error. In the OpenAI-compatible API /v1/chat/completions, the expected window value was not being reflected in the model loading. The model was running at the default of 4,096.

Furthermore, when the window limit was exceeded, Ollama did not return a 400 error; instead, it silently truncated the input from the beginning. In other words, the signal the system relied on—"seeing a 400 to remember the window size"—never arrived, and the process to filter down the tools never began.

The mere fact that we passed 29 tools wasn't enough to realize the cause. The number of tools passed during transmission and what the model was actually able to read were two different things.

How I fixed the tool call destination

Simply changing the window size on the application side wasn't enough; I had to rethink the entire path through which tool calls are sent.

In this fix, tool calls are sent to /api/chat. Along this route, I specify options.num_ctx as 16,384 and pass the window value when the model is loaded.

If I had only toggled the regular conversation and left the tool usage logic on the old route, the same issue would persist. Therefore, I moved the tool calls through /api/chat as well, converting the arguments and history to match the expected format of the destination. I avoided specifying tool_choice: required, as Ollama does not support it.

With this, I synchronized the window estimation with the actual loading settings using the same path.

Did it reach the end after specifying 16,384?

In the post-fix verification, I was able to specify 16,384 for the context window, and the 400 errors were zero. I was also able to pass all 29 tools.

The logs show that the process progressed from tool calling to searching and retrieval, through to the final response. Unlike before, I did not need to wait for errors before reducing the number of tools.

What I confirmed here is that the window specification and tool transmission are working as intended. However, simply fixing the window size does not guarantee the model's response content or speed. Differences in responses will remain depending on the specific model.

Initially, I was looking for the presence of the 400 error. However, in this path, a 400 is not generated even if the input is truncated. The absence of an error was not evidence that the entire input had arrived.

When investigating issues with tool calls, in addition to estimating the window size, I verify the actual transmission path and the specified values. The value obtained from model information and the value used during loading are not necessarily the same. If the ability to specify the window varies by the destination, I align the path, including the number of tools.

Key takeaways

Check the window value from model information.
Check context_length when the model loads.
Verify the tool call route and whether it sets the context window.
Route tool calls through /api/chat and set options.num_ctx to 16,384.
After the change, check the 400 count and the record from tool call through final response.

How to Check Your Mac for the LiteLLM 1.107.0 Compromise

orca forge — Wed, 21 Oct 2026 18:47:46 +0000

TL;DR: LiteLLM 1.107.0 distributed through PyPI was tampered with. On a Mac, check the installed version in each Python environment, then search for three files and indicators of infection. The article also explains why Spotlight can miss files and how to distinguish a malicious sitecustomize.py from a legitimate one.

Conclusion First

The affected environments are those where the tampered version 1.107.0 was installed. To verify this, check the installed version, three specific files, and the infection markers. If the compromised version was present, simply deleting the files and processes is not enough; you must also rotate any secret keys or tokens that were readable from the terminal.

Which Version is Dangerous?

The affected package is litellm==1.107.0 on PyPI. Both the sdist and wheels for Linux, macOS, and Windows were compromised. It was published around 20:39 JST on October 21 and removed from PyPI around 22:40 JST.

After learning about the news, I separately checked my own gateway and an AI tool that depends on LiteLLM. First, I verified the version in each Python environment. Assuming the virtual environment path is <venv>, you can run:

<venv>/bin/pip show litellm

Check the line starting with Version:. If pip show isn't available, the name of the litellm-*.dist-info file in the environment's site-packages directory can also provide a clue.

In my gateway, I found litellm-1.92.0.dist-info. I also checked another tool and uv's cache, both of which were at version 1.92.0. Once the version is confirmed, ensure that the startup script doesn't automatically update the package. My startup script only included logic to run LiteLLM in the virtual environment, with no installation or update processes.

Where to Find the Three Files

Malicious files are installed in Python's site-packages. Their names are cook.pth, cook.py, and sitecustomize.py. Since .pth and sitecustomize.py are loaded when Python starts, they may work even in processes that do not import LiteLLM.

On a Mac, you can also try searching with Spotlight.

mdfind -name cook.pth
mdfind -name sitecustomize.py

However, even if nothing is displayed, it does not necessarily mean that the files are not present. This is because Spotlight (mdfind) does not search hidden folders like .venv, ~/.cache, or ~/.local. I also did not get any results with Spotlight. Next, I used find to directly search my home directory, Python installation location, Homebrew location, and other places.

find ~ /opt/homebrew /usr/local /Library/Frameworks/Python.framework \
  \( -name "cook.pth" -o -name "cook.py" -o -name "sitecustomize.py" -o -name "litellm-*.dist-info" \) \
  -print 2>/dev/null

Searching a wide range of targets can take a long time. Excluding large folders like photos, videos, and iCloud using -prune can speed up the search. Be sure to include the locations where you installed Python and the cache used by tools in your search targets. The same approach applies to Linux; just replace the Mac-specific search locations with the locations where you installed Python and tools in your Linux environment.

What to Look for If You Find sitecustomize.py

Just seeing the filename sitecustomize.py isn't enough to determine whether a machine is infected. I found five instances of it on my system, but they turned out to be part of legitimate tools and standard Python environments. Instead of relying on the filename alone, you need to check the file's hash and contents.

Calculate the SHA-256 hash for each file using the following command:

shasum -a 256 /path/to/sitecustomize.py

Compare the resulting value against the malicious file hashes published in SafeDep's analysis report. I won't list the hashes in this post, but the analysis report contains the full list of malicious hashes along with more details.

Next, search the file's contents:

grep -i -E "remote_code_loader|PRIVCOLLECT|litellm\.dev" /path/to/sitecustomize.py

None of the five files I found matched the malicious hashes in the report, nor did they contain any of the indicator strings searched above. When inspecting these files, don't jump to conclusions based on the filename alone—always verify it alongside the hash and contents.

Checking for Marker Files and Processes

Next, we confirm the signs of sent stolen data and the operation of resident processes.

ls -la /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock

We do not finish our judgment just because neither of them exists, and we also investigate the processes. The sitecustomize.py at the time of infection creates a resident process that is separated from the parent process. One of the conditions for the marker is "the parent is a Python process with PID 1".

ps -axo pid,ppid,lstart,command | awk '$2==1' | grep -i python

Here, we would like to note that even if the parent has PID 1, it does not necessarily mean it is suspicious. A process that is resident with launchd also has a parent with PID 1. Please check the command line in the output and confirm whether it is a process you started. In my case, the Python process with PID 1 as its parent was a gateway started by launchd.

Verify Environment Variables and Communication as Well

We also look for the environment variable PRIVCOLLECT_ACTIVE=1 as a landmark. Since macOS does not have /proc, we check the environment variables of processes using ps eww -ax.

ps eww -ax | grep "[P]RIVCOLLECT_ACTIVE=1"

At first, I ran ps eww -ax | grep -c PRIVCOLLECT_ACTIVE and was surprised to find the result was 2. This was because grep itself and the line of the shell command that included the search command were being counted. When I re-counted, excluding the line of the search command, the result was 0. By writing the first character as [P] as shown above, grep itself does not match. Please check not only the count but also the contents of the displayed lines.

If you want to investigate the communication destination, you can do so as follows:

lsof -i -n -P | grep -i python

I confirmed that the only listener was 127.0.0.1:4000. We make a judgment based on the combined results of these verifications.

What to do if you had version 1.107.0

The malicious code steals SSH keys, cloud credentials, AI tool tokens, passwords and history stored in browsers, environment variables, and API keys located in the LiteLLM proxy database, sending them to the attacker's server. The domain mentioned in the analysis report is www.litellm[.]dev. This is not the official LiteLLM domain.

If you had version 1.107.0 installed, simply deleting the three files is insufficient. You must stop any resident processes, delete the marker file, and treat all secrets readable from that terminal as compromised. You will then need to regenerate your SSH keys, cloud keys, AI tool tokens, saved passwords, and API keys for the various services. For a detailed analysis and the hashes of the malicious files, please refer to the SafeDep analysis article.

I did not find version 1.107.0 in the environments I investigated, nor could I confirm the presence of the three files or the marker. Since LiteLLM was installed across multiple environments, I did not stop after looking at just one virtual environment; I also investigated the tool's environments and caches.

Key takeaways

Check each environment with pip show litellm or look for litellm-*.dist-info.
Use find to search for cook.pth, cook.py, and sitecustomize.py; continue if Spotlight finds nothing.
Compare sitecustomize.py hashes and contents with the analysis article; do not judge by filename alone.
Check the two indicator files, PRIVCOLLECT_ACTIVE=1, and Python processes with parent PID 1; inspect the command line when PID 1 is the parent.
If 1.107.0 was installed, stop the process and rotate keys or tokens for secrets the machine could read.

Why codesign Fails After Copying a Mac App from a DMG

orca forge — Wed, 21 Oct 2026 13:01:15 +0000

TL;DR The app showed “is damaged and can’t be opened” after distribution. Four Japanese filenames containing dakuten changed from NFC to NFD after copying from the DMG. That made the copied names differ from the names sealed by the signature, so codesign verification failed.

TL;DR

In this Mac app, after copying it from the DMG, four Japanese filenames containing voiced sound marks (dakuten) were converted from NFC to NFD normalization, causing codesign --verify --deep --strict to fail with a sealed resource is missing or invalid. To resolve this, I bundled the Japanese-named files into a single ASCII-named file and updated the app to extract them using NFC filenames on the first launch. After this fix, I confirmed that code signature verification passes after copying.

What I checked when I encountered a signature error

First, I verified whether the signature was actually corrupted. I asked the user to run codesign --verify --deep --strict on their device, which returned the error: a sealed resource is missing or invalid. This indicated there was a discrepancy between the app contents and the signature, going beyond a simple UI warning.

Checking with xattr, I found that the app had the quarantine attribute—essentially, it was marked as being downloaded. In the signature verification results, the same filename appeared as both file added and file missing.

At this point, I began to doubt my initial hypothesis. Previously, I assumed the app was being flagged as "broken" because of adhoc signing. However, that alone didn't explain why the same name was being reported as both added and missing.

How Japanese Filenames Changed After Copying from a DMG

I tested copying the app via a DMG on my local machine. That's when I noticed that the filenames' internal representation—the way the computer stores the characters—had changed.

In Japanese, characters with dakuten (voiced sound marks) look identical on screen, but have two different internal representations: NFC and NFD. Right when the app was built, the filenames were still in NFC, so codesign --verify running immediately after the build succeeded.

However, once the app was copied via the DMG, four filenames containing dakuten were converted to NFD. Names without dakuten remained in NFC. Even though they looked identical visually, the filenames sealed during signing no longer matched the filenames after copying, causing the signature verification to fail.

The issue didn't surface during the build itself, but only after passing through the DMG. Because I was only checking right after the build, I had missed inspecting the exact step where the failure actually occurred.

Modified to Avoid Including Japanese Names in Distributables

In this update, I've changed the approach to avoid including files with Japanese names directly in the app. Multiple files, along with their contents, are now consolidated into a single file with an ASCII name (alphanumeric characters). Upon the app's first launch, necessary files are extracted from this consolidated file.

The extracted file names are normalized to NFC (Unicode Normalization Form C). Since file names created in the user's folder are not part of the signing process, Japanese names can be used. The goal is to avoid including Japanese names within the distributable package.

When modifying the original files, the consolidated data is updated using a generation command. Tests are in place to verify that the consolidated content matches the original files, that names are NFC-compliant, and that the original file set is not included in the distribution configuration.

After Fixing, Did the Copied App Pass Signature Verification?

I recreated the DMG for the fixed version, mounted it (opened and displayed its contents), and then copied the app. After that, running codesign --verify --deep --strict passed this time. It was necessary to verify the signature after copying the app, not while it was still inside the DMG.

On the other hand, the spctl assessment remained rejected. Officially, this is due to the result of ad-hoc signing. Additionally, I haven’t yet confirmed how the warning displayed on the actual device changes after the fix.

What I learned from this is that correctly signing the source and ensuring the distributed app remains in the same state are two different things. Even if the file names appear correct, the internal representation may not be the same. After creating the DMG, it’s essential to verify the signature of the copied app as well.

Key takeaways

Check quarantine attributes with xattr.
Verify the signature with codesign --verify --deep --strict.
If a sealed resource is missing or invalid appears, compare the filenames reported as added and missing.
Verify the app again after copying it from the DMG.
For Japanese filenames, check the difference between NFC and NFD.

How to Fix WSL2 Connections to Windows VOICEVOX

orca forge — Tue, 20 Oct 2026 13:05:31 +0000

TL;DR WSL2's default NAT networking makes 127.0.0.1 inside WSL point to WSL itself, not Windows. A Windows VOICEVOX engine listening on Windows 127.0.0.1:50021 is therefore unreachable from a web app running in WSL. Try mirrored networking, expose the engine with --host 0.0.0.0 and set VOICEVOX_URL to the Windows IP, or run the engine inside WSL.

Reasons why localhost is unreachable

The connection destination of Voice Canvas is specified by the environment variable VOICEVOX_URL. The default value is http://127.0.0.1:50021. When running with Docker, http://host.docker.internal:50021 is used.

Here, it's important to note that 127.0.0.1 refers to the connecting side itself. The Windows version of VOICEVOX only listens on Windows' 127.0.0.1:50021. On the other hand, the app is running inside WSL.

WSL's default network is NAT. Therefore, even if a web server inside WSL connects to 127.0.0.1:50021, the connection destination is WSL itself, not Windows. Even if VOICEVOX is started on Windows, it will not reach the listening destination.

On Windows, Voice Canvas is run inside WSL2's Ubuntu. This is because the startup script is written in bash and the location of venv assumes a Linux/Mac format. The README notes that operation has been confirmed on Windows 11 and WSL2 (Ubuntu 22.04).

There are mainly three ways to fix the connection destination issue.

Solution 1: Setting WSL to Mirror Mode

This is a method that can be tried without changing the code. Write the following settings to %USERPROFILE%\.wslconfig:

[wsl2]
networkingMode=mirrored

Then, run the following in PowerShell and restart WSL:

wsl --shutdown

With this method, you can continue to use the default connection destination of Voice Canvas, http://127.0.0.1:50021.

There is a precaution to note. wsl --shutdown will stop all work inside WSL. Please save any work you are doing in servers or terminals before running it.

This method is suitable when you do not want to change the connection destination of the app. Since the procedure to stop and restart WSL is necessary, choose the timing carefully when you have ongoing work.

Solution 2: Start VOICEVOX in a Connectable State from WSL

Start the Windows version of the VOICEVOX engine with --host 0.0.0.0. Then, specify the Windows IP address in VOICEVOX_URL. If using WSL's default gateway, you can find the IP address within WSL using the following command:

ip route | awk '/default/ {print $3}'

For example, if the command returns 172.19.128.1, set the connection target as follows:

VOICEVOX_URL=http://172.19.128.1:50021

This IP is just an example. Be sure to verify the actual value by running the command within WSL. You may also need to allow the connection through the Windows firewall.

This method is suitable when you want to explicitly specify the connection target without using mirror mode. You'll need to configure both the engine's startup method and the app's connection target, as well as verify the Windows IP address.

Solution 3: Run the engine inside WSL

This method involves running the VOICEVOX engine inside WSL instead of Windows. You can either use the Linux version or run voicevox/voicevox_engine using Docker.

If both the app and the engine are within the same WSL environment, you can configure the connection to 127.0.0.1. If you are running Voice Canvas via Docker, use http://host.docker.internal:50021 as the connection address.

If you prefer to use the Windows version of VOICEVOX as-is, please choose a different solution. However, if you are able to run the engine on the WSL side as well, this is a viable option to consider.

Providing WSL Guidance from the App

When the connection cannot be established, displaying only "VOICEVOX not found" to the user makes it difficult to identify the cause. In Voice Canvas, the app determines whether it is running on WSL or not and provides guidance tailored to the environment.

You can determine if it's WSL by checking if microsoft is included in the Linux environment's /proc/version. When the connection fails, a 503 response with a WSL indicator is attached, and WSL-specific guidance is displayed on the screen.

The type of failure is also distinguished. The location to check differs between when there is no response and when the connection is refused. By conveying the difference in errors to the user, it becomes easier to verify the connection destination or engine waiting settings.

Another Pitfall: Node.js on the Windows Side

Sometimes, the Windows-side Node.js can end up mixed into the WSL PATH. In environments where you use tools like nvm4w, running node inside WSL might accidentally invoke the Windows version instead of the Linux one.

If you're using Node.js 20 or later, install the Linux version inside WSL. Use the following command to check which executable is being used:

which node

Verify that the displayed path points to a location within WSL. If issues persist at app startup even after correcting VOICEVOX's connection target, also verify the Node.js execution environment.

Choosing an Approach

Use mirror mode if you want to test without changing the connection target.
If you continue using the Windows version of the engine and want to explicitly specify the connection target, set --host 0.0.0.0 and the IP address on the Windows side.
If you can run the engine within WSL, use the Linux version or the Docker version.

Regardless of the method, first verify where the engine is listening for connections. The Voice Canvas README also lists the required packages for launching on WSL.

sudo apt install -y git build-essential python3.10-venv python3.10-dev

python3.10-venv is used for virtual environments. build-essential and python3.10-dev are required to build pyworld. Pre-built packages for pyworld are not available for Python 3.10, so it must be built from source.

If you plan to use a GPU, configuration is not limited to the WSL side. The GPU in WSL runs using the NVIDIA driver on the Windows side. Since torch 2.4.0 is built for CUDA 12.1, you need a driver version that supports CUDA 12.1 or higher. With an older driver, such as 522.06 (which supports up to CUDA 11.8), you will see the message "NVIDIA driver on your system is too old" and the system will fall back to CPU processing.

Key takeaways

Use mirrored networking when you want to keep the default VOICEVOX_URL.
For the Windows engine, start it with --host 0.0.0.0 and set VOICEVOX_URL to the Windows IP found from WSL.
If the engine can run in WSL, use the Linux or Docker version; the app and engine can then share 127.0.0.1.
First check where the engine is listening. If startup problems remain, check which Node.js executable which node selects.

Repository: Voice Canvas

Why reasoning_effort behaves differently across providers

orca forge — Mon, 19 Oct 2026 13:03:04 +0000

TL;DR The app uses OpenAI-compatible /v1/chat/completions endpoints across cloud, self-hosted vLLM, and a relay. Browser actions never ran because an error was classified as lack of tool support. The cause was provider-specific handling of reasoning_effort and a classifier that ignored the error details.

① The Cloud Rejected the Combination of Tools and Configuration

The first rejection occurred when we sent the tools and reasoning_effort simultaneously. The target endpoint was gpt-5.6-luna. We received a 400 status code with the following message:

Upon seeing tool and not supported in the error body, the application concluded that "this model does not support tools." From then on, it excluded tools from requests entirely.

This was the erroneous misjudgment introduced at the beginning. Even when asked to perform browser operations, no tools were provided, so not a single operation was executed. Although it might appear that the model was avoiding calling tools, there was simply no opportunity to call them in the first place.

The error message explicitly provided a solution. To use tools, one should either use /v1/responses or set reasoning_effort to 'none'. The application, however, skipped reading that part and immediately made the decision to discard the tools.

The fix was to read the resolution before treating the rejection as a permanent tool incompatibility. We reissued the request with reasoning_effort: 'none' while keeping the tools attached. Essentially, for this model, using tools meant stopping the reasoning process.

Speed-wise, this change had its appeal. Setting reasoning_effort: 'none' reduced the latency from input to the start of the output from 4–5 seconds to just 2 seconds.

② Our in-house vLLM flat-out rejected the value

When I applied the same configuration to the tool-calling path, our own vLLM instance returned a 400 error.

The error type was literal_error. It wasn't that the field was missing; rather, the endpoint simply did not accept the value none.

If you only test with plain conversation, you might stop right here. Since conversations speed up, it looks like things are working. It was only after testing the tool-calling path that we realized the endpoint would handle values differently.

For this endpoint, we detect the value rejection and stop sending reasoning_effort altogether. To disable thinking, we instead send chat_template_kwargs: { enable_thinking: false }.

Here are the measured results for comparison.

Method of disabling thinking	Time taken
Do nothing	87 seconds
`/no_think`	154 seconds
`enable_thinking=false`	65 seconds
`reasoning_effort none`	2 seconds

These figures were measured using a model on-device. The differences between methods were significant, meaning that just because configuration names are similar does not imply the behavior will be aligned.

On top of that, the output fields for thinking don't match up either. The name used varies among three possibilities: reasoning, reasoning_content, and thinking. The writing side was aware of all three, but the reading side was only looking for reasoning.

vLLM writes to reasoning_content. The moment we switched to our own vLLM, the classifier flagged "empty response" five times in a row. The model was returning the thinking, but because the reader wasn't looking at the correct field, we couldn't even count the amount of thinking generated.

③ The relay server returned empty only when streaming

The third point concerns the handling of sequential responses.

There were some endpoints that ignored the stream: true flag and returned standard JSON. The app discards any line that does not start with data:. As a result, zero fragments were captured. Since response.ok was true, no exception was thrown, and nothing appeared on the screen.

I fixed this by checking the content-type to determine whether the response is a streaming response or standard JSON.

But that wasn't the end of it. One relay server endpoint would return a 200 OK in 94ms only when streaming was enabled, but the body was empty. It would reject non-streaming calls with a 400 error. In empty responses, there are no clues like an error message body.

For this endpoint, I decided to treat an empty response as an exception. I configured it to retry once after disabling the "thinking" specification, and to stop sending requests after that. When I retried without the specification, the correct JSON was returned in 327ms.

A table of measured behavior per endpoint

Endpoint behavior	Data sent
Standard (OpenAI, etc.)	`reasoning_effort: 'none'`
`none` not in the value list (vLLM, rejects with 400)	`chat_template_kwargs: { enable_thinking: false }`
Returns empty when streaming (relay server)	Send nothing

All of these were decided based on actual measurements. I don't ask the users. The app learns based on the response from the endpoint.

Self-Inflicted Regressions

After implementing a fix to account for differences between endpoints, I introduced a couple of new issues myself.

Regression 1: Overly Broad Handling of 400 Error Bodies

The logic for detecting rejected values was also checking for the presence of the word invalid. If a 400 error body contained invalid_request_error, all errors were treated the same.

As a result, the system incorrectly learned that gpt-5.6-luna was an endpoint "missing the reasoning_effort field". It stopped at the none designation required in ①, causing the entire browser operation to fail.

The root cause was that I had created custom error messages for testing. Since these differed slightly from actual rejections, the discrepancy in detection went unnoticed. I adjusted the tests to use recorded error bodies directly.

Regression 2: Applying Local Settings to Cloud Endpoints

In voice conversations, I had enabled a setting to automatically truncate thoughts. This setting was inadvertently applied to the official cloud endpoints as well, causing none to be sent to OpenAI.

Every response generation request timed out after 60 seconds, resulting in a 500 error. This occurred consistently across four attempts, despite OpenAI's status being "normal".

The code originally noted that "cloud providers use the same keys for different purposes". I failed to consider endpoint-specific meanings and applied the setting globally. I corrected this by limiting the setting to local providers only.

Additionally, there was a flaw in the retry mechanism for rejected fields. Each utterance allowed only one retry. If both temperature and frequency_penalty were rejected, the first utterance would fail silently.

I updated the logic to remove and retry rejected fields upon each rejection, up to 8 attempts. If a response with at least one character is received before a failure, no retry is attempted.

Key takeaways

Read the full 400 response body before classifying the error.
Match reasoning_effort handling to each endpoint's observed behavior.
For vLLM, use chat_template_kwargs: { enable_thinking: false } when none is rejected.
If a relay returns an empty streaming response, retry without the reasoning setting and stop sending it to that endpoint.
Use observed endpoint behavior in tests and provider-specific configuration.

Why Electron Screen Recording Used 492% CPU

orca forge — Sat, 17 Oct 2026 13:01:33 +0000

TL;DR The Electron streaming window reached 492% CPU while ffmpeg used 28%. The recording size was unset, so capture used the Retina display resolution, and MediaRecorder plus ffmpeg encoded the video twice. Passing size and frame rate limits and copying the recorded format reduced recording-side CPU usage to about one-thirtieth.

The Cause: Recording Size and Double Encoding

There were two main causes.

The first was that I hadn't specified the size for the screen recording. The code was getDisplayMedia({ video: true }). Although the settings screen displayed 1280×720 at 30fps, those values were not actually being reflected in the recording.

Without a specification, it was recording at the native Retina resolution. The screen size was something like 3456×2234. For someone like me who was estimating streaming load based on the settings values, this was a major blind spot. Even though I intended to record a small window, I was actually capturing a massive display.

The second cause was that the video was being encoded twice. MediaRecorder encoded the video to VP8 using the CPU, and then ffmpeg converted that video into H.264. The device's VideoToolbox encoder was only being used on the ffmpeg side. The VP8 encoding for the recording remained stuck on the CPU.

Even the recording phase, which happens before the streaming, involves heavy encoding work. By measuring the processes separately, I was able to identify exactly where the load was occurring.

Deciding the Recording Format First

In the revision, we first passed the size and frame rate to getDisplayMedia with max. This informs the recording side of the upper limit.

Next, when using MediaRecorder, we try H.264 first. If the device's encoder can record in a usable format, we don't need to re-create the video with ffmpeg. The actual recorded format was video/mp4;codecs=avc1,mp4a.40.2.

In that case, ffmpeg only needs to re-wrap the video with -c:v copy. Here, specifying -b:v or -r would result in re-creating the video after all. If we're just copying, there's no need for extra specifications.

However, we can't know what format MediaRecorder can record in until we check the window side. So, we've changed it to launch ffmpeg after receiving the format notification from the window.

When changing the order, we first investigate the reason why it can be stopped. If it's due to ffmpeg being unavailable or a key being missing, we can inform the user before opening the window. If we open the window first and then display "cannot send", it will appear to the user as if the stream is being transmitted.

The recording side is about 1/30

After modification, I measured it 4 times at 20-second intervals on the same Mac. The CPU usage rate on the recording side was 14.8%, 16.3%, 19.6%, and 19.2%. ffmpeg was at 0.1%. The load average was 3.28, 3.48, 3.27, and 4.16.

The load on the recording side has become about 1/30. The load average of 3 to 4 includes the load of the application itself, such as LLM and embedding. The load of the distribution itself is almost negligible.

Let me note one thing. The modified episode was after the distribution slot of the receiver ended, so I haven't reconfirmed the reach to YouTube. The reach was confirmed in the episode before the modification. At that time, I distributed for 9 minutes and 30 seconds, the image quality was "very good" (非常に良い), and the bitrate was 3064 kbps. The fact that the load decreased after modification and the fact that the reach after modification was confirmed are separate.

When Load is Too High, the App Automatically Stops Streaming

Even if the load is reduced, operational concerns remain. The biggest issue this time was that users couldn't stop the stream. I was able to stop it through another method, but users didn't have the same option.

To address this, I implemented a mechanism where the app itself stops streaming when the load is too high. During streaming, the app checks the average load over the past minute every 10 seconds. If the load exceeds the number of CPUs × 2.5 for three consecutive checks (approximately 30 seconds), the app automatically stops the stream.

It won't stop if the load spikes momentarily. If the load drops even once, the counter resets. When stopping, the app also displays the reason and how to fix it. For example, it might suggest reducing the recording resolution.

By the time the app becomes too slow for users to operate, asking them to stop it manually is already too late. Detecting anomalies and stopping the stream should be part of the streaming feature's design.

Key takeaways

Set size and frame rate limits in getDisplayMedia.
Check the format actually produced by MediaRecorder before starting ffmpeg.
When the format can be copied, use -c:v copy and avoid settings that re-encode the video.
Monitor load during streaming and stop automatically if high load persists.

DEV Community: orca forge

Why gpu-unlock Speeds Up RTX 3090 Prefill but Barely Changes Decode

What Was Being Held Back

What Gets Faster—and What Doesn’t

Which Cards Have Been Reported

Things to Consider Before Installing

Key takeaways

Related Articles

How to Catch Japanese Text in Automated dev.to Crossposts

When the Body Is in English, It Slips Through

The English Translation Had Other Errors, Too

Natural-Sounding English Errors Can’t Be Found by Checking the Characters Alone

Inspect the Article Itself Right Before Posting

Results from Checking 94 Articles

Key takeaways

How to Recover 13 Deleted DNS Records in 11 Minutes

Conclusion First

Where the DNS Records Were Before Deletion

How I Verified Every Record After AXFR Was Denied

Verifying Recovery Time Using TTL and SOA Serial

How to Avoid Accidentally Deleting DNS Records

Key takeaways

Why MediaRecorder Turns a 190-Second Recording Into 92 Seconds

Conclusion First

Why the last data was missing after stopping the recording

Why My 60-Second Voiceless Recording Resulted in a 0-Byte File

Why the last voice of the studio-side avatar was cut off

How the Recording Time and Audio Length Changed After Fixes

Key takeaways

Why a VRM Right Hand Disappeared: Empty Cuff Ring and NaN

Conclusion First

Was the Disappearing Right Hand a Display or Pose Issue?

At which stage was NaN born?

Why the Ring at the Cuff's Vertex Became Empty

How to Stop the Empty Loop and NaN in Bones

Why Python Errors Don’t Stop Execution in Our Pipeline

How to Verify Values Are Created at the Right Stage

Related Articles

Key takeaways

Why uvx MCP servers fail with Pydantic 2.14

Conclusion First

Why Pydantic 2.14 Causes an ImportError

Adding Pydantic <2.14 Specification to uvx Arguments

Verify MCP Server initialize Response After Reconnection

Which Existing Configurations to Add Pydantic Specifications To

Key takeaways

Why Ollama Tool Calls Fail at a 4,096 Context Length

Conclusion First

Why Didn’t I Get a 400 Error and Couldn’t Pinpoint the Cause?

Why the limit changed from 16,384 to 4,096

How I fixed the tool call destination

Did it reach the end after specifying 16,384?

Key takeaways

How to Check Your Mac for the LiteLLM 1.107.0 Compromise

Conclusion First

Which Version is Dangerous?

Where to Find the Three Files

What to Look for If You Find sitecustomize.py

Checking for Marker Files and Processes

Verify Environment Variables and Communication as Well

What to do if you had version 1.107.0

Key takeaways

Why codesign Fails After Copying a Mac App from a DMG

TL;DR

What I checked when I encountered a signature error

How Japanese Filenames Changed After Copying from a DMG

Modified to Avoid Including Japanese Names in Distributables

After Fixing, Did the Copied App Pass Signature Verification?

Key takeaways

How to Fix WSL2 Connections to Windows VOICEVOX

Reasons why localhost is unreachable

Solution 1: Setting WSL to Mirror Mode

Solution 2: Start VOICEVOX in a Connectable State from WSL

Solution 3: Run the engine inside WSL

Providing WSL Guidance from the App

Another Pitfall: Node.js on the Windows Side

Choosing an Approach

Key takeaways

Related Articles

Why reasoning_effort behaves differently across providers

Verify MCP Server `initialize` Response After Reconnection