They have some nasty "dynamic tap zones" algorithm that dynamically resizes the hitbox for keys based on what it predicts you will type in order to reduce miss-taps. Anecdotally, it has just steadily been getting worse with every update. I swear I can be pressing the center of a key and it will select the next one over and immediately autocorrect to a completely different word than what I typed.
I had the pleasure of typing something on an Android the other day and it was such a breath of fresh air when it actually accepted the keys I was pressing...
In addition to this, there is a delay in the suggested word such that when you see the options above the keyboard, decide you see the word you want, stop typing and move to select it, it changes right as you land your finger.
That drives me crazy. What's crazier happens when the suggested word is the one you are going to type. You hit the next letter in the word, recognize that it has already been suggested, yet right after you hit the letter, it decides to suggest another word.
Compliments of product managers, engineers, etc making millions and millions of dollars to produce a much worse end user experience, if it wasn’t painful enough
Oh wonderful. That’s what’s happening to me. I’m an author and Apple‘s dictionary appears to be missing about half the more uncommon words in the English language. It’ll never recognize “prescient” in dictation for example. Some words it marks in red because it thinks it’s a spelling error. I know it’s not because I’ve used it, read it, and it’s in online dictionaries.
At least I’m macOS I can use Talon instead of the system dictation.
Thank you for putting a name to this phenomenon. I hadn't gone through my yearly attempt to figure out why iOS was terrible for text entry. I figured since I only have an iPad and not an iPhone, and infrequently type in it, that it just hadn't learned my habits or words. It's incredible that they've developed these kinds of algorithms that have made every facet of text entry from speech to text to spell checking to typing itself such a miserable experience.
Try turning off slide to type. It's under Settings > General > Keyboard.
I did it earlier this year. It seems to be much more accurate and confident with which key it thinks I want. I do occasionally miss the sliding but it's worth it overall.
Yeah, I’m not a dedicated iPhone user and my personal phones are androids so my iOS experience has been iPod Touch 2G -> employer owned iPhone 8 -> employer owned iPhone XR -> iPad Air M3. Each of those big gaps have seen the UI shift and the keyboard decline.
Interesting. Because I have a much harder time typing on my Pixel. In fact, I hate it. I wish I had a blackberry.
When I use iOS devices, it feels better but I don't use them enough to have used them in anger. Ok, well, yes they have made me angry but for other reasons than the keyboard hence why I'm on Android lol.
I used a Clicks keyboard with a folded Moto Razr for a while and it was Blackberry-esque. The keyboard is a little narrow compared to the Blackberries of yore, though. I'm somewhat hopeful about the Clicks Communicator which is wider, but sadly still only a four row keyboard.
To be clear, I only kind of recommend the keyboard. I stopped using mine after a while because of how awkward it was with the Razr unfolded and never actually found it faster or more accurate than the on screen keyboard.
someone posted high speed videos a few months ago where the keyboard will popup the key you thought you pressed (therefore did press, as far as the UI is concerned) but iOS will insert a different character anyway.
Some of those videos are misleading. They sometimes slide a finger off one key onto another: taps need to not move.
Personally, I use the slyde to type rather than tapping to type and have gboard installed for when slyde doesn't work (I think the Apple algos are not quite as good as Google's).
Yep; this has been the case since the very first iPhone, it can't be disabled, and there is no feedback it happens other than the typos. It is very crazy making and mind boggling.
I wrongly assumed I was below version 10.10.7 and tried to "upgrade" to it first as the migration guide said, but this completely blew up and the db migrations failed. I then tried to skip straight to 12 and that also crashed on startup during db migrations, so I just nuked the whole Jellyfin config and started from scratch.
Bit unfortunate how this can even happen, but it's on me for not checking or taking a backup first. The config/db really contain anything important anyways, other than "watched" markers that are already out of sync for me across Emby/Jellyfin/Plex.
These draconian "Preserved Thinking" measures they're taking are going to be an absolute pain in the ass. This alone is enough for me to move our API use off their platform entirely. It's a HUGE breaking change that they're trying to dampen by having it not affecting current customers until "in the future", see: https://platform.claude.com/docs/en/build-with-claude/preser...
You're no longer allowed to edit the context anywhere! The whole context is to become append-only, says Anthropic. No more editing the system prompt as the conversation progresses, no more dynamic loading of custom tool calling formats. Everything has to go through their built-in tools API and you aren't allowed to mess with anything in the context if it has any thinking blocks following it. This is the most intrusive "model DRM" we've seen so far!
> No more editing the system prompt as the conversation progresses, no more dynamic loading of custom tool calling formats.
Hm, aiui you can support both of these via mid-conversation system turns https://platform.claude.com/docs/en/build-with-claude/mid-co... - and in general you'd want to to preserve the cache and recency of the instruction anyways rather than frankensteining an off-distribution transcript. Not sure though.
I really don't see how that is an option, as if appending to the system prompt was ever enough to override previous instructions. Their example isn't very confidence inspiring either:
"The user switched the workspace to read-only mode. Do not write files until told otherwise."
Great! Now we just have to trust that the model never misinterprets any of the system prompt, which has always been so reliable before. Instead of your meticulously crafted prompt, it will now be some junk like this:
"The workspace is in write mode. The user switched the workspace to read-only mode. Do not write files until told otherwise. The workspace is now in write mode again. Wait, back to read-only!"
And who knows how this integrates with their context summarisation that we will be FORCED to use. How does it summarize multiple user + assistant/thinking blocks without messing up the system "appends"? If all it did was append the mid-convo system messages right under the original system prompt then they'd be ripe for all the same distillation "vulnerabilities" as before. I guess we'll never know!
Worse: Claude installed packages by just typing versions into package.json instead of running `pnpm install x`, then when running `pnpm install`, discovering that the package versions are too new and incompatible due to the default `minimumReleaseAge`, then proceeding to circumvent this by disabling `minimumReleaseAge` and running a full package update :)
I was subscribed to Kagi for a while but cancelled because there was no subscription for JUST search that didn't include their inferior AI assistant. Why am I paying for it?
If you compare the Professional plan (unlimited searches), to the API, you could justify that the extra AI cost is negligable if you are heavy user. The API costs $12 per 1000 searches, so 1.2¢ per individual search. 10/0.0012≈833.33. At 834 searches or more you would not be paying for the AI features. Obviously, this is only a comparison to the API, which might not have all special Kagi features.
But if you're using the starter plan, which is 300 searches for $5, then you definitely do pay for the assistant. The API cost would be $3.60.
IDK, when a system is very complex — which GH certainly is — this phrasing sounds kinda fine to me? It's recovering, but not yet operating fully as intended.
The main role of the harness is not any kind of moderation or alignment, but simply making a text generation engine do anything other than output a long stream of text.
It's like saying that the role of a car's wheel is to hold wheel clamps. Yes, you can put wheel clamps (or snow chains etc) on a wheel, but the wheel's overwhelming role is to rotate and propel the car forward, and there is no driving without having wheels, you just have an engine with parts rotating inside. Bad analogy I know but, a harness is not a safety feature. Imagine that you're trying to explain cars to someone who has never seen one and you never say that the wheel's purpose is to rotate and move the car from A to B, you just say that it's something to put chains on when it snows.
I guess the name sounds like some kind of straightjacket etc. But think of it more as the harness you put on a workhorse or ox. It's the thing that connects it to the workload in the first place. They are not the blinders of the horse.
None of this is true. The point of "just CLI" is that LLMs are infinitely more trained on working CLI tools. There doesn't need to be real CLI tools behind the harness, as long as the interface is CLI-like.
All of the main agent CLI's provides a demonstration that it is possible because they're all callable as a CLI. Several of them, like Codex, Kimi CLI, Pi, OpenCode are open source and so you could obviously strip out the MCP host and client from them and turn them into a CLI. Doing so in a way that keeps auth outside the agents sandbox is trickier and you might end up with a proxy which partly defeats the point but at least still keeps the composability of a CLI.
I had the pleasure of typing something on an Android the other day and it was such a breath of fresh air when it actually accepted the keys I was pressing...
reply